[Debian-lego-team] FYI: GCC 15 appears to generate faulty h8300-hitachi-coff cross-compiler binaries

[Matthew Sheets]

> Are you able to make a isolated test case?

The most I have been able to reduce this thus far is to GCC-15 creating faulty -O2 optimizations.  If I specify -O (instead of the usual -O2) in the CFLAGS passed to configure, the cc1plus-3.4.6 built by GCC-15 with -O is able to complete its tasks within the larger h8300-hitachi-coff cross-toolchain build without error.

A challenge in trying to narrow the scope is determining what GCC-15 did differently when building cc1plus-3.4.6 compared to what prior GCC versions (like GCC-13 with -O2) did when building cc1plus-3.4.6.  In its compiled form, cc1plus-3.4.6 is over 14 MB, which is rather broad in scope and certainly not approaching the "Detailed Bug Reporting Instructions" for GCC that request a "minimal testcase" and (in the case of miscompilation) the steps that begin with identification of the bad *.o file(s).
 * https://gcc.gnu.org/bugs

What I have been able to determine thus far through adding some debug code is that the specific configure code-check failure happens when a "VOID_TYPE" type makes in via the first argument passed to the "grokdeclarator" function in gcc-3.4.6/gcc/cp/decl.c.  That "VOID_TYPE" is not handled in the main case statement and thus falls all the way through to the default case, where an assert failure that triggers the ICE in cc1plus-3.4.6 is thrown (c.f. the line of code at the link below).
* https://github.com/BrickBot/GNU-Legacy-Toolchain/blob/v1.1.2/src-projects/gcc-3.4.6/gcc/cp/decl.c#L6783

With "--enable-sjlj-exceptions" passed to configure and "--keep-going" passed to make, numerous other types that shouldn't be getting passed in the chain to "grokdeclarator" being caught there and throwing errors.

> Is the ICE reported to the BTS for the GCC maintainers to have a look?

Nothing in the GCC-15 toolchain itself is throwing any Internal Compiler Errors under any of these scenarios, so there is no ICE to report for GCC-15.  There are two distinct compilers at play here: the GCC-3.4.6 cross-compiler and the GCC-15 compiler being used to build the GCC-3.4.6 cross-compiler.  The newly-surfaced ICEs are only in a GCC-15-with-O2-built cc1plus-3.4.6 cross-compiler.

> what happen if you run configure with --enable-sjlj-exceptions to
> force the use of such exceptions?

cc1plus-3.4.6 as built by GCC-15-with-O2 appears to just completely blow up if the configure code-check is skipped and "--keep-going" is enabled for Make.  In attempting to build some of the library code associated with the h8300-hitachi-coff cross-toolchain, multiple different exceptions beyond those previously reported are encountered as cc1plus-3.4.6 as built by GCC-15 with -O2.  Segmentation faults and errors that cc1plus-3.4.6 describes as "not reproductible, so it is likely a hardware or OS problem" (though here it is rather apparent that GCC-15 with -O2 is the problem).  Effectively, cc1plus-3.4.6 as built by GCC-15 with -O2 appears wholly unusable.

> Perhaps gcc-15 reject the invalid C/C++ code and this cause the test to fail?

At the point of the configure test failure, GCC-15 is not being invoked, so there is not even opportunity for GCC-15 to reject anything; everything at this point is with the GCC-3.4.6 cross-compiler (specifically cc1plus-3.4.6) that was previously built by GCC-15 with -O2.  The configure failure promulgates from a failure in cc1plus-3.4.6, so apart from GCC-15-with-O2 having built in a prior step the cc1plus-3.4.6 that is now failing, none of the more modern GCC compilers (12, 13, 15, etc.) appear to have anything directly to do with the compilation of the code snippet in question.  If instead building cc1plus-3.4.6 using either GCC-13 or GCC-15-with-O, everything is fine here.


I'm not aware of any other communities where there is at least semi-active use and discussion of legacy toolchains such as GCC-3.4.6, so that was part of my reason for posting here first….  :-)


Thank you,
Matthew