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
