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.