[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