For the following testcase: long c; long *d = &c; int a, e, f; int main(void) { for (; f <= 5; f++) { e = 0; for (; e <= 5; e++) { a = 1; for (; a <= 5; a++); *d = 0; if (f) break; } } return a; } Compiling with -O{0,1,2,3} (for both gcc and clang), as expected, the program returns 6. Compiling with -Os, the program returns 1 (since r11-408-g84935c9822183ce403bb361c5f405711b9a808c6). I've reproduced this on both x86 and aarch64. Interestingly, compiling with -Os -fno-strict-aliasing, we no longer see the wrong code bug (the program returns 6). However, I believe this program is free of strict aliasing violations. To reproduce: $ bin/gcc wrong_code.c $ ./a.out || echo $? 6 $ bin/gcc wrong_code.c -Os $ ./a.out || echo $? 1 $ bin/gcc wrong_code.c -Os -fno-strict-aliasing $ ./a.out || echo $? 6
Slightly adjusted testcase for the testsuite (gcc.c-torture/execute/ ?): long long e, *d = &e; int a, b, c; int main () { for (; c <= 5; c++) for (b = 0; b <= 5; b++) { for (a = 1; a <= 5; a++) ; *d = 0; if (c) break; } if (a != 6) __builtin_abort (); return 0; }
I'll have a look.
It's lim4 that does the bogus transform. It seems to be confused by the dead store in BB3: <bb 3> [local count: 118111600]: a = 1; a = 6; *d.2_3 = 0; ivtmp.15_9 = ivtmp.15_24 + 1; if (c.7_7 != 0) goto <bb 9>; [5.50%] else goto <bb 10>; [94.50%] and re-materializes the a = 1 store but not the a = 6 one.
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>: https://gcc.gnu.org/g:0df746afc50a47d1eb53a401e017c4373cf05641 commit r11-3321-g0df746afc50a47d1eb53a401e017c4373cf05641 Author: Richard Biener <rguenther@suse.de> Date: Mon Sep 21 14:04:25 2020 +0200 tree-optimization/97135 - fix dependence check in store-motion The following fixes a dependence check where in the particular place we cannot ignore self-dependences. 2020-09-21 Richard Biener <rguenther@suse.de> PR tree-optimization/97135 * tree-ssa-loop-im.c (sm_seq_push_down): Do not ignore self-dependences. * gcc.dg/torture/pr97135.c: New testcase.
Fixed.
*** Bug 97152 has been marked as a duplicate of this bug. ***