Created attachment 48672 [details] Reproducer for this bug Hi. I get the following error with the attached reproducer: libgccjit.so: error: in build2, at tree.c:4743 0x7faff2a7ca97 build2(tree_code, tree_node*, tree_node*, tree_node*) ../../gcc/gcc/tree.c:4743 0x7faff2d61116 gcc::jit::playback::context::new_binary_op(gcc::jit::playback::location*, gcc_jit_binary_op, gcc::jit::playback::type*, gcc::jit::playback::rvalue*, gcc::jit::playback::rvalue*) ../../gcc/gcc/jit/jit-playback.c:867 0x7faff2d4c9ba gcc::jit::recording::assignment_op::replay_into(gcc::jit::playback::context*) ../../gcc/gcc/jit/jit-recording.c:5948 0x7faff2d4d548 gcc::jit::recording::context::replay_into(gcc::jit::playback::context*) ../../gcc/gcc/jit/jit-recording.c:688 0x7faff2d5b6e4 gcc::jit::playback::context::replay() ../../gcc/gcc/jit/jit-playback.c:2734 The reproducer is very big, so tell me if you want me to try to make it smaller. Thanks.
>libgccjit.so: error: in build2, at tree.c:4743 This means the PLUS_EXPR is being used when adding a pointer and an integer together. It needs to be POINTER_PLUS_EXPR. This does not mean the bug is not in the JIT library but it might mean a bug in your code.
(In reply to Andrew Pinski from comment #1) > >libgccjit.so: error: in build2, at tree.c:4743 > > This means the PLUS_EXPR is being used when adding a pointer and an integer > together. It needs to be POINTER_PLUS_EXPR. > > This does not mean the bug is not in the JIT library but it might mean a bug > in your code. A goal of libgccjit is that it shouldn't be possible to generate an ICE by making API calls; so this seems like a violation of that; we either need stronger type-checking at the API boundary, or to be smarter about how we make our trees.
(In reply to bouanto from comment #0) > The reproducer is very big, so tell me if you want me to try to make it > smaller. Yes please! The attachment reproduces the ICE for me, but is too big for me to work with. By adding this: gcc_jit_context_dump_to_file (ctxt_0x7feee9512e00, "/tmp/something.c", 1 /* update_locations */); to immediately after the create call code, it generates "source" locations in the generated /tmp/something.c. By poking in the debugger at the location info: (gdb) p loc->m_recording_loc->m_line $10 = 6773 it shows that the issue is triggered at line 6773, which is here in the dump: repeat_loop_body: *((unsigned char *)loop_var) = returnValue; intLocal = (unsigned long long)1; loop_var += *((unsigned char * *)&intLocal); <<<<< HERE goto repeat_loop_header; within extern bool _ZN4core3fmt3num12GenericRadix7fmt_int17h0643c6b8b66acb3dE (struct fmt::num::Binary * param, unsigned int param, struct fmt::Formatter * param) Is it possible for you to use the above info to make a small(er) reproducer? Thanks.
Created attachment 48674 [details] Smaller bug reproducer Here's a smaller bug reproducer.
(In reply to bouanto from comment #4) > Here's a smaller bug reproducer. Thanks; this reproduces it for me.