From: SourceForge.net <no...@so...> - 2005-03-10 18:53:21
|
Bugs item #1160833, was opened at 2005-03-10 19:53 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1160833&group_id=599 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Simon Berg (ksb) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect use of cached cast Initial Comment: In the attached C file the second line of USB_send_data causes len to be cast to a 16 bit word and that word is stored in _USB_send_data_sloc1_1_0 . It's later used by the printf function for it's len argument. The problem is that len (mapped to _USB_send_data_PARM_3) is changed in between and an old value is used by printf. Sorry about the complicated test case but it seems very dependant on the number of variables allocated (or something), and as soon as I remove something the problem goes away. Compiled with: sdcc -mmcs51 -S fail.c Version: SDCC : mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds400/hc08 2.4.0 (Dec 15 2004) (UNIX) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1160833&group_id=599 |
From: SourceForge.net <no...@so...> - 2005-03-17 06:55:21
|
Bugs item #1160833, was opened at 2005-03-10 12:53 Message generated for change (Settings changed) made by epetrich You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1160833&group_id=599 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Simon Berg (ksb) >Assigned to: Erik Petrich (epetrich) Summary: Incorrect use of cached cast Initial Comment: In the attached C file the second line of USB_send_data causes len to be cast to a 16 bit word and that word is stored in _USB_send_data_sloc1_1_0 . It's later used by the printf function for it's len argument. The problem is that len (mapped to _USB_send_data_PARM_3) is changed in between and an old value is used by printf. Sorry about the complicated test case but it seems very dependant on the number of variables allocated (or something), and as soon as I remove something the problem goes away. Compiled with: sdcc -mmcs51 -S fail.c Version: SDCC : mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds400/hc08 2.4.0 (Dec 15 2004) (UNIX) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1160833&group_id=599 |
From: SourceForge.net <no...@so...> - 2005-03-20 19:41:04
|
Bugs item #1160833, was opened at 2005-03-10 12:53 Message generated for change (Comment added) made by epetrich You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1160833&group_id=599 Category: None >Group: fixed >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Simon Berg (ksb) Assigned to: Erik Petrich (epetrich) Summary: Incorrect use of cached cast Initial Comment: In the attached C file the second line of USB_send_data causes len to be cast to a 16 bit word and that word is stored in _USB_send_data_sloc1_1_0 . It's later used by the printf function for it's len argument. The problem is that len (mapped to _USB_send_data_PARM_3) is changed in between and an old value is used by printf. Sorry about the complicated test case but it seems very dependant on the number of variables allocated (or something), and as soon as I remove something the problem goes away. Compiled with: sdcc -mmcs51 -S fail.c Version: SDCC : mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds400/hc08 2.4.0 (Dec 15 2004) (UNIX) ---------------------------------------------------------------------- >Comment By: Erik Petrich (epetrich) Date: 2005-03-20 13:41 Message: Logged In: YES user_id=635249 I believe that this bug is now fixed in version 2.4.8 #980, although it is subtle enough that I can't say that with absolute certainty. In any case, the current test case appears to compile correctly now. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1160833&group_id=599 |