[Bug target/108984] New: [13 Regression] LTO bootstrap causes testsuite ICE

[Bug target/108984] New: [13 Regression] LTO bootstrap causes testsuite ICE

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108984

            Bug ID: 108984
           Summary: [13 Regression] LTO bootstrap causes testsuite ICE
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

I'm seeing the following ICE in a testsuite run after a simple
../configure --with-build-config=bootstrap-lto on x86_64-linux

#0  0x0000000000de94bf in general_operand (op=0x0, mode=E_DImode)
    at ../../gcc/gcc/recog.cc:1435
#1  0x00000000018740f9 in nonimmediate_operand (mode=E_DImode, op=0x0)
    at ../../gcc/gcc/recog.cc:1720
#2  x86_64_szext_general_operand (mode=E_DImode, op=0x0)
    at ../../gcc/gcc/config/i386/predicates.md:505
#3  x86_64_szext_general_operand (op=0x0, mode=E_DImode)
    at ../../gcc/gcc/config/i386/predicates.md:503
#4  0x00000000011fcd1d in insn_operand_matches (operand=0x0, opno=2,
    icode=CODE_FOR_anddi3) at ../../gcc/gcc/optabs.cc:7793
#5  gen_and2_insn (x=0x7ffff67b9420, y=0x0)
    at ../../gcc/gcc/config/i386/i386.cc:8415
#6  0x00000000011fcfb3 in ix86_expand_prologue ()
    at ../../gcc/gcc/config/i386/i386.cc:8580
#7  0x00000000011df0fb in gen_prologue ()
    at ../../gcc/gcc/config/i386/i386.md:16674
#8  target_gen_prologue () at ../../gcc/gcc/config/i386/i386.md:24241
#9  0x0000000000b504ec in make_prologue_seq ()
    at ../../gcc/gcc/function.cc:5841
#10 0x0000000000b60154 in thread_prologue_and_epilogue_insns ()
    at ../../gcc/gcc/function.cc:6073

happens when stack_realign_drap, for example for gcc.dg/stack-usage-2.c

[Bug target/108984] [13 Regression] LTO bootstrap causes testsuite ICE

[rguenth at gcc dot gnu.org]

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.

[Bug target/108984] [13 Regression] LTO bootstrap causes testsuite ICE

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108984

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hubicka at gcc dot gnu.org

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
.optimized of LTRANS unit 60 has

  # DEBUG BEGIN_STMT
  # DEBUG D#456 => -align_bytes_448
  # DEBUG D#453 => (long int) D#456
  # DEBUG D#245 => 0
  # DEBUG arg => D#453
  # DEBUG INLINE_ENTRY gen_rtx_CONST_INT
  # DEBUG D#246 => D#245
  # DEBUG mode => D#246
  _1005 = 64 - align_bytes_448;
  _1045 = (long int) _1005;
  _1046 = const_int_rtx[_1045];
  # DEBUG mode => NULL
  # DEBUG arg => NULL
  _95 = this_target_rtl;
  _96 = _95->x_global_rtl[0];
  _97 = gen_and2_insn (_96, _1046);

and after IPA we see

  # DEBUG BEGIN_STMT
  _92 = -align_bytes_448;
  _93 = (long int) _92;
  # DEBUG D#245ptD.0 => 0
  arg_1327 = _93;
  # DEBUG arg => arg_1327
  # DEBUG arg => arg_1327
  # DEBUG INLINE_ENTRY gen_rtx_CONST_INT
  # DEBUG D#246ptD.0 => D#245ptD.0
  # DEBUG mode => D#246ptD.0
  _1042 = arg_1327;
  _1043 = (unsigned long) _1042;
  _1044 = _1043 + 64;
  if (_1044 <= 128)
    goto <bb 59>; [51.12%]
  else
    goto <bb 60>; [48.88%]

  <bb 59> [local count: 67075190]:
  _1045 = _1042 + 64;
  _1046 = const_int_rtx[_1045];
  _1258 = _1046;
  # DEBUG arg => NULL
  # DEBUG mode => NULL
  # DEBUG arg => NULL
  _94 = _1258;
  _95 = this_target_rtl;
  _96 = _95->x_global_rtl[0];
  # USE = anything
  # CLB = anything
  _97 = gen_and2_insn (_96, _94);
  # USE = anything
  # CLB = anything
  insn_472 = emit_insn (_97);
  # DEBUG insn => insn_472
  # DEBUG BEGIN_STMT
  # DEBUG BEGIN_STMT
  # DEBUG _rtx => insn_472
  # DEBUG BEGIN_STMT
  _98 = insn_472->code;
  _99 = _98 + 65528;
  switch (_98) <default: <L12> [0.00%], case 8 ... 11: <L13> [100.00%], case
13: <L13> [100.00%], case 25: <L13> [100.00%]>

  <bb 60> [local count: 64136059]:
  _1047 = const_int_htab;
  _1048 = (unsigned int) _1042;
  # USE = anything
  # CLB = anything
  __builtin_unreachable ();

so it looks like the else path materialized to be unreachable for some
reason.  Before IPA we have

  _92 = -align_bytes_448;
  _93 = (long int) _92;
  _94 = gen_rtx_CONST_INT (0, _93);

IPA CP knows

    callsite  ix86_expand_prologue/1286343 -> gen_rtx_CONST_INT/244924 :
       param 0: CONST: 0
         value: 0x0, mask: 0x0
         Unknown VR
       param 1: UNKNOWN
         value: 0x0, mask:
0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
         VR  [-536870911, -5]

    callsite  ix86_expand_prologue/1286343 -> gen_rtx_CONST_INT/244924 :
       param 0: CONST: 0
         value: 0x0, mask: 0x0
         Unknown VR
       param 1: UNKNOWN
         value: 0x0, mask:
0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
         VR  [-536870911, 0]

and it at least creates a constprop clone for VOIDmode.

Considering gen_rtx_CONST_INT.constprop/2274667 with 38 size
 to be inlined into ix86_expand_prologue/1286343 in unknown:-1
 Estimated badness is -0.000000, frequency 0.12.
    Badness calculation for ix86_expand_prologue/1286343 ->
gen_rtx_CONST_INT.constprop/2274667
      size growth 2, time 4.533600 unspec 7.533600 IPA hints: cross_module
      -0.000000: guessed profile. frequency 0.122200, count -1 caller count -1
time saved 1.955200 overall growth 62692 (current) 39603 (original) 104883
(compensated)
      Adjusted by hints -0.000000
  Parm map:  -5 -5


I'm somewhat lost as to where to look for why that unreachable () is created.
It looks like the inliner redirects things this way.

[Bug target/108984] [13 Regression] LTO bootstrap causes testsuite ICE

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108984

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
There is redirect_to_unreachable and a couple of other places (though at least
half of them are related to devirtualization which shouldn't be happening
here):
grep builtin_decl_unreachable ipa*
ipa.cc:     target = cgraph_node::get_create (builtin_decl_unreachable ());
ipa-fnsummary.cc:    = cgraph_node::get_create (builtin_decl_unreachable ());
ipa-prop.cc:      target = builtin_decl_unreachable ();
ipa-prop.cc:  tree new_target = builtin_decl_unreachable ();
So, I'd add a breakpoint on builtin_decl_unreachable and see where it is called
for this code.

[Bug target/108984] [13 Regression] LTO bootstrap causes testsuite ICE

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108984

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
So there's interesting IPA summary on gen_rtx_CONST_INT.constprop/2274667

    find_slot_with_hash.constprop/2274668 function not considered for inlining
      freq:0.49 loop depth: 0 size: 6 time: 15 callee size:41 stack: 0
predicate: (op1,((unsigned long) #),(# + 64) > 128)
       op1 is compile time invariant
       op1 points to local or readonly memory
       op3 is compile time invariant

it looks like the parameter removal does not adjust the parameter number?
for the constprop clone the first parameter is constant VOIDmode (0), but
the second is unknown.  Not sure what '#' and op1 refer to for the
predicate though.  The above is from the IPA inline dump at WPA time.

Note I do not see redirect_to_unreachable being called with e->callee->m_uid ==
2274668 during WPA.  The function is called a lot, but too many times to
watch all of them (it's not called at LTRANS time at all).

[Bug target/108984] [13 Regression] LTO bootstrap causes testsuite ICE

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108984

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
But

void foo ();
int data[128];
static int bar (int i, int j)
{
  if (j > -64 && j < 64)
    return data[j+64];
  foo ();
}

int baz (int j)
{
  return bar (0, j);
}

seems to work fine with -O2 -fno-early-inlining -fipa-cp-clone, we create
a similar clone and have a similar inlining predicate.  But still the
predicate looks exactly the same whether we IPA CP or not ...

  calls:
    foo/3 function body not available
      freq:0.49 loop depth: 0 size: 1 time: 10 predicate: (op1,((unsigned int)
#),(# + 63) > 126)

But with IPA CP we get

  Parm map:  -5 0

I suspect -5 is for "removed" and 1 is mapped to 0.  But with the original
case we see

  Parm map:  -5 -5

so no remaining parameter but op1 is referenced in the predicate?

[Bug target/108984] [13 Regression] LTO bootstrap causes testsuite ICE

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108984

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
   Estimating body: gen_rtx_CONST_INT.constprop/2274667
   Known to be false: not inlined, op1,((unsigned long) #),(# + 64) > 128
   size:6 time:4.533600 nonspec time:7.533600 loops with known
iterations:0.000000 known strides:0.000000
  enqueuing call ix86_expand_prologue/1286343 ->
gen_rtx_CONST_INT.constprop/2274667, badness -0.000000

there are a few calls to the cprop clone but the above is likely the offending
one.

[Bug target/108984] [13 Regression] LTO bootstrap causes testsuite ICE

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108984

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Isn't what happens in i386.cc more like:
void foo (long);
int data[128];
static int bar (int i, long j)
{
  if (j >= -64 && j <= 64)
    return data[j+64];
  foo (j);
}

int baz (unsigned int j)
{
  int k = j / 8;
  return bar (0, -k);
}
?  Because we know in the caller it is [-0x1fffffff, 0] ...

[Bug target/108984] [13 Regression] LTO bootstrap causes testsuite ICE

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108984

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
I realized I have some value-range patches in the tree where I ran into this
(besides the pending dwarf2out change).  I'm now trying to reproduce on
r13-6384-ge3837b6f6c28a1 without changes.

[Bug target/108984] [13 Regression] LTO bootstrap causes testsuite ICE

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108984

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
OK, it's somehow caused by the series of local value_range changes I had in the
tree.