msys2
Possible problems with GCC's -foptimize-sibling-calls implementation
See #17549 / #17374. The -foptimize-sibling-calls optimization (which is enabled by default with -O2) breaks the mingw-w64-emacs build when --with-native-compilation is passed to the configure script. Could there be something wrong with its implementation in mingw-w64-gcc?
Just to note, currently no other MINGW patches packages turn off -foptimize-sibling-calls, although some packages might do that upstream, e.g. grepping in MINGW-packages I found OpenBLAS, although they've been doing it for years for seemingly different reason, so presumably it's unrelated to this issue.
Also, AFAIK MINGW packages are not tested by rebuilding after compiler and toolchain upgrades, and -foptimize-sibling-calls didn't cause any problems on GCC 12. So can expect more similar issues popping up as packages are built on GCC 13?
might be an ICE with gcc-13 should probably report it upstream just in case.
in the meantime a small fix like -fno-optimize-sibling-calls in flags should do the trick for emacs i reckon ?.
An upstream bug report has now been filed:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115132
The problem is that the -foptimize-sibling-calls optimization messes up the use of __builtin_unwind_init. It is not yet clear if it is a bug in GCC or a misuse of __builtin_unwind_init. Regardless, the issue has now been patched in Emacs:
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=19c983ddedf083f82008472c13dfd08ec94b615f