#3619 SDCC 4.3.0 compiler generate undocumented Z80 instructions

[Aoineko]

Hi,

When compiling one of my sample with SDCC 4.3.0, an undocumented Z80 instructions is generated (ld b, iyh) but the compiler (assembler in fact) complain about it and ends with an error: <a> Invalid Addressing Mode.

My command line:

MSXgl\tools/sdcc/bin/sdcc -c -mz80 --vc -DTARGET=TARGET_ROM_48K_ISR -DMSX_VERSION=MSX_2 -IMSXgl\projects\samples/ -IMSXgl\engine/src -IMSXgl\engine/content -IMSXgl\tools/  --opt-code-speed --debug -DAPPSIGN ./s_gm3.c -o MSXgl\projects\samples/out/

The generated assembler file and the source file are attached (assembler generated with --fverbose-asm option).

The --allow-undocumented-instructions option allow sample to be compiled.

The problem here seems to be double:
* SDCC should not generate undocumented instructions without the user having explicitly requested them (on the other hand, it's good to be able to do so).
* The assembler should be able to compile code containing undocumented instructions.

[Aoineko]

SDCC version: 4.3.0 #14184 (MINGW64)
The source file:

[Aoineko]

Do you have any idea when this bug might be fixed? It's a blocker so I can release a version of my library that supports SDCC 4.3.0 (the compilation will fail every time an undocumented instruction is generated by mistake).

Forcing support for undocumented instructions (using --allow-undocumented-instructions) is a workaround, but some users are pretty picky about standards compliance and I can't force them to have code containing undocumented instructions.

[Philipp Klaus Krause]

I was busy with other stuff until yesterday, but I intend to look into SDCC bugs again this and next week. The main goal will be to get more regression tests to pass in the farm, but I'll also look into this one.

[Aoineko]

Thank you for your time. That's great news.

However, I've found another problem that I'll explain in another thread: the size of the files generated by SDCC 4.3.0 is significantly larger than those generated with SDCC 4.2.0 (with identical parameters).

[Philipp Klaus Krause]

Fixed in [r14238].

If you want the stability of 4.3.0, you might want to backport the fix: Since 4.3.0 there were quite some changes in SDCC that result in better optimization, but of course come with a risk of having introduced new bugs.

[Aoineko]

Thanks for the (fast) fix.

What do you means by "backport"?

[Philipp Klaus Krause]

By "backport" I meant to take the diff of my commit, and apply it to the 4.3.0 source. Depending on your requirements doing so might or might not make sense for you.

[Aoineko]

Are you planning to release an SDCC 4.3.1 version at some point with fixes for this kind of bug?

[Philipp Klaus Krause]

SDCC usually does one release per calender year. X.Y.0. While we sometimes tag X.Y.Z, Z != 0 those are not considered stable releases, and all tags (stable release or not) are done on trunk. The 4.3.1 tag has already been created (and the fix for this bug was not yet in trunk at the time of the tag creation). There will be a 4.3.2 tag on trunk later this year, once a few more genconstprop bugs have been fixed.

[Aoineko]

Just to be sure.
Do you means that there will not be any "stable" version of SDCC that include this bug fix before 4.4.0 version next year?
This bug is a major issue for my MSXgl library as it prevents certain programs from being compiled at all. As it is, I can't release a version of the library and tool suite that includes SDCC 4.3.0.
Nor am I comfortable compiling SDCC myself to include just this fix. I have no experience in this, especially for Linux and macOS.

Anyway, there's also the problem of program size to deal with before considering leaving SDCC 4.2.0 for a new version.

[Philipp Klaus Krause]

The next official stable version will most likely be 4.4.0, I hope in January 2024. There is still some work to do before that: IMO, we can't do a stable release before fixing at least [bugs:#3628], [bugs:#3617] and [bugs:#3634].
If you don't want to compile yourself: We have precompiled nightly snapshots: https://sdcc.sourceforge.net/snap.php but their stability varies.