https://godbolt.org/z/qn3dsxsW8 Reproducer: #include <stdio.h> unsigned short a = 42; unsigned short b = 1; long long int c = 1; unsigned char var_120; unsigned char var_123; void test(unsigned short a, unsigned short b, long long int c) __attribute__((noipa)); void test(unsigned short a, unsigned short b, long long c) { for (char i = 0; i < (char)c; i += 5) if (!b) var_120 = a; else var_123 = a; } int main() { test(a, b, c); printf("%hhu\n", var_123); //if (var_123 != 42) // __builtin_abort(); } Error: >$ g++ -O3 small.cpp && ./a.out 0 >$ g++ -O2 small.cpp && ./a.out 42 GCC version: Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/testing/gcc/bin_master/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /testing/gcc/gcc_src_master/configure --enable-multilib --prefix=/testing/gcc/bin_master --disable-bootstrap Thread model: posix Supported LTO compression algorithms: zlib gcc version 12.0.0 20211023 (experimental) (GCC) root@abe71269b867:/testing/result/S_1635079215/reduce# cat /testing/gcc/gcc_rev.txt git://gcc.gnu.org/git/gcc.git:master e3725624ec0735996a18e1a90317e230bef899ac
<bb 6> [local count: 70079549]: var_123 = _27(D); goto <bb 3>; [100.00%] Fre messed up: Before: # var_120_lsm.8_36 = PHI <_1(5), _27(D)(4)> # var_120_lsm_flag.9_37 = PHI <1(5), 0(4)> # var_123_lsm.10_38 = PHI <_24(D)(5), _43(4)> # var_123_lsm_flag.11_39 = PHI <0(5), 1(4)> After: # var_120_lsm.8_36 = PHI <_1(5), _27(D)(4)> # var_120_lsm_flag.9_37 = PHI <1(5), 0(4)> # var_123_lsm_flag.11_39 = PHI <0(5), 1(4)> This would mean this was caused by r12-4625-gfe8475c500.
Mine then.
So the "logic" is that # var_120_lsm.9_7 = PHI <_42(6), _29(D)(5)> # var_123_lsm.11_13 = PHI <_26(D)(6), _1(5)> can be considered equal since _42 and _26(D) are optimistically equal and _29(D) and _1 are optimistically equal as well. But 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. Hmm, we're also treating a[i][undef] and a[undef][i] as the same but there I guess both undefs are "used" and thus both expressions invoke undefined behavior. While with the PHIs we don't know which edge will be taken and thus which copy will result in undefined behavior.
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>: https://gcc.gnu.org/g:aa15952d646fd5dd569fce287b719a737ae66e4f commit r12-4650-gaa15952d646fd5dd569fce287b719a737ae66e4f 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.
Fixed.
*** Bug 102902 has been marked as a duplicate of this bug. ***