This appears to be a recent regression. [575] % gcctk -v Using built-in specs. COLLECT_GCC=gcctk COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-trunk/configure --disable-bootstrap --prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++ --disable-werror --enable-multilib --with-system-zlib Thread model: posix Supported LTO compression algorithms: zlib gcc version 12.0.0 20211022 (experimental) [master r12-4624-gae5c540662e] (GCC) [576] % [576] % gcctk -O2 small.c; ./a.out [577] % [577] % gcctk -O3 small.c [578] % timeout -s 9 10 ./a.out Killed [579] % [579] % cat small.c int printf (const char *, ...); int a, b, c, d, e, f; int main() { int g; short h = 1; for (; e < 2; e++) { L1: f = 1; while (b > 0 || a > 0) { g++; h++; printf("%d", g); } L2: if (!h && (!c || a)) goto L1; if (c) goto L2; } return 0; }
Confirmed. -fno-ivopts fixes the issue. I suspect (have not fully looked yet), this is the same issue as PR 100810. Initializing g also fixes the issue which is another sign it is the same issue as PR 100810.
*** Bug 102922 has been marked as a duplicate of this bug. ***
I guess fixed with: commit aa15952d646fd5dd569fce287b719a737ae66e4f (HEAD -> master, origin/trunk, origin/master, origin/HEAD) Author: Richard Biener <rguenther@suse.de> Date: Mon Oct 25 09:33:15 2021 +0200 tree-optimization/102920 - fix PHI VN with undefined args This fixes a latent issue exposed by now allowing VN_TOP in PHI arguments. We may only use optimistic equality when merging values on different edges, not when merging values on the same edge - in particular we may not choose the undef value on any edge when there's a not undef value as well. 2021-10-25 Richard Biener <rguenther@suse.de> PR tree-optimization/102920 * tree-ssa-sccvn.h (expressions_equal_p): Add argument controlling VN_TOP matching behavior. * tree-ssa-sccvn.c (expressions_equal_p): Likewise. (vn_phi_eq): Do not optimistically match VN_TOP. * gcc.dg/torture/pr102920.c: New testcase.
(In reply to Martin Liška from comment #3) > I guess fixed with: > > commit aa15952d646fd5dd569fce287b719a737ae66e4f (HEAD -> master, > origin/trunk, origin/master, origin/HEAD) > Author: Richard Biener <rguenther@suse.de> > Date: Mon Oct 25 09:33:15 2021 +0200 > > tree-optimization/102920 - fix PHI VN with undefined args > > This fixes a latent issue exposed by now allowing VN_TOP in PHI > arguments. We may only use optimistic equality when merging values on > different edges, not when merging values on the same edge - in particular > we may not choose the undef value on any edge when there's a not undef > value as well. > > 2021-10-25 Richard Biener <rguenther@suse.de> > > PR tree-optimization/102920 > * tree-ssa-sccvn.h (expressions_equal_p): Add argument > controlling VN_TOP matching behavior. > * tree-ssa-sccvn.c (expressions_equal_p): Likewise. > (vn_phi_eq): Do not optimistically match VN_TOP. > > * gcc.dg/torture/pr102920.c: New testcase. Sorry, wrong PR.
Dup. *** This bug has been marked as a duplicate of bug 102920 ***
Hi Richard, I just noticed that this issue was mis-categorized as a duplicate of 102920, which was filed later. It's not very important, but it would probably be nice to correctly label the issues in the bug tracker. Thanks.
Reopening.
It is basically the same as PR 100810. we have a conditional use of an unitialized variable and ivopts decides to make it unconditional ...
PR100810 is P1 so lets make this one, too. Just to say, the bug will be very difficult to fix for good because fundamentally a default def SSA looks like to have the same value for two different uses but the way we handle it means that guarantee is violated. It's difficult to cure that not only because former defs can become undefs. We'd need a way to stabilize the value on an uninit use but without sacrifying optimization (for uses in PHI nodes).
Confirmed as duplicate, -fno-ivopts fixes it, as does the proposed patch(es) in the duplicate. *** This bug has been marked as a duplicate of bug 100810 ***