#3793 pic16 libm build fails

[Philipp Klaus Krause]

As mentioned by Erik on the sdcc-devel mailing list (https://sourceforge.net/p/sdcc/mailman/message/58836336/), there is an issue with the pic16 library. I can reproduce it on Debian GNU/Linux testing on amd64 and powerpc64, which uses gputils 1.4.0:

ldexpf.asm:111:Error[1102]   Parser error: syntax error
ldexpf.asm:162:Error[1102]   Parser error: syntax error
ldexpf.asm:188:Error[1102]   Parser error: syntax error

I don't remember any recent changes to the pic16 port, so this was likely some change in machine-independent parts of SDCC that triggers a preexisting pic16 issue.

[Philipp Klaus Krause]

Despite this being an issue only affecting the unmaintained pic16 port, it is still a serious issue, since if we can't fix ii, the next release won't have a pic16 port at all.

[Philipp Klaus Krause]

In [r15064], I implemented a workaround: disabling the optimization that triggers the pic16 issue.

[zeynelsagcan]

I investigated this issue using SDCC r15063 and PIC18F452.

I was able to reproduce the compiler failure with ldexpf.c and then reduce it to a small standalone regression test.

The investigation points to optimizeFinalCast() in SDCCopt.c. When the address attribute of the replacement operand is not preserved, the PIC16 backend receives an incorrect operand representation and generates invalid addressing code.

In particular, preserving:

op->isaddr = uic->left->isaddr;`

is essential.

I verified this through controlled compiler builds:

• A: compiler SIGSEGV.
• B: successful compilation and valid PIC18 assembly.
• D: disabling optimizeFinalCast() avoids the failure.
• E: removing only the isaddr assignment reproduces the SIGSEGV, with the same iCode as A across six stages.

The regression test also reproduces the failure in A and E, while B compiles successfully. The resulting B assembly was accepted by gpasm.

I have prepared a small regression test, bug-optimizeFinalCast-isaddr.c, which I can attach here.

I also identified a separate out-of-bounds access involving immdmod[3] in src/pic16/pcode.c. I will report that backend issue separately to keep this ticket focused on the original ldexpf failure.