https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108984
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target| |x86_64-linux
Keywords| |lto
Target Milestone|--- |13.0
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
It does look like a wrong-code issue, the GEN_INT (-align_bytes) argument is
percieved as NULL.
0x00000000011fcf92 <+578>: mov $0x40,%eax
0x00000000011fcf97 <+583>: sub %r12d,%eax
0x00000000011fcf9a <+586>: cltq
0x00000000011fcf9c <+588>: mov 0x2c9ada0(,%rax,8),%rsi
0x00000000011fcfa4 <+596>: mov 0x196302d(%rip),%rax # 0x2b5ffd8
<this_target_rtl>
0x00000000011fcfab <+603>: mov (%rax),%rdi
0x00000000011fcfae <+606>: call 0x11fcca0 <gen_and2_insn(rtx, rtx)>
and %rsi is indeed NULL at the call. %rax is -448. gdb locates the computed
address at
$9 = (rtx *) 0x2c99fa0 <_ZL13ix86_builtins.lto_priv.0+22848>
so it looks like we run into
rtx
gen_rtx_CONST_INT (machine_mode mode ATTRIBUTE_UNUSED, HOST_WIDE_INT arg)
{
if (arg >= - MAX_SAVED_CONST_INT && arg <= MAX_SAVED_CONST_INT)
return const_int_rtx[arg + MAX_SAVED_CONST_INT];
but MAX_SAVED_CONST_INT is 64 and gdb says align_bytes is 512. So
something seems to have elided the range check.
