bug#63365: 30.0.50; GCC 13.1 breaks building Emacs with native-compilation

[Eli Zaretskii]

> From: András Svraka <svraka.andras@gmail.com>
> Date: Thu, 1 Jun 2023 09:37:26 +0200
> Cc: Eli Zaretskii <eliz@gnu.org>,
>  Arash Esbati <arash@gnu.org>,
>  akrl@sdf.org
> 
> Thread 1 (Thread 6872.0xb48):
> #0  0x00007ffc3a8911c4 in win32u!NtUserWaitMessage () from 
> C:\Windows\System32\win32u.dll
> #1  0x00007ffc3cbfb25c in USER32!EndDialog () from 
> C:\Windows\System32\user32.dll
> #2  0x00007ffc3cbfb797 in USER32!EndDialog () from 
> C:\Windows\System32\user32.dll
> #3  0x00007ffc3cc1ef66 in USER32!SoftModalMessageBox () from 
> C:\Windows\System32\user32.dll
> #4  0x00007ffc3cc1d8a1 in USER32!DrawStateA () from 
> C:\Windows\System32\user32.dll
> #5  0x00007ffc3cc1e695 in USER32!MessageBoxTimeoutW () from 
> C:\Windows\System32\user32.dll
> #6  0x00007ffc3cc1e488 in USER32!MessageBoxTimeoutA () from 
> C:\Windows\System32\user32.dll
> #7  0x00007ffc3cc1e09e in USER32!MessageBoxA () from 
> C:\Windows\System32\user32.dll
> #8  0x00007ff6747977d5 in emacs_abort ()
> #9  0x00007ff674696308 in terminate_due_to_signal ()
> #10 0x00007ff6746af949 in deliver_fatal_thread_signal ()

This means Emacs crashed during native compilation, and is waiting for
"someone" to respond to the Abort dialog.  Since you are running CI
unattended, it might be a good idea to modify lisp/Makefile to pass

  --eval '(setq w32-disable-abort-dialog t)'

option on the batch compilation command line.

Why Emacs crashed is a separate issue:

> #11 0x00007ff6747f4992 in _gnu_exception_handler (exception_data=0x121dfa2d0) 
> at C:/M/B/src/mingw-w64/mingw-w64-crt/crt/crt_handler.c:213
> #12 0x00007ffc3a7c55f0 in ucrtbase!__C_specific_handler () from 
> C:\Windows\System32\ucrtbase.dll
> #13 0x00007ffc3d2643af in ntdll!.chkstk () from C:\Windows\SYSTEM32\ntdll.dll
> #14 0x00007ffc3d1f170e in ntdll!RtlVirtualUnwind2 () from 
> C:\Windows\SYSTEM32\ntdll.dll
> #15 0x00007ffc3d2633be in ntdll!KiUserExceptionDispatcher () from 
> C:\Windows\SYSTEM32\ntdll.dll
> #16 0x00007ff6747359d1 in print_object ()
> #17 0x00007ff6747373a1 in Fprin1_to_string ()
> #18 0x00007ffc0e2c267b in 
> F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_9 (par_0=0x19dd0292503, 
> par_1=<optimized out>) from 
> c:\_\B\src\build-UCRT64\native-lisp\28.2-16aa216e\byte-opt-9c5f25f5-718f7647.eln
> #19 0x00007ff67471640f in Ffuncall ()
> #20 0x00007ffc0e2c4007 in 
> F627974652d6f7074696d697a652d666f726d_byte_optimize_form_0 (par_0=<optimized 
> out>, par_1=0x0) from 
> c:\_\B\src\build-UCRT64\native-lisp\28.2-16aa216e\byte-opt-9c5f25f5-718f764--Type
>  <RET> for more, q to quit, c to continue without paging--c
> 7.eln

This tells that the crash was inside print_object, which was called by
prin1-to-string, probably because Emacs tried to print some invalid
Lisp object.  Since there are no line numbers in the backtrace, I
cannot tell more.

I also understand that the crash is avoided by using lower
optimization levels, and perhaps other non-default GCC options could
be involved.  So the jury is still out on whether this is an Emacs bug
or a (MinGW) GCC bug.

Thanks.