From: WongCK <won...@ya...> - 2024-06-02 13:10:14
|
Great work !!Hope you still have sometime left in your weekend to enjoy.... in some other way. On Sunday, 2 June 2024 at 08:21:19 pm SGT, Thorsten Otto <ad...@th...> wrote: Phew, i think i found it. Seems the bug was introduced by https://github.com/th-otto/m68k-atari-mint-gcc/commit/04c9cf5c786b94fbe3f6f21f06cae73a7575ff7a which implements a new optimization pass. Luckily, that optimization can be turned off by -ffold-mem-offsets. This is only in gcc-14.1.0, not in gcc-13.3.0 (but may eventually appear in the next release). It also explains why that bug only crashed the native compiler, not the cross-compiler. It has however the consequence that the als the cross-compiler generates wrong code in certain cases (eg. when compiling itself). In this case, the code around https://github.com/th-otto/m68k-atari-mint-gcc/blob/c9e3ffbc4ef9bcaaee9cbaeeeeed75df8ca459ea/gcc/tree-switch-conversion.cc#L1560-L1569 Was compiled into something that caused the assignment test[k].target_bb = n->m_case_bb to be miscompiled, and the outer loop would not find it, making new entries until the array overflows. - conclusion 1: we should think about adding --enable-checking=misc to our build scripts. That adds some assert checking, making the compiler slightly slower, but would catch such overflows which may or may not cause a bus-error. - conclusion 2: we need to find some way to test the compiler. Compiling it by itself would be a first step, but was not enough in this case (the cross-compiler could compile itself, but generates wrong code that caused only trouble when running the m68k executable). Obviously there is no easy way to test the native compiler, maybe qemu or aranym can help here. I'm currently doing some last tests, then recompiling all gcc-14 versions. Keep fingers crossed. _______________________________________________ Freemint-discuss mailing list Fre...@li... https://lists.sourceforge.net/lists/listinfo/freemint-discuss |