Small Device C Compiler (SDCC) / Bugs / #1861 --max-allocs-per-node problem 4

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

Status: closed-fixed

Owner: Philipp Klaus Krause

Labels: z80 port (189)

Category:

Priority: 5

Updated: 2012-08-14

Created: 2011-10-16

Creator: Woody

Private: 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 - 2011-10-16

protocol.c

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Woody - 2011-10-16

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

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Philipp Klaus Krause - 2011-10-18

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

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Woody - 2011-10-18

generated .asm files

protocol_asm.zip

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

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?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

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)

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

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)

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Philipp Klaus Krause - 2011-12-18

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.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

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.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Philipp Klaus Krause - 2012-01-16

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

Philipp

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

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.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Philipp Klaus Krause - 2012-01-18

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

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Woody - 2012-01-18

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

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Philipp Klaus Krause - 2012-01-18

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

Philipp

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Woody - 2012-02-24

md5.c

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

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.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

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?

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Philipp Klaus Krause - 2012-02-27

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

Philipp

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

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.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Philipp Klaus Krause - 2012-08-14

assigned_to: nobody --> spth

status: open --> closed-fixed
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Philipp Klaus Krause - 2012-08-14

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

Philipp

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

--max-allocs-per-node problem 4

The Small Device C Compiler (SDCC), targeting 8-bit architectures

Searches

Help

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

Discussion