* [Bug target/108984] [13 Regression] LTO bootstrap causes testsuite ICE
2023-03-01 10:25 [Bug target/108984] New: [13 Regression] LTO bootstrap causes testsuite ICE rguenth at gcc dot gnu.org
@ 2023-03-01 10:44 ` rguenth at gcc dot gnu.org
2023-03-01 12:14 ` rguenth at gcc dot gnu.org
` (7 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-03-01 10:44 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug target/108984] [13 Regression] LTO bootstrap causes testsuite ICE
2023-03-01 10:25 [Bug target/108984] New: [13 Regression] LTO bootstrap causes testsuite ICE rguenth at gcc dot gnu.org
2023-03-01 10:44 ` [Bug target/108984] " rguenth at gcc dot gnu.org
@ 2023-03-01 12:14 ` rguenth at gcc dot gnu.org
2023-03-01 12:21 ` jakub at gcc dot gnu.org
` (6 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-03-01 12:14 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug target/108984] [13 Regression] LTO bootstrap causes testsuite ICE
2023-03-01 10:25 [Bug target/108984] New: [13 Regression] LTO bootstrap causes testsuite ICE rguenth at gcc dot gnu.org
2023-03-01 10:44 ` [Bug target/108984] " rguenth at gcc dot gnu.org
2023-03-01 12:14 ` rguenth at gcc dot gnu.org
@ 2023-03-01 12:21 ` jakub at gcc dot gnu.org
2023-03-01 13:05 ` rguenth at gcc dot gnu.org
` (5 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-03-01 12:21 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug target/108984] [13 Regression] LTO bootstrap causes testsuite ICE
2023-03-01 10:25 [Bug target/108984] New: [13 Regression] LTO bootstrap causes testsuite ICE rguenth at gcc dot gnu.org
` (2 preceding siblings ...)
2023-03-01 12:21 ` jakub at gcc dot gnu.org
@ 2023-03-01 13:05 ` rguenth at gcc dot gnu.org
2023-03-01 13:23 ` rguenth at gcc dot gnu.org
` (4 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-03-01 13:05 UTC (permalink / raw)
To: gcc-bugs
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).
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug target/108984] [13 Regression] LTO bootstrap causes testsuite ICE
2023-03-01 10:25 [Bug target/108984] New: [13 Regression] LTO bootstrap causes testsuite ICE rguenth at gcc dot gnu.org
` (3 preceding siblings ...)
2023-03-01 13:05 ` rguenth at gcc dot gnu.org
@ 2023-03-01 13:23 ` rguenth at gcc dot gnu.org
2023-03-01 13:34 ` rguenth at gcc dot gnu.org
` (3 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-03-01 13:23 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug target/108984] [13 Regression] LTO bootstrap causes testsuite ICE
2023-03-01 10:25 [Bug target/108984] New: [13 Regression] LTO bootstrap causes testsuite ICE rguenth at gcc dot gnu.org
` (4 preceding siblings ...)
2023-03-01 13:23 ` rguenth at gcc dot gnu.org
@ 2023-03-01 13:34 ` rguenth at gcc dot gnu.org
2023-03-01 13:45 ` jakub at gcc dot gnu.org
` (2 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-03-01 13:34 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug target/108984] [13 Regression] LTO bootstrap causes testsuite ICE
2023-03-01 10:25 [Bug target/108984] New: [13 Regression] LTO bootstrap causes testsuite ICE rguenth at gcc dot gnu.org
` (5 preceding siblings ...)
2023-03-01 13:34 ` rguenth at gcc dot gnu.org
@ 2023-03-01 13:45 ` jakub at gcc dot gnu.org
2023-03-01 14:01 ` rguenth at gcc dot gnu.org
2023-03-02 7:25 ` rguenth at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-03-01 13:45 UTC (permalink / raw)
To: gcc-bugs
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] ...
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug target/108984] [13 Regression] LTO bootstrap causes testsuite ICE
2023-03-01 10:25 [Bug target/108984] New: [13 Regression] LTO bootstrap causes testsuite ICE rguenth at gcc dot gnu.org
` (6 preceding siblings ...)
2023-03-01 13:45 ` jakub at gcc dot gnu.org
@ 2023-03-01 14:01 ` rguenth at gcc dot gnu.org
2023-03-02 7:25 ` rguenth at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-03-01 14:01 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug target/108984] [13 Regression] LTO bootstrap causes testsuite ICE
2023-03-01 10:25 [Bug target/108984] New: [13 Regression] LTO bootstrap causes testsuite ICE rguenth at gcc dot gnu.org
` (7 preceding siblings ...)
2023-03-01 14:01 ` rguenth at gcc dot gnu.org
@ 2023-03-02 7:25 ` rguenth at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-03-02 7:25 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 10+ messages in thread