Christopher Bazley

After fixing genPointerPush() in mcs51/gen/c in [r17044] the test now fails the ASSERTs. @maartenbrock Unfortunately, I don't have the time or the expertise to investigate those assertion failures today, but I did ask Codex to do so and it produced the attached candidate patch, with the following explanation: getFreePtr saves a scratch pointer register on the hardware stack during IPUSH_VALUE_AT_ADDRESS, interleaving the saved register with outgoing argument bytes. Treat that instruction like IPUSH...

I don't have the time nor the expertise to investigate this today, but I did ask Codex to do so and it produced the attached candidate patch, with the following explanation: The failure occurs in genCopy, including with --no-peep. A register-copy cycle involving A attempts to use A as scratch storage while its original byte is still needed. Save that byte on the stack and finish its move last. This candidate changes no peephole rules. Baseline: common compiler sources r17043, Z80 generator identical...

(I'm not sure special treatment of _Atomic is justified given that SDCC does not yet support such types, but it does no obvious harm.)

(I'm not sure special treatment of _Atomic is justified given that SDCC does not yet support such types, but it does no obvious harm.

Attaching a candidate fix for this issue, created by Codex. It reuses the freshly checked member load, fixing both member positions while preserving warnings after potentially invalidating writes and calls. Bitfields are special-cased because two fields can share the same address but require different bit extraction. All six diagnostic configurations and the full Z80 runtime suite passed: 37164 tests, 0 failures. Focused runtime tests also passed on 65C02, STM8 and MCS51. @spth please would you be...

Execution on snapshot r17038 confirms that the valid function-pointer example still hits the internal compiler error in C11 mode.

Execution on snapshot r17038 confirms the member stays 43 instead of becoming 41.

Execution on snapshot r17038 confirms the false warning, but calculates 233 correctly.