From: SourceForge.net <no...@so...> - 2012-08-10 12:11:48
|
Bugs item #3424436, was opened at 2011-10-16 11:45 Message generated for change (Comment added) made by woody1234 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3424436&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: z80 port Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Woody (woody1234) Assigned to: Nobody/Anonymous (nobody) Summary: --max-allocs-per-node problem 4 Initial Comment: In attached protocol.c, the function SipCallStep1() was compiled correctly with command line "C:\SDCC\BIN\sdcc protocol.c -mz80 -c --std-c99 --max-allocs-per-node 9521 --codeseg CODE5", but generated error result when using --max-allocs-per-node 9522. C:\sdcc\src>..\bin\sdcc -v SDCC : mcs51/gbz80/z80/z180/r2k/ds390/pic16/pic14/TININative/ds400/hc08 3.0.6 #6969 (Oct 16 2011) (MINGW32) The interesting thing is, the was exactly the same function which went wrong with bug 3122620. ---------------------------------------------------------------------- >Comment By: Woody (woody1234) Date: 2012-08-10 05:11 Message: Tested again just now, no problem with current build #8062 too. So far seems that 3.2.0 is pretty good if --oldalloc is NOT used, but I noticed two new problem with --oldalloc. May file new bug report later. ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2012-02-27 07:33 Message: I suggest you file a new bug report for the time.c issue. Philipp ---------------------------------------------------------------------- Comment By: Woody (woody1234) Date: 2012-02-27 07:27 Message: There must be something magic with -"-max-allocs-per-node 9522", I am testing with #7368 today, and find the following: C:\SDCC\BIN\sdcc time.c -mz80 -c --std-c99 --max-allocs-per-node 9522 --codeseg CODE1 Caught signal 11: SIGSEGV ..\bin\make: *** [time.rel] Error 1 I tried several different --max-allocs-per-node from 5000 to 9521, all ok. without the signal 11. time.c is totally different from previous protocol.c, should I open a new bug or keep it with current one? ---------------------------------------------------------------------- Comment By: Woody (woody1234) Date: 2012-02-24 06:53 Message: I need to get over bug 3489899 before I can test this bug. As I can not attach file to "closed" bug 3489899 now, I attached md5.c for 3489899 here. ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2012-01-18 05:37 Message: Make it a new one ("here" refered to the Sourceforge bug tracker), so they can be discussed and closed individually. Philipp ---------------------------------------------------------------------- Comment By: Woody (woody1234) Date: 2012-01-18 05:31 Message: Should I open a new bug or pile it up with this old one? ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2012-01-18 02:35 Message: Ok, can you report the other problem as a bug here, so it can be tracked down and fixed (preferably with a small example to reporduce it)? Philipp ---------------------------------------------------------------------- Comment By: Woody (woody1234) Date: 2012-01-17 20:33 Message: I tested SDCC : mcs51/gbz80/z80/z180/r2k/ds390/pic16/pic14/TININative/ds400/hc08 3.1.2 #7234 (Jan 17 2012) (MINGW32) Still the same as #7110, 192.168.1.124 becomes 291.861.1.421, something compiled wrong, maybe in my atoi function. Do not have chance to test the original bug. ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2012-01-16 08:18 Message: Any news on this bug or how to reproduce it in current sdcc? Philipp ---------------------------------------------------------------------- Comment By: Woody (woody1234) Date: 2011-12-18 07:20 Message: I tried #7110, seems that there is a new bug which caused all my number string reversed, for example, IP address 192.168.1.1 becomes 291.861.1.1, SIP port 5060 becomes 0605. So I can not go on to test if the original bug was fixed or not. ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2011-12-18 03:48 Message: Could you please 1) Check if this problem still occours in current sdcc, with the old --max-allocs-per-node or different ones 2) State which error you encounter (compilation fails, wrong result in a specific place or wrong code generated for specific line) Philipp P.S.: I just tried and could not reproduce this using sdcc 3.1.1 #7110 on Debian GNU/Linux. However the bug probably is still present in the Windows build. ---------------------------------------------------------------------- Comment By: Woody (woody1234) Date: 2011-10-18 08:35 Message: I replaced with #6876 sdcc.exe, same problem as #6969 SDCC : mcs51/gbz80/z80/z180/r2k/ds390/pic16/pic14/TININative/ds400/hc08 3.0.6 #6976 (Oct 18 2011) (MINGW32) ---------------------------------------------------------------------- Comment By: Woody (woody1234) Date: 2011-10-18 08:28 Message: Only replace sdcc.exe will generate the problem, my previous version is: SDCC : mcs51/gbz80/z80/ds390/pic16/pic14/TININative/ds400/hc08 3.0.1 #6078 (Dec 7 2010) (MINGW32) ---------------------------------------------------------------------- Comment By: Woody (woody1234) Date: 2011-10-18 08:16 Message: I have uploaded the working protocol_9521.asm and none-working protocol_9522.asm. I only used sdcc.exe, sdcpp.exe, sdasz80.exe and sdld.exe, is there anything I missed? ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2011-10-18 06:11 Message: I cannot reproduce this. I've tried sdcc revision #6969 and an earlier and current version. For all of them the generated code is identical for --max-allocs-per-node 9521 vs. 9522. I used Debian GNU/Linux, compiled sdcc from source. Philipp ---------------------------------------------------------------------- Comment By: Woody (woody1234) Date: 2011-10-16 11:48 Message: The interesting thing is, the function SipCallStep1() was exactly the same function which went wrong with bug 3122620. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3424436&group_id=599 |