[Bug jit/99126] Compilation ICE trying insert trap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99126 --- Comment #9 from Andrea Corallo --- "dmalcolm at gcc dot gnu.org via Gcc-bugs" writes: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99126 > > --- Comment #8 from David Malcolm --- > (In reply to CVS Commits from comment #6) >> The master branch has been updated by David Malcolm : >> >> https://gcc.gnu.org/g:b258e263e0d74ca1f76aeaac5f4d1abef6b13707 >> >> commit r11-7288-gb258e263e0d74ca1f76aeaac5f4d1abef6b13707 > > Fixed on trunk for gcc 11. Andrea, do you need my to backport this? What GCC > versions are you targeting with your emacs project? We are targetting them all, but to my test I could not trigger this bug on GCC9 so I guess we could backport on GCC10 only?
Re: [Bug jit/99126] Compilation ICE trying insert trap
"dmalcolm at gcc dot gnu.org via Gcc-bugs" writes: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99126 > > --- Comment #8 from David Malcolm --- > (In reply to CVS Commits from comment #6) >> The master branch has been updated by David Malcolm : >> >> https://gcc.gnu.org/g:b258e263e0d74ca1f76aeaac5f4d1abef6b13707 >> >> commit r11-7288-gb258e263e0d74ca1f76aeaac5f4d1abef6b13707 > > Fixed on trunk for gcc 11. Andrea, do you need my to backport this? What GCC > versions are you targeting with your emacs project? We are targetting them all, but to my test I could not trigger this bug on GCC9 so I guess we could backport on GCC10 only?
[Bug jit/99126] Compilation ICE trying insert trap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99126 --- Comment #8 from David Malcolm --- (In reply to CVS Commits from comment #6) > The master branch has been updated by David Malcolm : > > https://gcc.gnu.org/g:b258e263e0d74ca1f76aeaac5f4d1abef6b13707 > > commit r11-7288-gb258e263e0d74ca1f76aeaac5f4d1abef6b13707 Fixed on trunk for gcc 11. Andrea, do you need my to backport this? What GCC versions are you targeting with your emacs project?
[Bug jit/99126] Compilation ICE trying insert trap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99126 --- Comment #7 from David Malcolm --- (In reply to Andrea Corallo from comment #5) > As a side question: do you guys think disabling "isolate-paths" is the > right workaround for the affected versions or might have harmful side > effects? It ought to stop the crash; given that the code path happens on places where the compiler predicts a NULL dereference, I don't think it can cause additional problems.
[Bug jit/99126] Compilation ICE trying insert trap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99126 --- Comment #6 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:b258e263e0d74ca1f76aeaac5f4d1abef6b13707 commit r11-7288-gb258e263e0d74ca1f76aeaac5f4d1abef6b13707 Author: David Malcolm Date: Thu Feb 18 21:28:26 2021 -0500 jit: fix ICE on BUILT_IN_TRAP [PR99126] gcc/jit/ChangeLog: PR jit/99126 * jit-builtins.c (gcc::jit::builtins_manager::get_builtin_function_by_id): Update assertion to reject BUILT_IN_NONE. (gcc::jit::builtins_manager::ensure_optimization_builtins_exist): New. * jit-builtins.h (gcc::jit::builtins_manager::ensure_optimization_builtins_exist): New decl. * jit-playback.c (gcc::jit::playback::context::replay): Call it. Remove redundant conditional on bm. gcc/testsuite/ChangeLog: PR jit/99126 * jit.dg/test-trap.c: New test.
[Bug jit/99126] Compilation ICE trying insert trap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99126 --- Comment #5 from Andrea Corallo --- "dmalcolm at gcc dot gnu.org via Gcc-bugs" writes: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99126 > > David Malcolm changed: > >What|Removed |Added > > Status|NEW |ASSIGNED > > --- Comment #4 from David Malcolm --- > Am testing a fix. Nice! As a side question: do you guys think disabling "isolate-paths" is the right workaround for the affected versions or might have harmful side effects? Thanks Andrea
Re: [Bug jit/99126] Compilation ICE trying insert trap
"dmalcolm at gcc dot gnu.org via Gcc-bugs" writes: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99126 > > David Malcolm changed: > >What|Removed |Added > > Status|NEW |ASSIGNED > > --- Comment #4 from David Malcolm --- > Am testing a fix. Nice! As a side question: do you guys think disabling "isolate-paths" is the right workaround for the affected versions or might have harmful side effects? Thanks Andrea
[Bug jit/99126] Compilation ICE trying insert trap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99126 David Malcolm changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #4 from David Malcolm --- Am testing a fix.
[Bug jit/99126] Compilation ICE trying insert trap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99126 --- Comment #3 from David Malcolm --- Created attachment 50216 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50216=edit Minimal reproducer as a test case Attached is a minimal reproducer, as a test case. I don't have a fix for this yet.
[Bug jit/99126] Compilation ICE trying insert trap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99126 Martin Liška changed: What|Removed |Added Last reconfirmed||2021-02-17 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- Thanks for the report. > This is my understanding of what is going on here: we have a some > generated code that in GIMPLE is proved to dereference a null pointer > (BTW this code should be unreachable). That's fine. > > MEM[(struct comp_Lisp_Cons *)0B].u.s.car = _35; > So I guess JIT should really initialize the builtins. I tried manually calling: gcc_jit_context_get_builtin_function (ctxt_0x8892590, "__builtin_trap"); and then your reproducer is fine. Leaving to David.
[Bug jit/99126] Compilation ICE trying insert trap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99126 --- Comment #1 from Andrea Corallo --- This is the bt of how the C front-end is initializing these declarations: #0 set_builtin_decl (implicit_p=, decl=, fncode=) at ../../gcc/tree.h:5662 #1 def_builtin_1 (fncode=, name=, fntype=, libtype=, both_p=, fallback_p=, nonansi_p=false, fnattrs=, implicit_p=true, fnclass=BUILT_IN_NORMAL) at ../../gcc/c-family/c-common.c:4729 #2 0x00a291c9 in c_define_builtins ( va_list_arg_type_node=, va_list_ref_type_node=) at ../../gcc/builtins.def:933 Thinking loud: I guess in jit-builtins.c we should loop once over all the builtins calling 'set_builtin_decl'? Probably in the constructor for gcc::jit::builtins_manager?
