[committed] jit: fix ICE on BUILT_IN_TRAP [PR99126]
David Malcolm
dmalcolm@redhat.com
Fri Feb 19 21:13:50 GMT 2021
On Fri, 2021-02-19 at 11:16 +0100, Andrea Corallo wrote:
> David Malcolm via Gcc-patches <gcc-patches@gcc.gnu.org> writes:
>
> > I tried several approaches to fixing this; this seemed the
> > least invasive.
>
> Hi Dave,
>
> thanks for fixing this.
>
> I do have a trivial question: are we guaranteed that the middle-end
> will
> not try to add any build-in other than a trap?
No; the middle-end can add various other builtins.
The C/C++ FE have c_define_builtins, which calls def_builtin_1 on
everything with DEF_BUILTIN, then calls:
targetm.init_builtins ();
build_common_builtin_nodes ();
jit_langhook_init calls build_common_builtin_nodes.
The jit builtins_manager creates recording::functions (and their
supporting types) for any builtins that are explicitly used, and these
recording::functions get turned into trees during playback.
I looked at the doing the equivalent of DEF_BUILTIN for any builtins
that haven't been created yet, but when to do it?
(a) in the builtin manager... but not all builtin-types are supported
yet (e.g. BT_FLOAT16), so it would be a big patch to do it that way
(b) in jit_langhook_init... but then if the user creates a builtin that
wasn't referenced before in a 2nd in-memory compile, I think the types
can get out-of-sync.
So I went with the patch I did as it seems to be the least invasive way
of fixing the specific problem.
Dave
More information about the Gcc-patches
mailing list