#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
     
    Attachments
  • 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

     
    Attachments
  • 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
     
    Attachments
  • 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

     

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

Sign up for the SourceForge newsletter:





No, thanks