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

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> 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.

Didn't had the time to follow this thread carefully, but I think would
be interesting to know if someone did try a native compiled Emacs on GCC
13.1.

  Andrea