https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107581
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Version|unknown |12.2.0
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
I assume that reproducing with trunk is with checking enabled? It would be
nice if you can do a debugging session on the crashing go1 invocation and
inspect the GIMPLE that's being expanded. From the backtrace it looks like
it's some
BUILT_IN_ATOMIC_FETCH_* and expand_builtin_atomic_fetch_op does
/* Change the call to the specified function. */
fndecl = get_callee_fndecl (exp);
addr = CALL_EXPR_FN (exp);
STRIP_NOPS (addr);
gcc_assert (TREE_OPERAND (addr, 0) == fndecl);
TREE_OPERAND (addr, 0) = builtin_decl_explicit (ext_call);
and this builtin_decl_explicit ends up NULL so we later crash. Adding an
assert that this isn't so after the above would confirm this. We compute
ext_call (lib) as
case BUILT_IN_ATOMIC_ADD_FETCH_1:
case BUILT_IN_ATOMIC_ADD_FETCH_2:
case BUILT_IN_ATOMIC_ADD_FETCH_4:
case BUILT_IN_ATOMIC_ADD_FETCH_8:
case BUILT_IN_ATOMIC_ADD_FETCH_16:
{
enum built_in_function lib;
mode = get_builtin_sync_mode (fcode - BUILT_IN_ATOMIC_ADD_FETCH_1);
lib = (enum built_in_function)((int)BUILT_IN_ATOMIC_FETCH_ADD_1 +
(fcode - BUILT_IN_ATOMIC_ADD_FETCH_1));
target = expand_builtin_atomic_fetch_op (mode, exp, target, PLUS, true,
ignore, lib);
as said, tracing exactly what fcode and lib is here would be useful.
Eventually this is a frontend issue, not properly initializing the builtins.
