[Bug middle-end/110228] [13/14 Regression] llvm-16 miscompiled due to an maybe uninitialized variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110228 --- Comment #34 from Sergei Trofimovich --- (In reply to rguent...@suse.de from comment #33) > On Tue, 4 Jul 2023, slyfox at gcc dot gnu.org wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110228 > > > > --- Comment #32 from Sergei Trofimovich --- > > (In reply to Richard Biener from comment #29) > > > I can't reproduce the original failure on trunk or with GCC 13.1, but the > > > testcase from comment#16 is now fixed. I also cannot reproduce the > > > testcase > > > from comment#21 before the fix. > > > > > > Can people double-check this is now fixed, maybe also on the branch when > > > this > > > fix is cherry-picked? > > > > Test suite on llvm-16 still fails the same single 'LLVM :: > > ExecutionEngine/JITLink/X86/MachO_weak_references.s' test for me. > > > > gcc was built from 2c12ccf800fc7890925402d30a02f0fa9e2627cc. > > Can you try 819285ef10a87d663f8c181c06aa88d1d9f75aed - your small > testcase looks OK now. Ah, that commit fixes 'LLVM :: ExecutionEngine/JITLink/X86/MachO_weak_references.s' and the rest of llvm-16 test suite for me. Thank you!
[Bug middle-end/110228] [13/14 Regression] llvm-16 miscompiled due to an maybe uninitialized variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110228 --- Comment #33 from rguenther at suse dot de --- On Tue, 4 Jul 2023, slyfox at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110228 > > --- Comment #32 from Sergei Trofimovich --- > (In reply to Richard Biener from comment #29) > > I can't reproduce the original failure on trunk or with GCC 13.1, but the > > testcase from comment#16 is now fixed. I also cannot reproduce the testcase > > from comment#21 before the fix. > > > > Can people double-check this is now fixed, maybe also on the branch when > > this > > fix is cherry-picked? > > Test suite on llvm-16 still fails the same single 'LLVM :: > ExecutionEngine/JITLink/X86/MachO_weak_references.s' test for me. > > gcc was built from 2c12ccf800fc7890925402d30a02f0fa9e2627cc. Can you try 819285ef10a87d663f8c181c06aa88d1d9f75aed - your small testcase looks OK now.
[Bug middle-end/110228] [13/14 Regression] llvm-16 miscompiled due to an maybe uninitialized variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110228
--- Comment #32 from Sergei Trofimovich ---
(In reply to Richard Biener from comment #29)
> I can't reproduce the original failure on trunk or with GCC 13.1, but the
> testcase from comment#16 is now fixed. I also cannot reproduce the testcase
> from comment#21 before the fix.
>
> Can people double-check this is now fixed, maybe also on the branch when this
> fix is cherry-picked?
Test suite on llvm-16 still fails the same single 'LLVM ::
ExecutionEngine/JITLink/X86/MachO_weak_references.s' test for me.
gcc was built from 2c12ccf800fc7890925402d30a02f0fa9e2627cc.
The following test still fails for me:
$ cat bug.c
static unsigned a[4] = {1,1,1,1};
__attribute__((noipa))
static void bug(unsigned * p, unsigned *t, int n) {
unsigned LookupFlags;
for(int i = 0; i < n; i++) {
unsigned v = t[i];
if (v == 0) LookupFlags = 0;
else if (v == 1) LookupFlags = 1;
*p = LookupFlags;
}
}
int main() {
unsigned r = 42;
bug(, a, 4);
if (r != 1) __builtin_abort();
return 0;
}
$ gcc bug.c -o bug -O1 -Wall && ./bug
bug.c: In function 'bug':
bug.c:10:15: warning: 'LookupFlags' may be used uninitialized
[-Wmaybe-uninitialized]
10 | else if (v == 1) LookupFlags = 1;
| ^
bug.c:5:15: note: 'LookupFlags' was declared here
5 | unsigned LookupFlags;
| ^~~
Aborted (core dumped)
bug.c.255t.optimized still turns stores into '|=' against uninit value:
__attribute__((noipa, noinline, noclone, no_icf))
void bug (unsigned int * p, unsigned int * t, int n)
{
unsigned long ivtmp.8;
unsigned int v;
unsigned int LookupFlags;
_Bool _16;
unsigned int _17;
unsigned int _18;
void * _19;
unsigned long _20;
unsigned long _26;
unsigned long _28;
[local count: 118111600]:
if (n_10(D) > 0)
goto ; [89.00%]
else
goto ; [11.00%]
[local count: 105119324]:
ivtmp.8_21 = (unsigned long) t_11(D);
_20 = (unsigned long) n_10(D);
_26 = _20 * 4;
_28 = ivtmp.8_21 + _26;
[local count: 955630225]:
# LookupFlags_22 = PHI
# ivtmp.8_6 = PHI
_19 = (void *) ivtmp.8_6;
v_12 = MEM[(unsigned int *)_19];
if (v_12 == 0)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 477815112]:
_16 = v_12 == 1;
_17 = (unsigned int) _16;
_18 = _17 | LookupFlags_22;
[local count: 955630225]:
# LookupFlags_4 = PHI
*p_13(D) = LookupFlags_4;
ivtmp.8_5 = ivtmp.8_6 + 4;
if (ivtmp.8_5 != _28)
goto ; [89.00%]
else
goto ; [11.00%]
[local count: 118111600]:
return;
}
[Bug middle-end/110228] [13/14 Regression] llvm-16 miscompiled due to an maybe uninitialized variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110228 --- Comment #31 from Richard Biener --- (In reply to Zhendong Su from comment #30) > (In reply to Richard Biener from comment #29) > > I can't reproduce the original failure on trunk or with GCC 13.1, but the > > testcase from comment#16 is now fixed. I also cannot reproduce the testcase > > from comment#21 before the fix. > > > > Can people double-check this is now fixed, maybe also on the branch when > > this > > fix is cherry-picked? > > > > Thanks. > > I can still reproduce the test from comment#21 as well as PR 110491 and PR > 110509. PR110491 still reproduces after my fix (and PHI-OPT fixed the same way). The two other non-deterministic ones don't reproduce before/after (or I misunderstand how they work). > PR 110376 doesn't reproduce for me anymore. I'm going to add this as testcase. So I think there's more analysis necessary and I didn't fix the underlying issues in the other PRs.
[Bug middle-end/110228] [13/14 Regression] llvm-16 miscompiled due to an maybe uninitialized variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110228 --- Comment #30 from Zhendong Su --- (In reply to Richard Biener from comment #29) > I can't reproduce the original failure on trunk or with GCC 13.1, but the > testcase from comment#16 is now fixed. I also cannot reproduce the testcase > from comment#21 before the fix. > > Can people double-check this is now fixed, maybe also on the branch when this > fix is cherry-picked? > > Thanks. I can still reproduce the test from comment#21 as well as PR 110491 and PR 110509. PR 110376 doesn't reproduce for me anymore.
[Bug middle-end/110228] [13/14 Regression] llvm-16 miscompiled due to an maybe uninitialized variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110228 Richard Biener changed: What|Removed |Added Priority|P3 |P2 --- Comment #29 from Richard Biener --- I can't reproduce the original failure on trunk or with GCC 13.1, but the testcase from comment#16 is now fixed. I also cannot reproduce the testcase from comment#21 before the fix. Can people double-check this is now fixed, maybe also on the branch when this fix is cherry-picked? Thanks.
[Bug middle-end/110228] [13/14 Regression] llvm-16 miscompiled due to an maybe uninitialized variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110228 --- Comment #28 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:b083203f053f1666e9cc1ded2abdf4e1688d1ec0 commit r14-2289-gb083203f053f1666e9cc1ded2abdf4e1688d1ec0 Author: Richard Biener Date: Tue Jul 4 10:29:26 2023 +0200 tree-optimization/110228 - avoid undefs in ifcombine more thoroughly The following replaces the simplistic gimple_uses_undefined_value_p with the conservative mark_ssa_maybe_undefs approach as already used by LIM and IVOPTs. This is to avoid exposing an unconditional uninitialized read on a path from entry by if-combine. PR tree-optimization/110228 * tree-ssa-ifcombine.cc (pass_tree_ifcombine::execute): Mark SSA may-undefs. (bb_no_side_effects_p): Check stmt uses for undefs. * gcc.dg/torture/pr110228.c: New testcase. * gcc.dg/uninit-pr101912.c: Un-XFAIL.
[Bug middle-end/110228] [13/14 Regression] llvm-16 miscompiled due to an maybe uninitialized variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110228 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #27 from Richard Biener --- For the testcase in comment#16 we have ifcombine doing [local count: 477815112]: - if (v_12 == 1) -goto ; [34.00%] - else -goto ; [66.00%] - - [local count: 315357972]: - if (LookupFlags_5 != 0) -goto ; [50.00%] + _19 = v_12 == 1; + _20 = LookupFlags_5 | _19; + if (_20 != 0) +goto ; [67.00%] that at least accesses 'LookupFlags_5' without checking v_12 is either zero or one. This exposes an uninitialized read of LookupFlags_5 on the path from entry, even actually at runtime. PHI-OPT then makes tt value dependent on this uninitialized variable and I suspect things go downhill from there. Note it's not obvious at all that 'LookupFlags_5' may be uninitialized here, so ifcombine might need to use mark_ssa_maybe_undefs to try to conservatively catch those.
[Bug middle-end/110228] [13/14 Regression] llvm-16 miscompiled due to an maybe uninitialized variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110228
--- Comment #26 from Richard Biener ---
(In reply to Sergei Trofimovich from comment #24)
> Trying to understand the failure mode here:
>
> In bug.c.033t.early_objsz I still see the explicit stores to LocalFlags:
>
>:
> LookupFlags_15 = 0;
> goto ; [INV]
>
>:
> if (v_13 == 1)
> goto ; [INV]
> else
> goto ; [INV]
>
>:
> LookupFlags_14 = 1;
>
>:
> # LookupFlags_4 = PHI LookupFlags_14(6)>
> *p_16(D) = LookupFlags_4;
>
> But in bug.c.034t.ccp1 I see no stores at all:
>
> if (v_13 == 0)
> goto ; [INV]
> else
> goto ; [INV]
>
>:
> if (v_13 == 1)
> goto ; [INV]
> else
> goto ; [INV]
>
>:
>
>:
> # LookupFlags_4 = PHI <0(3), LookupFlags_5(4), 1(5)>
>
> Specifically '# LookupFlags_4 = PHI <0(3), LookupFlags_5(4), 1(5)>' claims
> that somehow gets values '0' and '1' into a PHI node.
>
> AFAIU PHI is an equivalent of a mutable variable in an otherwise immutable
> SSA form. It has to be a write it needed value is not there yet. Why the
> store of '1' was removed? Is it because variable 'v_13' already happens to
> have 0 or 1 value?
>
> I wonder why PHI does not look like something below:
>
> # LookupFlags_4 = PHI
LookupFlags is in SSA form thus we are dealing with registers and no "stores".
What happens is just constant propagation, LookupFlags_1{4,5} can be
replaced with their assigned constant.
[Bug middle-end/110228] [13/14 Regression] llvm-16 miscompiled due to an maybe uninitialized variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110228 --- Comment #25 from Sergei Trofimovich --- Specifically this bug.c.034t.ccp1's bit looks fishy: ... Folding statement: LookupFlags_14 = 1; Queued stmt for removal. Folds to: 1 Folding statement: LookupFlags_15 = 0; Queued stmt for removal. Folds to: 0 Folding PHI node: LookupFlags_4 = PHI <0(4), LookupFlags_5(5), 1(6)> No folding possible Folding statement: *p_16(D) = LookupFlags_4; Not folded Folding statement: i_18 = i_6 + 1; Not folded Removing dead stmt:i_8 = 0; Removing dead stmt:LookupFlags_14 = 1; Removing dead stmt:LookupFlags_15 = 0;
[Bug middle-end/110228] [13/14 Regression] llvm-16 miscompiled due to an maybe uninitialized variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110228 Sergei Trofimovich changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #24 from Sergei Trofimovich --- Trying to understand the failure mode here: In bug.c.033t.early_objsz I still see the explicit stores to LocalFlags: : LookupFlags_15 = 0; goto ; [INV] : if (v_13 == 1) goto ; [INV] else goto ; [INV] : LookupFlags_14 = 1; : # LookupFlags_4 = PHI *p_16(D) = LookupFlags_4; But in bug.c.034t.ccp1 I see no stores at all: if (v_13 == 0) goto ; [INV] else goto ; [INV] : if (v_13 == 1) goto ; [INV] else goto ; [INV] : : # LookupFlags_4 = PHI <0(3), LookupFlags_5(4), 1(5)> Specifically '# LookupFlags_4 = PHI <0(3), LookupFlags_5(4), 1(5)>' claims that somehow gets values '0' and '1' into a PHI node. AFAIU PHI is an equivalent of a mutable variable in an otherwise immutable SSA form. It has to be a write it needed value is not there yet. Why the store of '1' was removed? Is it because variable 'v_13' already happens to have 0 or 1 value? I wonder why PHI does not look like something below: # LookupFlags_4 = PHI
[Bug middle-end/110228] [13/14 Regression] llvm-16 miscompiled due to an maybe uninitialized variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110228 --- Comment #23 from Andrew Pinski --- (In reply to Andrew Pinski from comment #22) > (In reply to Zhendong Su from comment #21) > > Another very likely related reproducer. > Yes: >[local count: 82077551]: > a.0_1 = a; > _27 = a.0_1 == 0; > _5 = (int) _27; > _28 = _5 | i_14; > pretmp_45 = b; > ... >[local count: 200189151]: > # i_14 = PHI I wonder if ccp1 in this case could cause the 1 to proped out of the loop. and maybe we need some more isolation going on when it comes to using uninitialized variables ...
[Bug middle-end/110228] [13/14 Regression] llvm-16 miscompiled due to an maybe uninitialized variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110228 --- Comment #22 from Andrew Pinski --- (In reply to Zhendong Su from comment #21) > Another very likely related reproducer. Yes: [local count: 82077551]: a.0_1 = a; _27 = a.0_1 == 0; _5 = (int) _27; _28 = _5 | i_14; pretmp_45 = b; ... [local count: 200189151]: # i_14 = PHI
[Bug middle-end/110228] [13/14 Regression] llvm-16 miscompiled due to an maybe uninitialized variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110228
--- Comment #21 from Zhendong Su ---
Another very likely related reproducer.
[628] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/home/suz/suz-local/software/local/gcc-trunk/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror
--disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230701 (experimental) [master r14-924-gd709841ae0f] (GCC)
[629] %
[629] % gcctk -O3 small.c
[630] % for i in $(seq 1 10); do
> echo $i
> ./a.out
> done
1
Floating point exception
2
Floating point exception
3
Floating point exception
4
Floating point exception
5
Floating point exception
6
Floating point exception
7
Floating point exception
8
Floating point exception
9
10
[631] % cat small.c
int a, b, c, d, e, f = 1, g, h;
int main () {
int i;
for (; g < 1; g++) {
if (!a)
i = 1;
for (; b < 1; b++)
L:
;
}
int k = -1 / f;
while (d)
i = 0;
c = k;
e = ~i;
if (e > h) {
f = 0;
goto L;
}
return 0;
}
[Bug middle-end/110228] [13/14 Regression] llvm-16 miscompiled due to an maybe uninitialized variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110228 Andrew Pinski changed: What|Removed |Added CC||zhendong.su at inf dot ethz.ch --- Comment #20 from Andrew Pinski --- *** Bug 110509 has been marked as a duplicate of this bug. ***
[Bug middle-end/110228] [13/14 Regression] llvm-16 miscompiled due to an maybe uninitialized variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110228 --- Comment #19 from Andrew Pinski --- *** Bug 110491 has been marked as a duplicate of this bug. ***
[Bug middle-end/110228] [13/14 Regression] llvm-16 miscompiled due to an maybe uninitialized variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110228 --- Comment #18 from Andrew Pinski --- *** Bug 110376 has been marked as a duplicate of this bug. ***
