#1861 --max-allocs-per-node problem 4

closed-fixed
z80 port (188)
5
2012-08-14
2011-10-16
Woody
No

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.

Discussion

  • Woody

    Woody - 2011-10-16
     
  • Woody

    Woody - 2011-10-16

    The interesting thing is, the function SipCallStep1() was exactly the same function which went wrong with bug 3122620.

     
  • Philipp Klaus Krause

    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

     
  • Woody

    Woody - 2011-10-18

    generated .asm files

     
  • Woody

    Woody - 2011-10-18

    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?

     
  • Woody

    Woody - 2011-10-18

    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)

     
  • Woody

    Woody - 2011-10-18

    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)

     
  • Philipp Klaus Krause

    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.

     
  • Woody

    Woody - 2011-12-18

    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.

     
  • Philipp Klaus Krause

    Any news on this bug or how to reproduce it in current sdcc?

    Philipp

     
  • Woody

    Woody - 2012-01-18

    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.

     
  • Philipp Klaus Krause

    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

     
  • Woody

    Woody - 2012-01-18

    Should I open a new bug or pile it up with this old one?

     
  • Philipp Klaus Krause

    Make it a new one ("here" refered to the Sourceforge bug tracker), so they can be discussed and closed individually.

    Philipp

     
  • Woody

    Woody - 2012-02-24
     
  • Woody

    Woody - 2012-02-24

    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.

     
  • Woody

    Woody - 2012-02-27

    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?

     
  • Philipp Klaus Krause

    I suggest you file a new bug report for the time.c issue.

    Philipp

     
  • Woody

    Woody - 2012-08-10

    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.

     
  • Philipp Klaus Krause

    • assigned_to: nobody --> spth
    • status: open --> closed-fixed
     
  • Philipp Klaus Krause

    So it seems this bug went away sometime near the 3.2.0 release.

    Philipp

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks