https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88589
--- Comment #5 from Lionel Debroux <lionel_debroux at yahoo dot fr> --- Thanks for your tests. On my side, with Debian 9's m68k-elf-gcc: * the ICE reproduces just fine when using -Os but not when using -O2; * when the cause of the ICE is commented out, the wrong codegen for the line between the two nops also reproduces when using either -Os or -O2. Well, I guess I'll have to build upstream GCC... later :) I chose -Os because the smaller the ROM dumper, the lower its RAM consumption. Understood about -mshort. It's been the default in GCC4TI and its dead ancestor since the early 2000s, since that's what the target platform's OS (AMS for TI-68k calculators) uses. As such, it received downstream validation on multiple GCC major versions and thousands of programs over the years. However, said downstream is a franken-GCC for m68k-coff, latest version 4.1.2 (!), carrying a significant set of changes over upstream GCC, so tests there clearly do not carry to any upstream version... Changes in the GCC patch range from features (register parameter passing, register-relative addressing, support for a custom floating-point format, etc.) and optimization tweaks to upstream reverts, e.g. the sudden horrible pessimization (ISTR one program's size jumping up dozens of KBs to well over 64 KB, the limit on that OS) of code using formerly global "cast constructors" / "compound literals", a popular idiom for that environment. Obviously, GCC4TI's ~15-year-old heavily patched GCC 4.1, and companion tools inherited from the dead ancestor (patched binutils, see e.g. https://sourceware.org/bugzilla/show_bug.cgi?id=1198 ; .s patcher to complement partial changes in GCC; full-custom optimizing linker with support for the AmigaOS object file format unsupported by binutils), are increasingly hard to support on modern platforms, for an ever lowering number of users of the target platform. That's why I wanted to get libticalcs rid of the dependency on GCC4TI for a while, and Debian packaging m68k-elf binutils+GCC gave me a path to that aim... or so I thought :) By the end of 2018, several days after I posted this bug report, I had finished rewriting libticalcs' TI-68k ROM dumper in pure assembly, using GCC4TI GCC's output as a starting point, so that there's only a dependency on stock / distro binutils.
