From: Vangelis R. <vr...@ot...> - 2004-09-04 00:37:29
|
The code generator is not buggy at this point. It is a hand placed call to assertion to track a possible bug. The truth is that in gen.c there was a portion of old code which was handling a strange combination of operands in assignments. When I first encountered the code block I couldn't figure out what purpose it served (and I still can't!), so instead of creating a another silent bug, I added an assert(0) line which at the right time would show what was its purpose, just like what happened with your source. Now, after examining the portion again I am sure it can be safely removed, since the specific case can be handled by other portions. The bug wouldn't appear if you changed the order of variables in assign_demo(), or if you had another variable inbetween. In fact the assertion is raised only if the byte variable is allocated at the 5th position in RAM memory!!! (long is 4 bytes and byte is placed at ram position 4). In a few words, the bug will be fixed soon! regards, Vangelis ----- Original Message ----- From: "SourceForge.net" <no...@so...> To: <no...@so...> Sent: Friday, September 03, 2004 7:29 PM Subject: [sdcc-devel] [ sdcc-Bugs-1021927 ] assignment from SFRs buggy? > Bugs item #1021927, was opened at 2004-09-03 16:29 > 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=1021927&group_id=599 > > Category: pic16 target > Group: None > Status: Open > Resolution: None > Priority: 5 > Submitted By: ccsporters (tecodev) > Assigned to: Nobody/Anonymous (nobody) > Summary: assignment from SFRs buggy? > > Initial Comment: > The following code fragment of PIC16 code shows unusual > behaviour: > (1) byte value, byte temp compiles ok > (2) byte value, long temp compiles ok > (3) long value, long temp compiles ok > (4) long value, byte temp failes with assertion in > gen.c, line 10903. > > sdcc: gen.c:10903: genAssign: Assertion `0' failed. > Caught signal 6: SIGABRT > > After removing the function hurdle() (or by moving it > below assign_demo()) the code compiles nicely in all of > the above cases... > > Here is the code: > --- > #include "pic18f6720.h" > > typedef unsigned char byte; > > void hurdle () { > // do nothing > } > > int assign_demo () > { > long value; > byte temp; > > value = ADRESH; > temp = ADRESL; > value |= temp; > return value; > } > --- > A workaround is possible by casting ADRESL to > (long)ADRESL, but still there seems to be a problem... > > Tested with SDCC : pic16 2.4.3 #826 (Aug 30 2004) (UNIX), > command line: sdcc -mpic16 -p18f6720 -I > ~/sdcc/device/include/pic16 -I ~/sdcc/device/include > assign_gen.c > > > ---------------------------------------------------------------------- > > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=100599&aid=1021927&group_id=599 > > > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > |