GNU bug report logs - #79722
31; Segfault while compiling Emacs

Previous Next

To reply to this bug, email your comments to 79722 AT debbugs.gnu.org.
There is no need to reopen the bug first.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 31; Segfault while compiling Emacs
Date: Wed, 29 Oct 2025 17:29:35 -0400

On 96fd4725936e403dc7012fcf056cda95db445b6c (the current head of trunk),
and for at least a few weeks back, compiling Emacs segfaults in native
compilation.

I'm on Rocky Linux 8 with libgccjit-8.5.0-27.el8.x86_64

Below is the problematic line, and the backtrace under gdb.

/bin/sh: line 1: 2292650 Segmentation fault      (core dumped) '../src/bootstrap-emacs' -batch --no-site-file --no-site-lisp -l comp -f batch-byte+native-compile emacs-lisp/macroexp.el

Thread 1 "bootstrap-emacs" received signal SIGSEGV, Segmentation fault.
0x00007fffec5127af in dominated_by_p(cdi_direction, basic_block_def const*, basic_block_def const*) () from /lib64/libgccjit.so.0
(gdb) bt
#0  0x00007fffec5127af in dominated_by_p(cdi_direction, basic_block_def const*, basic_block_def const*) () from /lib64/libgccjit.so.0
#1  0x00007fffec93d6cf in get_continuation_for_phi(gimple*, ao_ref*, unsigned int*, bitmap_head**, bool, void* (*)(ao_ref*, tree_node*, void*, bool*), void*) () from /lib64/libgccjit.so.0
#2  0x00007fffec93db8e in walk_non_aliased_vuses(ao_ref*, tree_node*, void* (*)(ao_ref*, tree_node*, unsigned int, void*), void* (*)(ao_ref*, tree_node*, void*, bool*), tree_node* (*)(tree_node*), void*) () from /lib64/libgccjit.so.0
#3  0x00007fffec9df822 in vn_reference_lookup(tree_node*, tree_node*, vn_lookup_kind, vn_reference_s**, bool) () from /lib64/libgccjit.so.0
#4  0x00007fffec9e5187 in visit_use(tree_node*) () from /lib64/libgccjit.so.0
#5  0x00007fffec9e7602 in DFS(tree_node*) () from /lib64/libgccjit.so.0
#6  0x00007fffec9e7da0 in sccvn_dom_walker::before_dom_children(basic_block_def*) () from /lib64/libgccjit.so.0
#7  0x00007fffecf7a0b2 in dom_walker::walk(basic_block_def*) () from /lib64/libgccjit.so.0
#8  0x00007fffec9e88b0 in run_scc_vn(vn_lookup_kind) () from /lib64/libgccjit.so.0
#9  0x00007fffec9e904f in (anonymous namespace)::pass_fre::execute(function*) () from /lib64/libgccjit.so.0
#10 0x00007fffec796293 in execute_one_pass(opt_pass*) () from /lib64/libgccjit.so.0
#11 0x00007fffec796998 in execute_pass_list_1(opt_pass*) () from /lib64/libgccjit.so.0
#12 0x00007fffec7969aa in execute_pass_list_1(opt_pass*) () from /lib64/libgccjit.so.0
#13 0x00007fffec7969f5 in execute_pass_list(function*, opt_pass*) () from /lib64/libgccjit.so.0
#14 0x00007fffec4da94c in cgraph_node::expand() () from /lib64/libgccjit.so.0
#15 0x00007fffec4dbd1f in symbol_table::compile() () from /lib64/libgccjit.so.0
#16 0x00007fffec4dd8b2 in symbol_table::finalize_compilation_unit() () from /lib64/libgccjit.so.0
#17 0x00007fffec85cb0e in compile_file() () from /lib64/libgccjit.so.0
#18 0x00007fffec41f50b in toplev::main(int, char**) () from /lib64/libgccjit.so.0
#19 0x00007fffec44526d in gcc::jit::playback::context::compile() () from /lib64/libgccjit.so.0
#20 0x00007fffec43b3f6 in gcc::jit::recording::context::compile_to_file(gcc_jit_output_kind, char const*) () from /lib64/libgccjit.so.0
#21 0x00007fffec42f589 in gcc_jit_context_compile_to_file () from /lib64/libgccjit.so.0
#22 0x000000000061cafd in Fcomp__compile_ctxt_to_file0 (filename=0x9632f4) at lisp.h:728
#23 0x00000000006128a3 in exec_byte_code (fun=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) at lisp.h:728
#24 0x00000000005cedef in funcall_general (args=0x7fffffffbe68, numargs=0, fun=<optimized out>) at eval.c:3117
#25 Ffuncall (nargs=1, args=0x7fffffffbe60) at eval.c:3177
#26 0x00000000005d1f17 in eval_sub (form=<optimized out>) at eval.c:2639
#27 0x00000000005d2a20 in Fprogn (body=<optimized out>) at eval.c:445
#28 Fif (args=<optimized out>) at eval.c:401
#29 0x00000000005d1f85 in eval_sub (form=<optimized out>) at lisp.h:728
#30 0x00000000005d2aa0 in Fprogn (body=<optimized out>) at eval.c:445
#31 Fcond (args=0x7fffdfa203d3) at eval.c:425
#32 0x00000000005d1f85 in eval_sub (form=<optimized out>) at lisp.h:728
#33 0x00000000005d35c0 in Fprogn (body=<optimized out>) at eval.c:445
#34 FletX (args=0x7fffdfa202c3) at eval.c:1126
#35 0x00000000005d1f85 in eval_sub (form=<optimized out>) at lisp.h:728
#36 0x00000000005d2210 in Fprogn (body=<optimized out>) at eval.c:445
#37 0x00000000005d2e9d in prog_ignore (body=0x7fffdfa202a3) at eval.c:456
#38 Fwhile (args=<optimized out>) at eval.c:1214
#39 0x00000000005d1f85 in eval_sub (form=<optimized out>) at lisp.h:728
#40 0x00000000005d35c0 in Fprogn (body=<optimized out>) at eval.c:445
#41 FletX (args=0x7fffdfa20243) at eval.c:1126
#42 0x00000000005d1f85 in eval_sub (form=<optimized out>) at lisp.h:728
#43 0x00000000005d2210 in Fprogn (body=<optimized out>) at eval.c:445
#44 0x00000000005d1f85 in eval_sub (form=<optimized out>) at lisp.h:728
#45 0x00000000005d1f85 in eval_sub (form=<optimized out>) at lisp.h:728
#46 0x00000000005d3390 in Fprogn (body=<optimized out>) at eval.c:445
#47 Flet (args=0x7fffdfa201c3) at eval.c:1193
#48 0x00000000005d1f85 in eval_sub (form=<optimized out>) at lisp.h:728
#49 0x00000000005d3390 in Fprogn (body=<optimized out>) at eval.c:445
#50 Flet (args=0x7fffdfa1a74b) at eval.c:1193
#51 0x00000000005d1f85 in eval_sub (form=<optimized out>) at lisp.h:728
#52 0x00000000005d25d0 in Fprogn (body=<optimized out>) at eval.c:445
#53 funcall_lambda (fun=fun <at> entry=0x7fffdfa1a6cd, nargs=nargs <at> entry=1, arg_vector=arg_vector <at> entry=0x7fffffffc820) at eval.c:3434
#54 0x00000000005d2fc9 in apply_lambda (fun=fun <at> entry=0x7fffdfa1a6cd, args=<optimized out>, count=count <at> entry=...) at eval.c:3299
#55 0x00000000005d196f in eval_sub (form=<optimized out>) at eval.c:2756
#56 0x00000000005d3390 in Fprogn (body=<optimized out>) at eval.c:445
#57 Flet (args=0x7fffdfa6c243) at eval.c:1193
#58 0x00000000005d1f85 in eval_sub (form=<optimized out>) at lisp.h:728
#59 0x00000000005d25d0 in Fprogn (body=<optimized out>) at eval.c:445
#60 funcall_lambda (fun=fun <at> entry=0x7fffdfa6c1d5, nargs=nargs <at> entry=0, arg_vector=arg_vector <at> entry=0x7fffffffcae0) at eval.c:3434
#61 0x00000000005d2fc9 in apply_lambda (fun=fun <at> entry=0x7fffdfa6c1d5, args=<optimized out>, count=count <at> entry=...) at eval.c:3299
#62 0x00000000005d196f in eval_sub (form=<optimized out>) at eval.c:2756
#63 0x00000000005d3722 in Funwind_protect (args=0x7fffdfadb94b) at lisp.h:728
#64 0x00000000005d1f85 in eval_sub (form=<optimized out>) at lisp.h:728
#65 0x00000000005d3390 in Fprogn (body=<optimized out>) at eval.c:445
#66 Flet (args=0x7fffdfadb91b) at eval.c:1193
#67 0x00000000005d1f85 in eval_sub (form=<optimized out>) at lisp.h:728
#68 0x00000000005d2a20 in Fprogn (body=<optimized out>) at eval.c:445
#69 Fif (args=<optimized out>) at eval.c:401
#70 0x00000000005d1f85 in eval_sub (form=<optimized out>) at lisp.h:728
#71 0x00000000005d25d0 in Fprogn (body=<optimized out>) at eval.c:445
#72 funcall_lambda (fun=fun <at> entry=0x7fffdfadb1ed, nargs=nargs <at> entry=0, arg_vector=arg_vector <at> entry=0x7fffffffcf30) at eval.c:3434
#73 0x00000000005d2fc9 in apply_lambda (fun=fun <at> entry=0x7fffdfadb1ed, args=<optimized out>, count=count <at> entry=...) at eval.c:3299
#74 0x00000000005d196f in eval_sub (form=form <at> entry=0x7fffdfe504a3) at eval.c:2756
#75 0x00000000005d3bdf in Feval (form=0x7fffdfe504a3, lexical=lexical <at> entry=0x30) at eval.c:2528
#76 0x000000000054a7eb in top_level_2 () at lisp.h:1151
#77 0x00000000005cd792 in internal_condition_case (bfun=bfun <at> entry=0x54a7a0 <top_level_2>, handlers=handlers <at> entry=0x90, hfun=hfun <at> entry=0x551da0 <cmd_error>) at eval.c:1690
#78 0x000000000054cd82 in top_level_1 (ignore=ignore <at> entry=0x0) at keyboard.c:1191
#79 0x00000000005cd6c1 in internal_catch (tag=tag <at> entry=0x12690, func=func <at> entry=0x54cd60 <top_level_1>, arg=arg <at> entry=0x0) at eval.c:1370
#80 0x000000000054a6cb in command_loop () at lisp.h:1151
#81 0x0000000000551984 in recursive_edit_1 () at keyboard.c:749
#82 0x0000000000551ce4 in Frecursive_edit () at keyboard.c:832
#83 0x000000000042a129 in main (argc=<optimized out>, argv=<optimized out>) at emacs.c:2629

Lisp Backtrace:
"comp--compile-ctxt-to-file0" (0xd19ff2c8)
"comp--compile-ctxt-to-file" (0xd19ff270)
"comp--final1" (0xd19ff1a8)
"comp--final" (0xd19ff138)
"comp--native-compile" (0xd19ff090)
"batch-native-compile" (0xd19ff038)
"batch-byte+native-compile" (0xffffbe68)
"funcall" (0xffffbe60)
"if" (0xffffbf68)
"cond" (0xffffc038)
"let*" (0xffffc168)
"while" (0xffffc248)
"let*" (0xffffc378)
"progn" (0xffffc438)
"if" (0xffffc4e8)
"let" (0xffffc608)
"let" (0xffffc728)
"command-line-1" (0xffffc820)
"let" (0xffffc9e8)
"command-line" (0xffffcae0)
"unwind-protect" (0xffffcc48)
"let" (0xffffcd68)
"if" (0xffffce38)
"normal-top-level" (0xffffcf30)

Message #8 received at 79722 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: pipcet <at> protonmail.com, acorallo <at> gnu.org, 79722 <at> debbugs.gnu.org
Subject: Re: bug#79722: 31; Segfault while compiling Emacs
Date: Thu, 30 Oct 2025 08:53:27 +0200

> Cc: Pip Cet <pipcet <at> protonmail.com>, Andrea Corallo <acorallo <at> gnu.org>
> Date: Wed, 29 Oct 2025 17:29:35 -0400
> From:  Spencer Baugh via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> 
> On 96fd4725936e403dc7012fcf056cda95db445b6c (the current head of trunk),
> and for at least a few weeks back, compiling Emacs segfaults in native
> compilation.
> 
> I'm on Rocky Linux 8 with libgccjit-8.5.0-27.el8.x86_64

Which GCC version does this correspond to?

Also, do you mean _every_ native compilation of any Lisp file
segfaults like that?  Or just some files?  If the latter, can you give
examples of files that cause these crashes?

Also, with the same libgccjit, if you build another branch, say,
emacs-30, does it also crash?  If not, how many weeks is "a few weeks
back"?  The last change in native-compilation related files was a week
ago, and the ones before that were in July.  Or maybe you could
bisect?

Thanks.

Message #11 received at 79722 <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> protonmail.com>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: Andrea Corallo <acorallo <at> gnu.org>, 79722 <at> debbugs.gnu.org
Subject: Re: bug#79722: 31; Segfault while compiling Emacs
Date: Fri, 31 Oct 2025 15:25:49 +0000

"Spencer Baugh" <sbaugh <at> janestreet.com> writes:

> On 96fd4725936e403dc7012fcf056cda95db445b6c (the current head of trunk),
> and for at least a few weeks back, compiling Emacs segfaults in native
> compilation.

> I'm on Rocky Linux 8 with libgccjit-8.5.0-27.el8.x86_64

Can you confirm this fixes it (works around the issue, at least)?

diff --git a/src/comp.c b/src/comp.c
index 8ab167ab592..39ed0e4a233 100644
--- a/src/comp.c
+++ b/src/comp.c
@@ -1541,7 +1541,7 @@ emit_EQ (gcc_jit_rvalue *x, gcc_jit_rvalue *y)
 
   return emit_OR (
     base_eq,
-    emit_AND (unlikely_symbols_with_pos_enabled, emit_slow_eq (x, y)));
+    emit_AND (symbols_with_pos_enabled_rval, emit_slow_eq (x, y)));
 }
 
 static gcc_jit_rvalue *

Thanks!

Pip

Message #14 received at 79722 <at> debbugs.gnu.org (full text, mbox):

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Pip Cet <pipcet <at> protonmail.com>
Cc: Andrea Corallo <acorallo <at> gnu.org>, 79722 <at> debbugs.gnu.org
Subject: Re: bug#79722: 31; Segfault while compiling Emacs
Date: Mon, 03 Nov 2025 15:51:52 -0500

Pip Cet <pipcet <at> protonmail.com> writes:

> "Spencer Baugh" <sbaugh <at> janestreet.com> writes:
>
>> On 96fd4725936e403dc7012fcf056cda95db445b6c (the current head of trunk),
>> and for at least a few weeks back, compiling Emacs segfaults in native
>> compilation.
>
>> I'm on Rocky Linux 8 with libgccjit-8.5.0-27.el8.x86_64
>
> Can you confirm this fixes it (works around the issue, at least)?
>
> diff --git a/src/comp.c b/src/comp.c
> index 8ab167ab592..39ed0e4a233 100644
> --- a/src/comp.c
> +++ b/src/comp.c
> @@ -1541,7 +1541,7 @@ emit_EQ (gcc_jit_rvalue *x, gcc_jit_rvalue *y)
>  
>    return emit_OR (
>      base_eq,
> -    emit_AND (unlikely_symbols_with_pos_enabled, emit_slow_eq (x, y)));
> +    emit_AND (symbols_with_pos_enabled_rval, emit_slow_eq (x, y)));
>  }
>  
>  static gcc_jit_rvalue *

Yes, compilation succeeds (and Emacs works fine) with this patch.

Message #17 received at 79722 <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> protonmail.com>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: Andrea Corallo <acorallo <at> gnu.org>, 79722 <at> debbugs.gnu.org
Subject: Re: bug#79722: 31; Segfault while compiling Emacs
Date: Mon, 03 Nov 2025 21:08:41 +0000

"Spencer Baugh" <sbaugh <at> janestreet.com> writes:

> Pip Cet <pipcet <at> protonmail.com> writes:
>
>> "Spencer Baugh" <sbaugh <at> janestreet.com> writes:
>>
>>> On 96fd4725936e403dc7012fcf056cda95db445b6c (the current head of trunk),
>>> and for at least a few weeks back, compiling Emacs segfaults in native
>>> compilation.
>>
>>> I'm on Rocky Linux 8 with libgccjit-8.5.0-27.el8.x86_64
>>
>> Can you confirm this fixes it (works around the issue, at least)?
>>
>> diff --git a/src/comp.c b/src/comp.c
>> index 8ab167ab592..39ed0e4a233 100644
>> --- a/src/comp.c
>> +++ b/src/comp.c
>> @@ -1541,7 +1541,7 @@ emit_EQ (gcc_jit_rvalue *x, gcc_jit_rvalue *y)
>>
>>    return emit_OR (
>>      base_eq,
>> -    emit_AND (unlikely_symbols_with_pos_enabled, emit_slow_eq (x, y)));
>> +    emit_AND (symbols_with_pos_enabled_rval, emit_slow_eq (x, y)));
>>  }
>>
>>  static gcc_jit_rvalue *
>
> Yes, compilation succeeds (and Emacs works fine) with this patch.

Thanks. Andrea, do you happen to know which version of libgccjit has the
fix for this problem? As it's merely an optimization, we might be able
to get away with simply disabling it on versions of libgccjit < 14,
but I'm not sure whether that's a good choice.

Pip

Message #20 received at 79722 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pip Cet <pipcet <at> protonmail.com>, acorallo <at> gnu.org
Cc: sbaugh <at> janestreet.com, 79722 <at> debbugs.gnu.org
Subject: Re: bug#79722: 31; Segfault while compiling Emacs
Date: Sat, 15 Nov 2025 11:19:57 +0200

Ping!  Andrea, can you answer Pip's question below?

> Cc: Andrea Corallo <acorallo <at> gnu.org>, 79722 <at> debbugs.gnu.org
> Date: Mon, 03 Nov 2025 21:08:41 +0000
> From:  Pip Cet via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> "Spencer Baugh" <sbaugh <at> janestreet.com> writes:
> 
> > Pip Cet <pipcet <at> protonmail.com> writes:
> >
> >> "Spencer Baugh" <sbaugh <at> janestreet.com> writes:
> >>
> >>> On 96fd4725936e403dc7012fcf056cda95db445b6c (the current head of trunk),
> >>> and for at least a few weeks back, compiling Emacs segfaults in native
> >>> compilation.
> >>
> >>> I'm on Rocky Linux 8 with libgccjit-8.5.0-27.el8.x86_64
> >>
> >> Can you confirm this fixes it (works around the issue, at least)?
> >>
> >> diff --git a/src/comp.c b/src/comp.c
> >> index 8ab167ab592..39ed0e4a233 100644
> >> --- a/src/comp.c
> >> +++ b/src/comp.c
> >> @@ -1541,7 +1541,7 @@ emit_EQ (gcc_jit_rvalue *x, gcc_jit_rvalue *y)
> >>
> >>    return emit_OR (
> >>      base_eq,
> >> -    emit_AND (unlikely_symbols_with_pos_enabled, emit_slow_eq (x, y)));
> >> +    emit_AND (symbols_with_pos_enabled_rval, emit_slow_eq (x, y)));
> >>  }
> >>
> >>  static gcc_jit_rvalue *
> >
> > Yes, compilation succeeds (and Emacs works fine) with this patch.
> 
> Thanks. Andrea, do you happen to know which version of libgccjit has the
> fix for this problem? As it's merely an optimization, we might be able
> to get away with simply disabling it on versions of libgccjit < 14,
> but I'm not sure whether that's a good choice.
> 
> Pip
> 
> 
> 
> 
> 

Message #23 received at 79722 <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> protonmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: sbaugh <at> janestreet.com, acorallo <at> gnu.org, 79722 <at> debbugs.gnu.org
Subject: Re: bug#79722: 31; Segfault while compiling Emacs
Date: Sat, 15 Nov 2025 10:07:03 +0000

"Eli Zaretskii" <eliz <at> gnu.org> writes:

> Ping!  Andrea, can you answer Pip's question below?

>> Cc: Andrea Corallo <acorallo <at> gnu.org>, 79722 <at> debbugs.gnu.org
>> Date: Mon, 03 Nov 2025 21:08:41 +0000
>> From:  Pip Cet via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>>
>> "Spencer Baugh" <sbaugh <at> janestreet.com> writes:
>>
>> > Pip Cet <pipcet <at> protonmail.com> writes:
>> >
>> >> "Spencer Baugh" <sbaugh <at> janestreet.com> writes:
>> >>
>> >>> On 96fd4725936e403dc7012fcf056cda95db445b6c (the current head of trunk),
>> >>> and for at least a few weeks back, compiling Emacs segfaults in native
>> >>> compilation.
>> >>
>> >>> I'm on Rocky Linux 8 with libgccjit-8.5.0-27.el8.x86_64
>> >>
>> >> Can you confirm this fixes it (works around the issue, at least)?
>> >>
>> >> diff --git a/src/comp.c b/src/comp.c
>> >> index 8ab167ab592..39ed0e4a233 100644
>> >> --- a/src/comp.c
>> >> +++ b/src/comp.c
>> >> @@ -1541,7 +1541,7 @@ emit_EQ (gcc_jit_rvalue *x, gcc_jit_rvalue *y)
>> >>
>> >>    return emit_OR (
>> >>      base_eq,
>> >> -    emit_AND (unlikely_symbols_with_pos_enabled, emit_slow_eq (x, y)));
>> >> +    emit_AND (symbols_with_pos_enabled_rval, emit_slow_eq (x, y)));
>> >>  }
>> >>
>> >>  static gcc_jit_rvalue *
>> >
>> > Yes, compilation succeeds (and Emacs works fine) with this patch.
>>
>> Thanks. Andrea, do you happen to know which version of libgccjit has the
>> fix for this problem? As it's merely an optimization, we might be able
>> to get away with simply disabling it on versions of libgccjit < 14,
>> but I'm not sure whether that's a good choice.

Rereading this, I fear I may have left out some context which Andrea
might need to answer the question:

with the old libgccjit the OP used, there was a segfault because,
apparently, the builtin function "__builtin_expect" wasn't assigned the
right type by libgccjit. I assume that this is an issue that has been
fixed since (it doesn't occur with a newer libgccjit), but there's
little harm in simply avoiding the __builtin_expect machinery for old
libgccjit.

But I don't know what the right cut-off point is.

Note that there is currently significant discussion to make EQ = BASE_EQ
again, in which case all this code would be simplified anyway, and the
builtin_expect would no longer be needed (my measurements indicate that
the probability EQ returns true is about 50%, which is what GCC assumes
anyway in the absence of a builtin_expect_[with_probability]
annotation).

Thanks!
Pip

Message #26 received at 79722 <at> debbugs.gnu.org (full text, mbox):

From: Andrea Corallo <acorallo <at> gnu.org>
To: Pip Cet <pipcet <at> protonmail.com>
Cc: sbaugh <at> janestreet.com, Eli Zaretskii <eliz <at> gnu.org>, 79722 <at> debbugs.gnu.org
Subject: Re: bug#79722: 31; Segfault while compiling Emacs
Date: Sat, 15 Nov 2025 11:52:22 -0500

Pip Cet <pipcet <at> protonmail.com> writes:

> "Eli Zaretskii" <eliz <at> gnu.org> writes:
>
>> Ping!  Andrea, can you answer Pip's question below?
>
>>> Cc: Andrea Corallo <acorallo <at> gnu.org>, 79722 <at> debbugs.gnu.org
>>> Date: Mon, 03 Nov 2025 21:08:41 +0000
>>> From:  Pip Cet via "Bug reports for GNU Emacs,
>>>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>>>
>>> "Spencer Baugh" <sbaugh <at> janestreet.com> writes:
>>>
>>> > Pip Cet <pipcet <at> protonmail.com> writes:
>>> >
>>> >> "Spencer Baugh" <sbaugh <at> janestreet.com> writes:
>>> >>
>>> >>> On 96fd4725936e403dc7012fcf056cda95db445b6c (the current head of trunk),
>>> >>> and for at least a few weeks back, compiling Emacs segfaults in native
>>> >>> compilation.
>>> >>
>>> >>> I'm on Rocky Linux 8 with libgccjit-8.5.0-27.el8.x86_64
>>> >>
>>> >> Can you confirm this fixes it (works around the issue, at least)?
>>> >>
>>> >> diff --git a/src/comp.c b/src/comp.c
>>> >> index 8ab167ab592..39ed0e4a233 100644
>>> >> --- a/src/comp.c
>>> >> +++ b/src/comp.c
>>> >> @@ -1541,7 +1541,7 @@ emit_EQ (gcc_jit_rvalue *x, gcc_jit_rvalue *y)
>>> >>
>>> >>    return emit_OR (
>>> >>      base_eq,
>>> >> -    emit_AND (unlikely_symbols_with_pos_enabled, emit_slow_eq (x, y)));
>>> >> +    emit_AND (symbols_with_pos_enabled_rval, emit_slow_eq (x, y)));
>>> >>  }
>>> >>
>>> >>  static gcc_jit_rvalue *
>>> >
>>> > Yes, compilation succeeds (and Emacs works fine) with this patch.
>>>
>>> Thanks. Andrea, do you happen to know which version of libgccjit has the
>>> fix for this problem? As it's merely an optimization, we might be able
>>> to get away with simply disabling it on versions of libgccjit < 14,
>>> but I'm not sure whether that's a good choice.

Hi Pip and Eli,

I was not aware of this libgccjit bug and I don't know when it was fixed
(nor if the fix was intentional).


> Rereading this, I fear I may have left out some context which Andrea
> might need to answer the question:
>
> with the old libgccjit the OP used, there was a segfault because,
> apparently, the builtin function "__builtin_expect" wasn't assigned the
> right type by libgccjit.

Do you think we could work around this with some type casting on our side?

> I assume that this is an issue that has been
> fixed since (it doesn't occur with a newer libgccjit), but there's
> little harm in simply avoiding the __builtin_expect machinery for old
> libgccjit.
>
> But I don't know what the right cut-off point is.

Maybe we should have a GCC bug to understand when this was fixed and if
the fix is intentional and 100% reliable?

Thanks!

  Andrea

Message #29 received at 79722 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andrea Corallo <acorallo <at> gnu.org>
Cc: sbaugh <at> janestreet.com, pipcet <at> protonmail.com, 79722 <at> debbugs.gnu.org
Subject: Re: bug#79722: 31; Segfault while compiling Emacs
Date: Sat, 29 Nov 2025 13:00:43 +0200

Ping!  How should we proceed with this issue?

> From: Andrea Corallo <acorallo <at> gnu.org>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  sbaugh <at> janestreet.com,
>   79722 <at> debbugs.gnu.org
> Date: Sat, 15 Nov 2025 11:52:22 -0500
> 
> Pip Cet <pipcet <at> protonmail.com> writes:
> 
> > "Eli Zaretskii" <eliz <at> gnu.org> writes:
> >
> >> Ping!  Andrea, can you answer Pip's question below?
> >
> >>> Cc: Andrea Corallo <acorallo <at> gnu.org>, 79722 <at> debbugs.gnu.org
> >>> Date: Mon, 03 Nov 2025 21:08:41 +0000
> >>> From:  Pip Cet via "Bug reports for GNU Emacs,
> >>>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> >>>
> >>> "Spencer Baugh" <sbaugh <at> janestreet.com> writes:
> >>>
> >>> > Pip Cet <pipcet <at> protonmail.com> writes:
> >>> >
> >>> >> "Spencer Baugh" <sbaugh <at> janestreet.com> writes:
> >>> >>
> >>> >>> On 96fd4725936e403dc7012fcf056cda95db445b6c (the current head of trunk),
> >>> >>> and for at least a few weeks back, compiling Emacs segfaults in native
> >>> >>> compilation.
> >>> >>
> >>> >>> I'm on Rocky Linux 8 with libgccjit-8.5.0-27.el8.x86_64
> >>> >>
> >>> >> Can you confirm this fixes it (works around the issue, at least)?
> >>> >>
> >>> >> diff --git a/src/comp.c b/src/comp.c
> >>> >> index 8ab167ab592..39ed0e4a233 100644
> >>> >> --- a/src/comp.c
> >>> >> +++ b/src/comp.c
> >>> >> @@ -1541,7 +1541,7 @@ emit_EQ (gcc_jit_rvalue *x, gcc_jit_rvalue *y)
> >>> >>
> >>> >>    return emit_OR (
> >>> >>      base_eq,
> >>> >> -    emit_AND (unlikely_symbols_with_pos_enabled, emit_slow_eq (x, y)));
> >>> >> +    emit_AND (symbols_with_pos_enabled_rval, emit_slow_eq (x, y)));
> >>> >>  }
> >>> >>
> >>> >>  static gcc_jit_rvalue *
> >>> >
> >>> > Yes, compilation succeeds (and Emacs works fine) with this patch.
> >>>
> >>> Thanks. Andrea, do you happen to know which version of libgccjit has the
> >>> fix for this problem? As it's merely an optimization, we might be able
> >>> to get away with simply disabling it on versions of libgccjit < 14,
> >>> but I'm not sure whether that's a good choice.
> 
> Hi Pip and Eli,
> 
> I was not aware of this libgccjit bug and I don't know when it was fixed
> (nor if the fix was intentional).
> 
> 
> > Rereading this, I fear I may have left out some context which Andrea
> > might need to answer the question:
> >
> > with the old libgccjit the OP used, there was a segfault because,
> > apparently, the builtin function "__builtin_expect" wasn't assigned the
> > right type by libgccjit.
> 
> Do you think we could work around this with some type casting on our side?
> 
> > I assume that this is an issue that has been
> > fixed since (it doesn't occur with a newer libgccjit), but there's
> > little harm in simply avoiding the __builtin_expect machinery for old
> > libgccjit.
> >
> > But I don't know what the right cut-off point is.
> 
> Maybe we should have a GCC bug to understand when this was fixed and if
> the fix is intentional and 100% reliable?
> 
> Thanks!
> 
>   Andrea
> 

Message #32 received at 79722 <at> debbugs.gnu.org (full text, mbox):

From: Andrea Corallo <acorallo <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: sbaugh <at> janestreet.com, pipcet <at> protonmail.com, 79722 <at> debbugs.gnu.org
Subject: Re: bug#79722: 31; Segfault while compiling Emacs
Date: Thu, 04 Dec 2025 11:09:07 -0500

Eli Zaretskii <eliz <at> gnu.org> writes:

> Ping!  How should we proceed with this issue?

I did some digging but I could not identify for sure when this libgccjit
bug was actually fixed.

So I pushed to master d52bf63de2b which implements Pip's suggestion of
not using builtin_expect with libgccjit < 14.

Please all have a look, when this is confirmed to work I guess we can
close.

Thanks!

  Andrea

Message #35 received at 79722 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andrea Corallo <acorallo <at> gnu.org>
Cc: sbaugh <at> janestreet.com, pipcet <at> protonmail.com, 79722 <at> debbugs.gnu.org
Subject: Re: bug#79722: 31; Segfault while compiling Emacs
Date: Thu, 04 Dec 2025 18:15:37 +0200

> From: Andrea Corallo <acorallo <at> gnu.org>
> Cc: sbaugh <at> janestreet.com,  pipcet <at> protonmail.com,  79722 <at> debbugs.gnu.org
> Date: Thu, 04 Dec 2025 11:09:07 -0500
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Ping!  How should we proceed with this issue?
> 
> I did some digging but I could not identify for sure when this libgccjit
> bug was actually fixed.
> 
> So I pushed to master d52bf63de2b which implements Pip's suggestion of
> not using builtin_expect with libgccjit < 14.
> 
> Please all have a look, when this is confirmed to work I guess we can
> close.

Thanks, but should this perhaps bump the ABI version?  Or are the
*.eln files produced with this change fully-compatible with those
without it, for libgccjit versions < 14?

Message #38 received at 79722 <at> debbugs.gnu.org (full text, mbox):

From: Andrea Corallo <acorallo <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: sbaugh <at> janestreet.com, pipcet <at> protonmail.com, 79722 <at> debbugs.gnu.org
Subject: Re: bug#79722: 31; Segfault while compiling Emacs
Date: Fri, 05 Dec 2025 10:16:22 -0500

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Andrea Corallo <acorallo <at> gnu.org>
>> Cc: sbaugh <at> janestreet.com,  pipcet <at> protonmail.com,  79722 <at> debbugs.gnu.org
>> Date: Thu, 04 Dec 2025 11:09:07 -0500
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> > Ping!  How should we proceed with this issue?
>> 
>> I did some digging but I could not identify for sure when this libgccjit
>> bug was actually fixed.
>> 
>> So I pushed to master d52bf63de2b which implements Pip's suggestion of
>> not using builtin_expect with libgccjit < 14.
>> 
>> Please all have a look, when this is confirmed to work I guess we can
>> close.
>
> Thanks, but should this perhaps bump the ABI version?  Or are the
> *.eln files produced with this change fully-compatible with those
> without it, for libgccjit versions < 14?

Hi Eli, no need to bump the ABI_VERSION as this change should be
fully-compatible 👍

Andrea

Message #41 received at 79722 <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Andrea Corallo <acorallo <at> gnu.org>
Cc: sbaugh <at> janestreet.com, Eli Zaretskii <eliz <at> gnu.org>, 79722 <at> debbugs.gnu.org,
 pipcet <at> protonmail.com
Subject: Re: bug#79722: 31; Segfault while compiling Emacs
Date: Sat, 06 Dec 2025 15:19:47 +0100

Andrea Corallo <acorallo <at> gnu.org> writes:

> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> From: Andrea Corallo <acorallo <at> gnu.org>
>>> Cc: sbaugh <at> janestreet.com,  pipcet <at> protonmail.com,  79722 <at> debbugs.gnu.org
>>> Date: Thu, 04 Dec 2025 11:09:07 -0500
>>> 
>>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>> 
>>> > Ping!  How should we proceed with this issue?
>>> 
>>> I did some digging but I could not identify for sure when this libgccjit
>>> bug was actually fixed.
>>> 
>>> So I pushed to master d52bf63de2b which implements Pip's suggestion of
>>> not using builtin_expect with libgccjit < 14.
>>> 
>>> Please all have a look, when this is confirmed to work I guess we can
>>> close.
>>
>> Thanks, but should this perhaps bump the ABI version?  Or are the
>> *.eln files produced with this change fully-compatible with those
>> without it, for libgccjit versions < 14?
>
> Hi Eli, no need to bump the ABI_VERSION as this change should be
> fully-compatible 👍
>
> Andrea

d52bf63de2b gives an unused variable warning. I think the fix is

1 file changed, 1 insertion(+), 1 deletion(-)
src/comp.c | 2 +-

modified   src/comp.c
@@ -1533,7 +1533,7 @@ emit_EQ (gcc_jit_rvalue *x, gcc_jit_rvalue *y)
                                                comp.long_type,
                                                0) };
 
-      gcc_jit_rvalue *symbols_with_pos_enabled_rval = emit_coerce (
+      symbols_with_pos_enabled_rval = emit_coerce (
         comp.bool_type,
         gcc_jit_context_new_call (
           comp.ctxt,

Message #44 received at 79722 <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Andrea Corallo <acorallo <at> gnu.org>
Cc: sbaugh <at> janestreet.com, Eli Zaretskii <eliz <at> gnu.org>, 79722 <at> debbugs.gnu.org,
 pipcet <at> protonmail.com
Subject: Re: bug#79722: 31; Segfault while compiling Emacs
Date: Sun, 07 Dec 2025 03:45:33 +0100

Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:

> Andrea Corallo <acorallo <at> gnu.org> writes:
>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>>>> From: Andrea Corallo <acorallo <at> gnu.org>
>>>> Cc: sbaugh <at> janestreet.com,  pipcet <at> protonmail.com,  79722 <at> debbugs.gnu.org
>>>> Date: Thu, 04 Dec 2025 11:09:07 -0500
>>>> 
>>>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>>> 
>>>> > Ping!  How should we proceed with this issue?
>>>> 
>>>> I did some digging but I could not identify for sure when this libgccjit
>>>> bug was actually fixed.
>>>> 
>>>> So I pushed to master d52bf63de2b which implements Pip's suggestion of
>>>> not using builtin_expect with libgccjit < 14.
>>>> 
>>>> Please all have a look, when this is confirmed to work I guess we can
>>>> close.
>>>
>>> Thanks, but should this perhaps bump the ABI version?  Or are the
>>> *.eln files produced with this change fully-compatible with those
>>> without it, for libgccjit versions < 14?
>>
>> Hi Eli, no need to bump the ABI_VERSION as this change should be
>> fully-compatible 👍
>>
>> Andrea
>
> d52bf63de2b gives an unused variable warning. I think the fix is
>
> 1 file changed, 1 insertion(+), 1 deletion(-)
> src/comp.c | 2 +-
>
> modified   src/comp.c
> @@ -1533,7 +1533,7 @@ emit_EQ (gcc_jit_rvalue *x, gcc_jit_rvalue *y)
>                                                 comp.long_type,
>                                                 0) };
>  
> -      gcc_jit_rvalue *symbols_with_pos_enabled_rval = emit_coerce (
> +      symbols_with_pos_enabled_rval = emit_coerce (
>          comp.bool_type,
>          gcc_jit_context_new_call (
>            comp.ctxt,

I've pushed that.

Message #49 received at 79722-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: sbaugh <at> janestreet.com, pipcet <at> protonmail.com, acorallo <at> gnu.org,
 79722-done <at> debbugs.gnu.org
Subject: Re: bug#79722: 31; Segfault while compiling Emacs
Date: Mon, 08 Dec 2025 16:26:57 +0200

> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  sbaugh <at> janestreet.com,
>   pipcet <at> protonmail.com,  79722 <at> debbugs.gnu.org
> Date: Sat, 06 Dec 2025 15:19:47 +0100
> 
> Andrea Corallo <acorallo <at> gnu.org> writes:
> 
> > Eli Zaretskii <eliz <at> gnu.org> writes:
> >
> >>> From: Andrea Corallo <acorallo <at> gnu.org>
> >>> Cc: sbaugh <at> janestreet.com,  pipcet <at> protonmail.com,  79722 <at> debbugs.gnu.org
> >>> Date: Thu, 04 Dec 2025 11:09:07 -0500
> >>> 
> >>> Eli Zaretskii <eliz <at> gnu.org> writes:
> >>> 
> >>> > Ping!  How should we proceed with this issue?
> >>> 
> >>> I did some digging but I could not identify for sure when this libgccjit
> >>> bug was actually fixed.
> >>> 
> >>> So I pushed to master d52bf63de2b which implements Pip's suggestion of
> >>> not using builtin_expect with libgccjit < 14.
> >>> 
> >>> Please all have a look, when this is confirmed to work I guess we can
> >>> close.
> >>
> >> Thanks, but should this perhaps bump the ABI version?  Or are the
> >> *.eln files produced with this change fully-compatible with those
> >> without it, for libgccjit versions < 14?
> >
> > Hi Eli, no need to bump the ABI_VERSION as this change should be
> > fully-compatible 👍
> >
> > Andrea
> 
> d52bf63de2b gives an unused variable warning. I think the fix is
> 
> 1 file changed, 1 insertion(+), 1 deletion(-)
> src/comp.c | 2 +-
> 
> modified   src/comp.c
> @@ -1533,7 +1533,7 @@ emit_EQ (gcc_jit_rvalue *x, gcc_jit_rvalue *y)
>                                                 comp.long_type,
>                                                 0) };
>  
> -      gcc_jit_rvalue *symbols_with_pos_enabled_rval = emit_coerce (
> +      symbols_with_pos_enabled_rval = emit_coerce (
>          comp.bool_type,
>          gcc_jit_context_new_call (
>            comp.ctxt,

This was installed, so I'm closing the bug.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.