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

classic Classic list List threaded Threaded
68 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

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

Andy Moreton-3
On Windows with the mingw64 32bit toolchain, the native branch build
fails when configured with "--with-nativecomp --with-wide-int".

Emacs crashes during .eln compilation. Attaching gdb to the crashing
emacs process does not produce a backtrace.

I suspect that this problem may not be Windows-specific, and should be
reproducable on Linux, but I have not tried that.

     AndyM



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
> From: Andy Moreton <[hidden email]>
> Date: Sat, 13 Feb 2021 17:57:09 +0000
>
> On Windows with the mingw64 32bit toolchain, the native branch build
> fails when configured with "--with-nativecomp --with-wide-int".
>
> Emacs crashes during .eln compilation. Attaching gdb to the crashing
> emacs process does not produce a backtrace.

What does GDB produce if you attach it?

Can you run a compilation from Emacs that runs under GDB?



Reply | Threaded
Open this post in threaded view
|

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

Andy Moreton-3
In reply to this post by Andy Moreton-3
On Sat 13 Feb 2021, Eli Zaretskii wrote:

>> From: Andy Moreton <[hidden email]>
>> Date: Sat, 13 Feb 2021 17:57:09 +0000
>>
>> On Windows with the mingw64 32bit toolchain, the native branch build
>> fails when configured with "--with-nativecomp --with-wide-int".
>>
>> Emacs crashes during .eln compilation. Attaching gdb to the crashing
>> emacs process does not produce a backtrace.
>
> What does GDB produce if you attach it?

Nothing - the windows tra handler, followed by gdb deciding that
something has died and giving up completely.

> Can you run a compilation from Emacs that runs under GDB?

How do I do that in a way that captures only the relevant subprocesses ?

   AndyM




Reply | Threaded
Open this post in threaded view
|

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

Andy Moreton-3
In reply to this post by Andy Moreton-3
On Sat 13 Feb 2021, Andy Moreton wrote:

> On Windows with the mingw64 32bit toolchain, the native branch build
> fails when configured with "--with-nativecomp --with-wide-int".
>
> Emacs crashes during .eln compilation. Attaching gdb to the crashing
> emacs process does not produce a backtrace.
>
> I suspect that this problem may not be Windows-specific, and should be
> reproducable on Linux, but I have not tried that.

I have also tried the mingw.org 32bit toolchain (i686-pc-mingw32) when
configured with with "--with-nativecomp --with-wide-int", and that
works.

Thus this bug seems to be a problem with the MSYS2 mingw32 32bit
toolchain (i686-w64-mingw32) only.

    AndyM




Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
> From: Andy Moreton <[hidden email]>
> Date: Sun, 14 Feb 2021 13:24:32 +0000
>
> > I suspect that this problem may not be Windows-specific, and should be
> > reproducable on Linux, but I have not tried that.
>
> I have also tried the mingw.org 32bit toolchain (i686-pc-mingw32) when
> configured with with "--with-nativecomp --with-wide-int", and that
> works.

Thanks, that's good news.

> Thus this bug seems to be a problem with the MSYS2 mingw32 32bit
> toolchain (i686-w64-mingw32) only.

It does seem that way, although I wonder what could that problem be...



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
In reply to this post by Andy Moreton-3
> From: Andy Moreton <[hidden email]>
> Date: Sat, 13 Feb 2021 20:23:20 +0000
>
> > Can you run a compilation from Emacs that runs under GDB?
>
> How do I do that in a way that captures only the relevant subprocesses ?

That's "set follow-exec-mode" in GDB, but I don't know if it works on
Windows.



Reply | Threaded
Open this post in threaded view
|

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

Emacs - Bugs mailing list
In reply to this post by Eli Zaretskii
Eli Zaretskii <[hidden email]> writes:

>> From: Andy Moreton <[hidden email]>
>> Date: Sun, 14 Feb 2021 13:24:32 +0000
>>
>> > I suspect that this problem may not be Windows-specific, and should be
>> > reproducable on Linux, but I have not tried that.
>>
>> I have also tried the mingw.org 32bit toolchain (i686-pc-mingw32) when
>> configured with with "--with-nativecomp --with-wide-int", and that
>> works.
>
> Thanks, that's good news.
>
>> Thus this bug seems to be a problem with the MSYS2 mingw32 32bit
>> toolchain (i686-w64-mingw32) only.
>
> It does seem that way, although I wonder what could that problem be...

Well... I can confirm also i686-pc-linux-gnu "--with-nativecomp
--with-wide-int" looks broken for me.

I'm going to look into this the coming week.

  Andrea



Reply | Threaded
Open this post in threaded view
|

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

Andy Moreton-3
In reply to this post by Andy Moreton-3
On Sun 14 Feb 2021, Eli Zaretskii wrote:

>> From: Andy Moreton <[hidden email]>
>> Date: Sun, 14 Feb 2021 13:24:32 +0000
>>
>> > I suspect that this problem may not be Windows-specific, and should be
>> > reproducable on Linux, but I have not tried that.
>>
>> I have also tried the mingw.org 32bit toolchain (i686-pc-mingw32) when
>> configured with with "--with-nativecomp --with-wide-int", and that
>> works.
>
> Thanks, that's good news.
>
>> Thus this bug seems to be a problem with the MSYS2 mingw32 32bit
>> toolchain (i686-w64-mingw32) only.
>
> It does seem that way, although I wonder what could that problem be...

I have only just discovered this news item:

https://www.msys2.org/news/#2020-05-17-32-bit-msys2-no-longer-actively-supported

Perhaps that means that only the mingw.org (i686-w64-mingw32) toolchain
should be supported for 32bit builds on Windows.

    AndyM




Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
On February 15, 2021 11:01:19 AM GMT+02:00, Andy Moreton <[hidden email]> wrote:

> On Sun 14 Feb 2021, Eli Zaretskii wrote:
>
> >> From: Andy Moreton <[hidden email]>
> >> Date: Sun, 14 Feb 2021 13:24:32 +0000
> >>
> >> > I suspect that this problem may not be Windows-specific, and
> should be
> >> > reproducable on Linux, but I have not tried that.
> >>
> >> I have also tried the mingw.org 32bit toolchain (i686-pc-mingw32)
> when
> >> configured with with "--with-nativecomp --with-wide-int", and that
> >> works.
> >
> > Thanks, that's good news.
> >
> >> Thus this bug seems to be a problem with the MSYS2 mingw32 32bit
> >> toolchain (i686-w64-mingw32) only.
> >
> > It does seem that way, although I wonder what could that problem
> be...
>
> I have only just discovered this news item:
>
> https://www.msys2.org/news/#2020-05-17-32-bit-msys2-no-longer-actively-supported
>
> Perhaps that means that only the mingw.org (i686-w64-mingw32)
> toolchain
> should be supported for 32bit builds on Windows.
>
>     AndyM

Right, but Andrea said there were problems on Posix systems as well with this configuration, so it could be that something else is at work here.



Reply | Threaded
Open this post in threaded view
|

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

Emacs - Bugs mailing list
Eli Zaretskii <[hidden email]> writes:

> On February 15, 2021 11:01:19 AM GMT+02:00, Andy Moreton <[hidden email]> wrote:
>> On Sun 14 Feb 2021, Eli Zaretskii wrote:
>>
>> >> From: Andy Moreton <[hidden email]>
>> >> Date: Sun, 14 Feb 2021 13:24:32 +0000
>> >>
>> >> > I suspect that this problem may not be Windows-specific, and
>> should be
>> >> > reproducable on Linux, but I have not tried that.
>> >>
>> >> I have also tried the mingw.org 32bit toolchain (i686-pc-mingw32)
>> when
>> >> configured with with "--with-nativecomp --with-wide-int", and that
>> >> works.
>> >
>> > Thanks, that's good news.
>> >
>> >> Thus this bug seems to be a problem with the MSYS2 mingw32 32bit
>> >> toolchain (i686-w64-mingw32) only.
>> >
>> > It does seem that way, although I wonder what could that problem
>> be...
>>
>> I have only just discovered this news item:
>>
>> https://www.msys2.org/news/#2020-05-17-32-bit-msys2-no-longer-actively-supported
>>
>> Perhaps that means that only the mingw.org (i686-w64-mingw32)
>> toolchain
>> should be supported for 32bit builds on Windows.
>>
>>     AndyM
>
> Right, but Andrea said there were problems on Posix systems as well with this configuration, so it could be that something else is at work here.

Confirm, I see a problem compiling closures, this should be the
responsible for the bootstrap to be broken (at least on my case).

Yesterday I've already reduced a small reproducer so I should be on the
good way to understand during the next debug session why this is
happening only on wide-int.

It will be interesting why is working in some configuration and not in
others.

  Andrea



Reply | Threaded
Open this post in threaded view
|

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

Emacs - Bugs mailing list
Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <[hidden email]> writes:

> Eli Zaretskii <[hidden email]> writes:
>
>> On February 15, 2021 11:01:19 AM GMT+02:00, Andy Moreton <[hidden email]> wrote:
>>> On Sun 14 Feb 2021, Eli Zaretskii wrote:
>>>
>>> >> From: Andy Moreton <[hidden email]>
>>> >> Date: Sun, 14 Feb 2021 13:24:32 +0000
>>> >>
>>> >> > I suspect that this problem may not be Windows-specific, and
>>> should be
>>> >> > reproducable on Linux, but I have not tried that.
>>> >>
>>> >> I have also tried the mingw.org 32bit toolchain (i686-pc-mingw32)
>>> when
>>> >> configured with with "--with-nativecomp --with-wide-int", and that
>>> >> works.
>>> >
>>> > Thanks, that's good news.
>>> >
>>> >> Thus this bug seems to be a problem with the MSYS2 mingw32 32bit
>>> >> toolchain (i686-w64-mingw32) only.
>>> >
>>> > It does seem that way, although I wonder what could that problem
>>> be...
>>>
>>> I have only just discovered this news item:
>>>
>>> https://www.msys2.org/news/#2020-05-17-32-bit-msys2-no-longer-actively-supported
>>>
>>> Perhaps that means that only the mingw.org (i686-w64-mingw32)
>>> toolchain
>>> should be supported for 32bit builds on Windows.
>>>
>>>     AndyM
>>
>> Right, but Andrea said there were problems on Posix systems as well with this configuration, so it could be that something else is at work here.
>
> Confirm, I see a problem compiling closures, this should be the
> responsible for the bootstrap to be broken (at least on my case).
>
> Yesterday I've already reduced a small reproducer so I should be on the
> good way to understand during the next debug session why this is
> happening only on wide-int.
>
> It will be interesting why is working in some configuration and not in
> others.
>
>   Andrea

Andy could you point out the two libgccjit versions you used specifying
wich one was used in the successfull / failed experiment?

Thanks

  Andrea



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
> From: Andrea Corallo <[hidden email]>
> Cc: Eli Zaretskii <[hidden email]>, [hidden email],
>         [hidden email]
> Date: Tue, 16 Feb 2021 09:34:49 +0000
>
> Andy could you point out the two libgccjit versions you used specifying
> wich one was used in the successfull / failed experiment?

Right, this is another potential reason for the difference.  AFAIK,
MinGW64 uses GCC 10.x, whereas mingw.org uses 9.2.



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
> From: Andrea Corallo <[hidden email]>
> Cc: [hidden email], [hidden email]
> Date: Tue, 16 Feb 2021 16:30:46 +0000
>
> I did some GCC debugging (the crash is there) using my reduced
> reproducer and clearly look (for my case at least) this is a libgccjit
> bug that we trigger only generating code for 32bit wide-int.

So GCC 10 has a bug when it generates code which manipulates 64-bit
integers, is that what you are saying?

> GCC trunk is broken but as you've anticipated 9 is working (just
> finished an Emacs bootstrap).

Thanks, this is good to know.  I think we should add an entry to
etc/PROBLEMS about this.

Does the buggy behavior of GCC 10 happen regardless of optimization
level?

> This evening I'll open a bug on the GCC bugzilla and link it here.
> Would be nice to fix it before the end of stage4... :/

Thanks.



Reply | Threaded
Open this post in threaded view
|

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

Emacs - Bugs mailing list
Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <[hidden email]> writes:

> Eli Zaretskii <[hidden email]> writes:
>
>>> From: Andrea Corallo <[hidden email]>
>>> Cc: [hidden email], [hidden email]
>>> Date: Tue, 16 Feb 2021 16:30:46 +0000
>>>
>>> I did some GCC debugging (the crash is there) using my reduced
>>> reproducer and clearly look (for my case at least) this is a libgccjit
>>> bug that we trigger only generating code for 32bit wide-int.
>>
>> So GCC 10 has a bug when it generates code which manipulates 64-bit
>> integers, is that what you are saying?
>
> It's not strictly related to the integer size.  On 32bit wide-int we
> indeed we generate significantly different code respect to 64bit.  For
> one case of this GCC manage to prove that a piece of code will deference
> a null pointer (this code in reality is unreachable) and tries to add a
> call to __builtin_trap () in place.  Unfortunately the libgccjit
> front-end is not initializing this built-in declaration.  This is as far
> as I've analyzed the problem for now.
>
>>> GCC trunk is broken but as you've anticipated 9 is working (just
>>> finished an Emacs bootstrap).
>>
>> Thanks, this is good to know.  I think we should add an entry to
>> etc/PROBLEMS about this.
>
> Will do, still wants to try 10 to be sure.
>
>> Does the buggy behavior of GCC 10 happen regardless of optimization
>> level?
>
> I think -O0 should spot this as copy-prop is not running.  We might have
> a better (more narrowed) ways to work around this but I need to
> investigate more.  Will follow-up.
>
>>> This evening I'll open a bug on the GCC bugzilla and link it here.
>>> Would be nice to fix it before the end of stage4... :/
>>
>> Thanks.
>
> Welcome
>
>   Andrea

Here the bugzilla bug with some description more:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99126

I think a good work-around might be to try to switch off the
'isolate-paths' pass.

  Andrea



Reply | Threaded
Open this post in threaded view
|

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

Andy Moreton-3
In reply to this post by Andy Moreton-3
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).

mingw.org (i686-w64-mingw32)
----------------------------
I retried the mingw.org build configured with "--with-nativecomp
--with-wide-int" (starting from "git clean -xdf"), and that now fails
at commit 31416495ad9b2c84473f72ad99e2adc87dd66e5a.

My mingw.org installation has libgccjit packages:
  libgccjit-9.2.0-2-mingw32-dev.tar.xz
  libgccjit-9.2.0-2-mingw32-dll-0.tar.xz
  libgccjit-9.2.0-2-mingw32-info.tar.xz

These were obtained from a link on the ticket at:
  https://osdn.net/projects/mingw/ticket/41070

That was part of the work done after Eli requested libjcc support.


MSYS2 (i686-w64-mingw32)
------------------------
Running "pacman -Qs gccjit" shows:

local/mingw-w64-i686-libgccjit 10.2.0-6 (mingw-w64-i686-toolchain)
    GNU Compiler Collection (libgccjit) for MinGW-w64
local/mingw-w64-x86_64-libgccjit 10.2.0-6 (mingw-w64-x86_64-toolchain)
    GNU Compiler Collection (libgccjit) for MinGW-w64

As noted in an earlier message upthread, the MSYS2 developers have
stopped support for the 32bit builds.


   AndyM




Reply | Threaded
Open this post in threaded view
|

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

Emacs - Bugs mailing list
Andy Moreton <[hidden email]> 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.

  Andrea



Reply | Threaded
Open this post in threaded view
|

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

Emacs - Bugs mailing list
Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <[hidden email]> writes:

> Andy Moreton <[hidden email]> 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?

Thanks

  Andrea


diff --git a/src/comp.c b/src/comp.c
index 5e95161030..bb3cd83036 100644
--- a/src/comp.c
+++ b/src/comp.c
@@ -56,6 +56,7 @@
 #undef gcc_jit_block_end_with_return
 #undef gcc_jit_block_end_with_void_return
 #undef gcc_jit_context_acquire
+#undef gcc_jit_context_add_command_line_option
 #undef gcc_jit_context_add_driver_option
 #undef gcc_jit_context_compile_to_file
 #undef gcc_jit_context_dump_reproducer_to_file
@@ -124,6 +125,8 @@ DEF_DLL_FN (const char *, gcc_jit_context_get_first_error,
 DEF_DLL_FN (gcc_jit_block *, gcc_jit_function_new_block,
             (gcc_jit_function *func, const char *name));
 DEF_DLL_FN (gcc_jit_context *, gcc_jit_context_acquire, (void));
+DEF_DLL_FN (void, gcc_jit_context_add_command_line_option,
+            (gcc_jit_context *ctxt, const char *optname));
 DEF_DLL_FN (void, gcc_jit_context_add_driver_option,
             (gcc_jit_context *ctxt, const char *optname));
 DEF_DLL_FN (gcc_jit_field *, gcc_jit_context_new_field,
@@ -312,6 +315,7 @@ init_gccjit_functions (void)
   LOAD_DLL_FN (library, gcc_jit_struct_set_fields);
   LOAD_DLL_FN (library, gcc_jit_type_get_const);
   LOAD_DLL_FN (library, gcc_jit_type_get_pointer);
+  LOAD_DLL_FN_OPT (library, gcc_jit_context_add_command_line_option);
   LOAD_DLL_FN_OPT (library, gcc_jit_context_add_driver_option);
   LOAD_DLL_FN_OPT (library, gcc_jit_global_set_initializer);
   LOAD_DLL_FN_OPT (library, gcc_jit_version_major);
@@ -330,6 +334,7 @@ #define gcc_jit_block_end_with_jump fn_gcc_jit_block_end_with_jump
 #define gcc_jit_block_end_with_return fn_gcc_jit_block_end_with_return
 #define gcc_jit_block_end_with_void_return fn_gcc_jit_block_end_with_void_return
 #define gcc_jit_context_acquire fn_gcc_jit_context_acquire
+#define gcc_jit_context_add_command_line_option fn_gcc_jit_context_add_command_line_option
 #define gcc_jit_context_add_driver_option fn_gcc_jit_context_add_driver_option
 #define gcc_jit_context_compile_to_file fn_gcc_jit_context_compile_to_file
 #define gcc_jit_context_dump_reproducer_to_file fn_gcc_jit_context_dump_reproducer_to_file
@@ -4400,6 +4405,15 @@ DEFUN ("comp--compile-ctxt-to-file", Fcomp__compile_ctxt_to_file,
     if (!EQ (HASH_VALUE (func_h, i), Qunbound))
       compile_function (HASH_VALUE (func_h, i));
 
+#if defined (WIDE_EMACS_INT) \
+  && (defined (LIBGCCJIT_HAVE_gcc_jit_context_add_command_line_option) \
+      || defined (WINDOWSNT))
+  Lisp_Object version = Fcomp_libgccjit_version ();
+  if (!NILP (version) && XFIXNUM (XCAR (version)) >= 10)
+    gcc_jit_context_add_command_line_option (comp.ctxt,
+     "-fdisable-tree-isolate-paths");
+#endif
+
   add_driver_options ();
 
   if (comp.debug)
Reply | Threaded
Open this post in threaded view
|

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

Andy Moreton-3
In reply to this post by Andy Moreton-3
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" <[hidden email]> writes:
>
>> Andy Moreton <[hidden email]> 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 ?? ()






Reply | Threaded
Open this post in threaded view
|

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

Emacs - Bugs mailing list
Andy Moreton <[hidden email]> writes:

> 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" <[hidden email]> writes:
>>
>>> Andy Moreton <[hidden email]> 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).

The patch is not affecting GCC9 as initially was reported to be working.
If you suspect also 9 is affected you can trivially modify the patch to
take effect on 9 too.

  Andrea



Reply | Threaded
Open this post in threaded view
|

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

Andy Moreton-3
In reply to this post by Andy Moreton-3
On Fri 19 Feb 2021, Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of text editors" wrote:

> The patch is not affecting GCC9 as initially was reported to be working.
> If you suspect also 9 is affected you can trivially modify the patch to
> take effect on 9 too.

I tried a clean rebuild after modifying the patch to appy for gcc9.
No difference - the compile processes still crash.

Debugging this further will have to wait for Eli or some other
interested person who uses this platform to investigate this issue.

    AndyM




1234