* [committed] jit: fix ICE on BUILT_IN_TRAP [PR99126]
@ 2021-02-19 2:31 David Malcolm
2021-02-19 10:16 ` Andrea Corallo
0 siblings, 1 reply; 4+ messages in thread
From: David Malcolm @ 2021-02-19 2:31 UTC (permalink / raw)
To: gcc-patches, jit
I tried several approaches to fixing this; this seemed the
least invasive.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r11-7288-gb258e263e0d74ca1f76aeaac5f4d1abef6b13707.
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.
---
gcc/jit/jit-builtins.c | 14 +++++++-
gcc/jit/jit-builtins.h | 3 ++
gcc/jit/jit-playback.c | 11 +++---
gcc/testsuite/jit.dg/test-trap.c | 59 ++++++++++++++++++++++++++++++++
4 files changed, 82 insertions(+), 5 deletions(-)
create mode 100644 gcc/testsuite/jit.dg/test-trap.c
diff --git a/gcc/jit/jit-builtins.c b/gcc/jit/jit-builtins.c
index 18e477cc907..1ea96f4e025 100644
--- a/gcc/jit/jit-builtins.c
+++ b/gcc/jit/jit-builtins.c
@@ -162,7 +162,7 @@ builtins_manager::get_builtin_function (const char *name)
recording::function *
builtins_manager::get_builtin_function_by_id (enum built_in_function builtin_id)
{
- gcc_assert (builtin_id >= 0);
+ gcc_assert (builtin_id > BUILT_IN_NONE);
gcc_assert (builtin_id < END_BUILTINS);
/* Lazily build the functions, caching them so that repeated calls for
@@ -600,6 +600,18 @@ builtins_manager::make_ptr_type (enum jit_builtin_type,
return base_type->get_pointer ();
}
+/* Ensure that builtins that could be needed during optimization
+ get created ahead of time. */
+
+void
+builtins_manager::ensure_optimization_builtins_exist ()
+{
+ /* build_common_builtin_nodes does most of this, but not all.
+ We can't loop through all of the builtin_data array, we don't
+ support all types yet. */
+ (void)get_builtin_function_by_id (BUILT_IN_TRAP);
+}
+
/* Playback support. */
/* A builtins_manager is associated with a recording::context
diff --git a/gcc/jit/jit-builtins.h b/gcc/jit/jit-builtins.h
index b9f008dd4e2..c5e2b2dd600 100644
--- a/gcc/jit/jit-builtins.h
+++ b/gcc/jit/jit-builtins.h
@@ -127,6 +127,9 @@ public:
tree
get_attrs_tree (enum built_in_attribute attr);
+ void
+ ensure_optimization_builtins_exist ();
+
void
finish_playback (void);
diff --git a/gcc/jit/jit-playback.c b/gcc/jit/jit-playback.c
index 152ef250949..c6136301243 100644
--- a/gcc/jit/jit-playback.c
+++ b/gcc/jit/jit-playback.c
@@ -2949,6 +2949,11 @@ replay ()
/* Replay the recorded events: */
timevar_push (TV_JIT_REPLAY);
+ /* Ensure that builtins that could be needed during optimization
+ get created ahead of time. */
+ builtins_manager *bm = m_recording_ctxt->get_builtins_manager ();
+ bm->ensure_optimization_builtins_exist ();
+
m_recording_ctxt->replay_into (this);
/* Clean away the temporary references from recording objects
@@ -2957,13 +2962,11 @@ replay ()
refs. Hence we must stop using them before the GC can run. */
m_recording_ctxt->disassociate_from_playback ();
- /* The builtins_manager, if any, is associated with the recording::context
+ /* The builtins_manager is associated with the recording::context
and might be reused for future compiles on other playback::contexts,
but its m_attributes array is not GTY-labeled and hence will become
nonsense if the GC runs. Purge this state. */
- builtins_manager *bm = get_builtins_manager ();
- if (bm)
- bm->finish_playback ();
+ bm->finish_playback ();
timevar_pop (TV_JIT_REPLAY);
diff --git a/gcc/testsuite/jit.dg/test-trap.c b/gcc/testsuite/jit.dg/test-trap.c
new file mode 100644
index 00000000000..4eb65cd14c1
--- /dev/null
+++ b/gcc/testsuite/jit.dg/test-trap.c
@@ -0,0 +1,59 @@
+#include <stdlib.h>
+#include <stdio.h>
+#include <stddef.h>
+
+#include "libgccjit.h"
+
+#include "harness.h"
+
+void
+create_code (gcc_jit_context *ctxt, void *user_data)
+{
+ /* Let's try to inject the equivalent of:
+
+ void
+ test_trap (void)
+ {
+ *((int *)0) = 42;
+ }
+ */
+ gcc_jit_type *void_type
+ = gcc_jit_context_get_type (ctxt, GCC_JIT_TYPE_VOID);
+ gcc_jit_type *int_type
+ = gcc_jit_context_get_type (ctxt, GCC_JIT_TYPE_INT);
+ gcc_jit_type *int_ptr_type
+ = gcc_jit_type_get_pointer (int_type);
+
+ /* Build the test_fn. */
+ gcc_jit_function *func
+ = gcc_jit_context_new_function (ctxt, NULL,
+ GCC_JIT_FUNCTION_EXPORTED,
+ void_type,
+ "test_trap",
+ 0, NULL,
+ 0);
+
+ gcc_jit_block *initial = gcc_jit_function_new_block (func, "initial");
+
+ gcc_jit_rvalue *null_ptr
+ = gcc_jit_context_new_rvalue_from_ptr (ctxt, int_ptr_type, NULL);
+
+ /* "*((int *)0) = 42;" */
+ gcc_jit_block_add_assignment (
+ initial, NULL,
+ gcc_jit_rvalue_dereference (null_ptr, NULL),
+ gcc_jit_context_new_rvalue_from_int (ctxt, int_type, 42));
+
+ gcc_jit_block_end_with_void_return (initial, NULL);
+}
+
+void
+verify_code (gcc_jit_context *ctxt, gcc_jit_result *result)
+{
+ typedef void (*fn_type) (void);
+ CHECK_NON_NULL (result);
+ fn_type test_array =
+ (fn_type)gcc_jit_result_get_code (result, "test_trap");
+ CHECK_NON_NULL (test_array);
+ /* Don't attempt to call it. */
+}
--
2.26.2
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [committed] jit: fix ICE on BUILT_IN_TRAP [PR99126]
2021-02-19 2:31 [committed] jit: fix ICE on BUILT_IN_TRAP [PR99126] David Malcolm
@ 2021-02-19 10:16 ` Andrea Corallo
2021-02-19 10:32 ` Andrea Corallo
2021-02-19 21:13 ` David Malcolm
0 siblings, 2 replies; 4+ messages in thread
From: Andrea Corallo @ 2021-02-19 10:16 UTC (permalink / raw)
To: David Malcolm via Gcc-patches; +Cc: jit, David Malcolm, nd
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?
Regards
Andrea
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [committed] jit: fix ICE on BUILT_IN_TRAP [PR99126]
2021-02-19 10:16 ` Andrea Corallo
@ 2021-02-19 10:32 ` Andrea Corallo
2021-02-19 21:13 ` David Malcolm
1 sibling, 0 replies; 4+ messages in thread
From: Andrea Corallo @ 2021-02-19 10:32 UTC (permalink / raw)
To: Andrea Corallo via Gcc-patches; +Cc: jit, nd
Andrea Corallo via Gcc-patches <gcc-patches@gcc.gnu.org> writes:
> 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?
Ah also, shouldn't the fix be also back-ported?
Thanks
Andrea
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [committed] jit: fix ICE on BUILT_IN_TRAP [PR99126]
2021-02-19 10:16 ` Andrea Corallo
2021-02-19 10:32 ` Andrea Corallo
@ 2021-02-19 21:13 ` David Malcolm
1 sibling, 0 replies; 4+ messages in thread
From: David Malcolm @ 2021-02-19 21:13 UTC (permalink / raw)
To: Andrea Corallo, David Malcolm via Gcc-patches; +Cc: jit, nd
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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2021-02-19 21:13 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-02-19 2:31 [committed] jit: fix ICE on BUILT_IN_TRAP [PR99126] David Malcolm
2021-02-19 10:16 ` Andrea Corallo
2021-02-19 10:32 ` Andrea Corallo
2021-02-19 21:13 ` David Malcolm
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).