[Bug jit/95426] libgccjit.so: error: RTL check: expected elt 2 type 'B', have '0' (rtx barrier) in BLOCK_FOR_INSN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95426 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from David Malcolm --- Should be fixed by the above commit.
[Bug jit/95426] libgccjit.so: error: RTL check: expected elt 2 type 'B', have '0' (rtx barrier) in BLOCK_FOR_INSN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95426 --- Comment #9 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:44564c4c811f4751daf363ca019a9f9bed702f4f commit r11-839-g44564c4c811f4751daf363ca019a9f9bed702f4f Author: David Malcolm Date: Sun May 31 13:28:41 2020 -0400 jit: fix __builtin_unreachable [PR 95426] PR jit/95426 reports a crash deep inside "expand" when using __builtin_unreachable via gcc_jit_context_get_builtin_function, due to BLOCK_FOR_INSN being erroneously used on a barrier within rtl_verify_bb_pointers. The root cause turns out to be that I didn't implement LANG_HOOKS_COMMON_ATTRIBUTE_TABLE and LANG_HOOKS_FORMAT_ATTRIBUTE_TABLE for the jit "frontend". When building a decl for the builtin, the libgccjit frontend generates a chain of attributes names, but when this is passed to decl_attributes and the attributes are looked up by namespace and name within lookup_scoped_attribute_spec, attributes_table is empty. Hence no attributes were being associated with the fndecl, and so ECF_NORETURN was not set on the gimple_call (along with various other flags missing on the decl, etc), and so the call is treated as not terminating its BB, and so the CFG rapidly diverges from the equivalent created by the C frontend. This patch fixes things by implementing these langhooks, copying the minimal attribute-handling code from LTO. I stepped through the creation of the fndecl and verified that with this fix it has the same attributes as the equivalent created by the C frontend. gcc/jit/ChangeLog: PR jit/95426 * dummy-frontend.c: Include "options.h", "stringpool.h", and "attribs.h". (ATTR_EXCL): New, copied from lto/lto-lang.c. (attr_noreturn_exclusions): Likewise. (attr_returns_twice_exclusions): Likewise. (attr_const_pure_exclusions): Likewise. (jit_attribute_table): Likewise, copied from lto_attribute_table. (jit_format_attribute_table): Likewise, copied from lto_format_attribute_table. (handle_noreturn_attribute): New, copied from lto/lto-lang.c. (handle_leaf_attribute): Likewise. (handle_const_attribute): Likewise. (handle_malloc_attribute): Likewise. (handle_pure_attribute): Likewise. (handle_novops_attribute): Likewise. (get_nonnull_operand): Likewise. (handle_nonnull_attribute): Likewise. (handle_nothrow_attribute): Likewise. (handle_sentinel_attribute): Likewise. (handle_type_generic_attribute): Likewise. (handle_transaction_pure_attribute): Likewise. (handle_returns_twice_attribute): Likewise. (handle_patchable_function_entry_attribute): Likewise. (ignore_attribute): Likewise. (handle_format_attribute): Likewise. (handle_format_arg_attribute): Likewise. (handle_fnspec_attribute): Likewise. (LANG_HOOKS_COMMON_ATTRIBUTE_TABLE): Define. (LANG_HOOKS_FORMAT_ATTRIBUTE_TABLE): Define. gcc/testsuite/ChangeLog: PR jit/95426 * jit.dg/all-non-failing-tests.h: Add note about... * jit.dg/test-builtin-unreachable.c: New test.
[Bug jit/95426] libgccjit.so: error: RTL check: expected elt 2 type 'B', have '0' (rtx barrier) in BLOCK_FOR_INSN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95426 --- Comment #8 from David Malcolm --- Looks like the way libgccjit sets up attributes (such as "noreturn") on builtins has somehow become a no-op. Am investigating.
[Bug jit/95426] libgccjit.so: error: RTL check: expected elt 2 type 'B', have '0' (rtx barrier) in BLOCK_FOR_INSN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95426 --- Comment #7 from David Malcolm --- This seems like a bug with how libgccjit interacts with __builtin_unreachable, sorry. As a workaround, try removing the __builtin_unreachable calls for now.
[Bug jit/95426] libgccjit.so: error: RTL check: expected elt 2 type 'B', have '0' (rtx barrier) in BLOCK_FOR_INSN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95426 --- Comment #6 from bouanto at zoho dot com --- Any idea how I should change the generated code to make it work? Or will a patch not require changing the generated code? Thanks.
[Bug jit/95426] libgccjit.so: error: RTL check: expected elt 2 type 'B', have '0' (rtx barrier) in BLOCK_FOR_INSN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95426 --- Comment #5 from David Malcolm --- Created attachment 48657 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48657=edit Reduced test case I've reduced the reproducer you posted to this test case. Seems to require a call to __builtin_unreachable followed by code, without optimization, leading to a crash in the "expand" pass when transitioning from gimple to RTL internally, due to an unexpected barrier insn in the RTL.
[Bug jit/95426] libgccjit.so: error: RTL check: expected elt 2 type 'B', have '0' (rtx barrier) in BLOCK_FOR_INSN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95426 David Malcolm changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2020-05-31 Status|UNCONFIRMED |ASSIGNED --- Comment #4 from David Malcolm --- The reproducer you attached reproduces the crash from comment #0 for me; marking as ASSIGNED. (gdb) call debug(insn) (barrier 29 28 30)
[Bug jit/95426] libgccjit.so: error: RTL check: expected elt 2 type 'B', have '0' (rtx barrier) in BLOCK_FOR_INSN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95426 --- Comment #3 from David Malcolm --- Aha - thanks. Re-reading https://gcc.gnu.org/onlinedocs/jit/topics/contexts.html#debugging it looks like the documentation for these entrypoints could use some clarification on whether each one relates to the current state of the context, or whether it takes effect when the context is compiled.
[Bug jit/95426] libgccjit.so: error: RTL check: expected elt 2 type 'B', have '0' (rtx barrier) in BLOCK_FOR_INSN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95426 --- Comment #2 from bouanto at zoho dot com --- Created attachment 48648 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48648=edit Reproducer for the bug Oh, I see what I was doing wrong: I thought it was an option, so I was calling this function at the beginning. Also, I had to comment the line creating the type GCC_JIT_TYPE_COMPLEX_DOUBLE in order for this reproducer to reproduce the issue. With that line, it does another error: libgccjit.so: error: gcc_jit_context_get_type: unrecognized value for enum gcc_jit_types: 21 That's probably another bug, though.
[Bug jit/95426] libgccjit.so: error: RTL check: expected elt 2 type 'B', have '0' (rtx barrier) in BLOCK_FOR_INSN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95426
--- Comment #1 from David Malcolm ---
gcc_jit_context_dump_reproducer_to_file runs in the testsuite, and I see it
generating sane-looking reproducers (with non-empty create_code functions).
Are you calling gcc_jit_context_dump_reproducer_to_file before or after calling
gcc_jit_context_compile? (or when not calling gcc_jit_context_compile?) I
have a feeling that calling it after an unsuccessful compile might break it
("unsuccessful" in the sense of a compile that generates a non-fatal error but
doesn't crash the process).
Can you attach the result of gcc_jit_context_dump_reproducer_to_file to this
bug please?
Another thing to try might be to use gcc_jit_context_set_logfile and to attach
the resulting logfile (though you may need to flush it and close it and not
call gcc_jit_context_compile).
