Looking at the mcs51 asm generated for tests/gcc-torture-execute-20180131-1.c, in the function testTortureExecute, there are two function calls. One to f, one to memcpy (as a helper function used for copying a struct).
However the SEND iCode that should send the first parameter to f ends up before memcpy.
Apparently, tests/gcc-torture-execute-pr67226.c is also affected. I guess this bug might affect mcs51 for all calls, where a struct parameter follows an integer parameter.
In [r14440] I added a regression test for this (for now disabled for the ports where it fails).
Apparently affected ports: mcs51, hc08, s08, mos6502.
Apparently unaffected ports: pdk, stm8, z80 and related.
Test fails to link: ds390.
P.S.: Apparently, the bug does not happen when using --stack-auto.
Related
Commit: [r14440]
Last edit: Philipp Klaus Krause 2023-11-18
The code looks already wrong in dumpraw0, i.e. when iCode is first generated; apparently the bug happens in the conversion from AST to iCode.
P.S.: I think in src/SDCCicode.c, in geniCodeParms, this case:
Is the one where we run into the bug. I suspect that iCodes for the memcpy helper function call are inserted in the wrong place.
P.P.S.: At that point the iCode chain does only exist as an SDCCset (created via ADDTOCHAIN), making it harder to insert iCodes at a specific place.
Last edit: Philipp Klaus Krause 2023-11-18
Fixed in [r14443]. Quite a hackish fix, but apparently, it works. Maybe we can find a cleaner solution one day.
Related
Commit: [r14443]