From: SourceForge.net <no...@so...> - 2007-08-21 13:24:12
|
Bugs item #1777758, was opened at 2007-08-20 18:36 Message generated for change (Comment added) made by borutr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1777758&group_id=599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Icode generator Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jeremy Cooper (ke6jjj) Assigned to: Nobody/Anonymous (nobody) Summary: Constants fold incorrectly under Mac OS X Intel gcc Initial Comment: SUMMARY SDCC 2.7.0 does not run correctly under Mac OS X Intel using gcc 4.0.1, in some cases it produces incorrect code, and in other cases it crashes. I have isolated one specific (non-crash) behavior to the following minimal test case. The following test code compiles correctly under gcc version 3.4.2 [FreeBSD] 20040728 and incorrectly under gcc version 4.0.1 (Apple Computer, Inc. build 5367). To isolate the problem, I ran SDCC in '--dumptree' mode and found that the bug occurs at the intermediate code level. To reproduce: sdcc --dumptree -mmcs51 -c test.c -o test.rel EXAMPLE PROGRAM char epcs (char ep) { ep &= ~0x80; return ep; } EXPECTED BEHAVIOR: (obtained from SDCC 2.7.0 under FreeBSD gcc 3.4.2) ... sdcc-test.c:4: CONSTANT (0x82db180) value = 127, 0x7f 127.000000 type (literal-char) ... ACTUAL BEHAVIOR: (obtained from SDCC 2.7.0 under Mac OS X gcc 4.0.1) ... sdcc-test.c:4: CONSTANT (0x5399e0) value = 0, 0x0, 0.000000 type(literal-char) ... SDCC Version: SDCC : mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds400/hc08 2.7.0 #4818 (Aug 17 2007) (UNIX) ---------------------------------------------------------------------- >Comment By: Borut Ražem (borutr) Date: 2007-08-21 15:24 Message: Logged In: YES user_id=568035 Originator: NO Just FYI: the problem is not reproducible on ppc Mac OS X. It seems that only x86 Mac OS X is affected :-( Borut ---------------------------------------------------------------------- Comment By: Jeremy Cooper (ke6jjj) Date: 2007-08-21 06:27 Message: Logged In: YES user_id=531281 Originator: YES I have tested and suggest the following (attached) patch to SDCCval.c (2.7.0). It removes the offending upfront cast and uses 'fval' directly where needed. File Added: sdcc.1777758.patch ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2007-08-21 06:07 Message: Logged In: NO I have tracked down the source of this bug to the assignment of 'l' in the function valCastLiteral(), in SDCCval.c. value * valCastLiteral (sym_link * dtype, double fval) { value *val; TYPE_TARGET_ULONG l = (TYPE_TARGET_ULONG)fval; In this particular case, 'fval' has the value -129. As such, the result of this assignment operation is undefined; an unsigned long cannot hold the value -129. According to the C99 specification: 6.3.1.4 Real floating and integer ... If the value of the integral part cannot be represented by the integer type, the behavior is undefined. I believe this was also pointed out in track item #1739860. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1777758&group_id=599 |