[Bug middle-end/63224] false positive for -Wmaybe-uninitialized at -Os (not -O2) with && transformed to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63224 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #11 from Jeffrey A. Law --- Because of the -Os & size of duplicated block heuristic issue, this is ultimately a duplicate of 36550. Fix jump threading to recognize when the duplicate block will ultimately be eliminated as dead code and both bugs get fixed. *** This bug has been marked as a duplicate of bug 36550 ***
[Bug middle-end/63224] false positive for -Wmaybe-uninitialized at -Os (not -O2) with && transformed to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63224 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #10 from Jeffrey A. Law --- Note that Os throttles jump threading as jump threading often increases codesize. That's why you get this warning at -Os, but not at -O2.Jump threading does not have a good way to estimate how much of the duplicated block will be eliminated as dead code. In the reduced testcase, the contents of the duplicated block would be entirely eliminated as dead code making threading jumps 100% free from a codesize standpoint. That's where I think the focus is better spent (rather than adding additional cases to tree-ssa-uninit.c). Improve the jump threading heuristics -- the net result will be better code *and* the warning goes away as a side effect.
[Bug middle-end/63224] false positive for -Wmaybe-uninitialized at -Os (not -O2) with transformed to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63224 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-09-12 Component|c |middle-end Blocks||24639 Summary|False Positive for |false positive for |-Wmaybe-uninitialized at|-Wmaybe-uninitialized at |-Os, not -O2|-Os (not -O2) with ||transformed to Ever confirmed|0 |1 --- Comment #9 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Manuel López-Ibáñez from comment #6) I think this is PR56574, but we need to check the dumps to be sure. The dump should be something like: test.c.NNNt.uninit1, you can get it with -fdump-tree-all-all-lineno. According to this: + [Os.c : 8:8] # RANGE [0, 1] + _12 = s_4(D) == 2; + [Os.c : 8:18] # RANGE [0, 1] + _13 = c_1 == 0; + [Os.c : 8:13] # RANGE [0, 1] + _14 = _13 _12; the same bug is involved, but this one is a bit more complicated because it is not clear that the uninit pass realizes that the c_5(D)(7) edge is guarded by s==0, so in that case _12==0 and c_1 doesn't matter.
