From: Bernhard Held <bheld@mg...> - 2003-08-05 16:09:56
My commit today was only the beginning of a review of some parts of the
optimizer. Currently I'm hunting problems with signed and unsigned operands.
SDCC emited different results, if e.g. a multiplication was performed by
SDCCval.c or SDCCcse.c or during runtime by the library support functions.
Of course there's only one ANSI-compliant way. I'll supply a comprehensive
regression test to strengthen the status quo.
One important change today is, that literal constants are signed again by
default (it's simply a must; they were unsigned before, I hope Johan is on
holiday :->). As a result literal constants in the range 128...255 don't fit
any longer in an "unsigned char", they need a "signed int" now. An exception
are hex- and octal-constants. Another new possibility is to append the flag
u (or U) to force an unsigned constant in the smallest possible data type.
extern unsigned char b;
unsigned int a;
a = b * 246u;
if (a == 64002u)
puts ("I'm happy about the short code");
The same problem re-appears at the 16 boundary.
In order to expose problems there's a new warning "integer overflow in
expression". The warning is switched off by --less-pedantic.
Get latest updates about Open Source Projects, Conferences and News.