https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100263
Bug ID: 100263
Summary: Wrong removal of statement in copyprop3
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: stefansf at linux dot ibm.com
Target Milestone: ---
Target: s390*-*-*
Created attachment 50676
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50676&action=edit
copyprop3
int a = 3, d, l, o, p, q;
unsigned char b, f, g;
unsigned char c[9][9][3];
long e;
unsigned h;
short j, k;
static unsigned char r(int s) {
for (; b-2; b=b-2) {
int *m = &d;
if (a) {
char *n = &c[3][8][2];
*n = 1;
for (; h;)
for (; g;)
for (; e;)
;
} else {
int i = 0;
for (; i < 2; i++)
if (*m)
return 0;
if (s)
l = k |= ((j-- != b) <= s) - (long)s;
else
return f;
}
}
return 0;
}
int main() {
r(b);
if (c[3][8][2] != 1)
__builtin_abort ();
}
The outermost loop is executed 127 times. Since variable `a` does not change
from its initial value 3, the store to `c[3][8][2]` must materialize since the
infinite loops over variables h, g, e are never executed. However, running `gcc
-march=z13 t.c -O1 && ./a.out` results in an abort. Runs are successfull if
using different optimization levels than 1.
Prior to copyprop3 we have
<bb 3>
c__lsm.20_74 = MEM[(char *)&c + 107B];
<bb 4>
if (a.1_7 != 0)
goto <bb 5>; [50.00%]
else
goto <bb 59>; [50.00%]
<bb 5> [local count: 5160584476]:
c__lsm.20_94 = 1;
c__lsm_flag.21_95 = 1;
whereas afterwards the store to `c__lsm.20_94` is removed. Dump file contains:
Removing dead stmt c__lsm.20_94 = 1;
In total we have that the only store to `c[3][8][2]` happens in inner loop over
variable `h` which is never executed. There we have `MEM[(char *)&c + 107B] =
1;`.
Tested against g:3971aee9dd8d6323c377d1b241173f7d2b51a835 on IBM Z where it
fails. Runs successfully on x86 (by chance?).
Bisection stops at g:f9e1ea10e657af9fb02fafecf1a600740fd34409 which might not
be the root cause.
