GNU bug report logs -
#46495
28.0.50; [native-comp] Build fails for 32bit --with-wide-int
Previous Next
Full log
View this message in rfc822 format
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 <at> gnu.org> writes:
>
>> Andy Moreton <andrewjmoreton <at> 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 ?? ()
This bug report was last modified 4 years and 43 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.