bug#46495: 28.0.50; [native-comp] Build fails for 32bit --with-wide-int

[Andy Moreton <andrewjmoreton@gmail.com>]

On Wed 17 Feb 2021, Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote:

> Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of
> text editors" <bug-gnu-emacs@gnu.org> writes:
>
>> Andy Moreton <andrewjmoreton@gmail.com> writes:
>>
>>> On Tue 16 Feb 2021, Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote:
>>>
>>>> Andy could you point out the two libgccjit versions you used specifying
>>>> wich one was used in the successfull / failed experiment?
>>>
>>> It seems they both now fail (and I have lost the build log from the
>>> successful experiment, so I don't have a note of the commit used).
>>
>> That's odd.  The culprit of the bug I've isolated is a crash in
>> libgccjit so should be easy to recognize (we should never crash in
>> libgccjit).
>>
>> Anyway I've an half cooked patch to work around this issue, I guess I'll
>> test it this evening.
>
> A fix like the attached is working around the GCC bug.
>
> The only annoyance of this approach is that libgccjit for each
> compilation is outputting to console:
> "libgccjit.so: note: disable pass tree-isolate-paths for functions in the range of [0, 4294967295]"
>
> We probably also want to check at configure time and raise an error in
> case configuring --with-nativecomp --with-wide-int but with a (really)
> old libgccjit that does not provide
> 'gcc_jit_context_add_command_line_option'.
>
> Works for me bootstraping Emacs on i686-pc-linux-gnu + GCC10 but I can't
> test the Windows side, Andy would you mind giving it a try?

I tried doing clean builds (after "git clean -xdf" each time ) both
without and then with this patch. The i686-pc-mingw32 toolchain is:
   gcc version 9.2.0 (MinGW.org GCC Build-2).

Without your patch, the i686-pc-mingw32 build succeeded. As I have seen
some builds succeed and some fail, there is perhaps another issue to
look into after this one.

With your patch, the i686-pc-mingw32 build succeeded. Running the
resulting emacs still produced some crashes in the async compile processes.

Program received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 6952.0x1e8c]
0x757bff43 in KERNELBASE!DebugBreak () from C:\WINDOWS\System32\KernelBase.dll
#0  0x757bff43 in KERNELBASE!DebugBreak () from C:\WINDOWS\System32\KernelBase.dll
#1  0x012d2778 in emacs_abort () at c:/emacs/git/emacs/native/src/w32fns.c:10914
#2  0x0112509c in terminate_due_to_signal (sig=11, backtrace_limit=40) at c:/emacs/git/emacs/native/src/emacs.c:416
#3  0x01158fd2 in handle_fatal_signal (sig=11) at c:/emacs/git/emacs/native/src/sysdep.c:1762
#4  0x01158fac in deliver_thread_signal (sig=11, handler=0x1158fb9 <handle_fatal_signal>) at c:/emacs/git/emacs/native/src/sysdep.c:1754
#5  0x01159007 in deliver_fatal_thread_signal (sig=11) at c:/emacs/git/emacs/native/src/sysdep.c:1774
#6  0x010010d1 in __register_frame_info ()
#7  0x012d2693 in my_exception_handler (exception_data=0xbfc764) at c:/emacs/git/emacs/native/src/w32fns.c:10862
#8  0x7581e6e2 in UnhandledExceptionFilter () from C:\WINDOWS\System32\KernelBase.dll
#9  0x00bfc764 in ?? ()
#10 0x77364c91 in ntdll!RtlCaptureStackContext () from C:\WINDOWS\SYSTEM32\ntdll.dll
#11 0x77327684 in ntdll!RtlGetAppContainerNamedObjectPath () from C:\WINDOWS\SYSTEM32\ntdll.dll
#12 0x00000000 in ?? ()