https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80119
Richard Biener <rguenth at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P3 |P2 Status|UNCONFIRMED |NEW Keywords| |diagnostic, | |missed-optimization Last reconfirmed| |2017-03-21 CC| |rguenth at gcc dot gnu.org Ever confirmed|0 |1 Summary|-Wmaybe-uninitialized |[6/7 Regression] |wrongly flags the body of a |-Wmaybe-uninitialized |short-circuited if-clause |wrongly flags the body of a | |short-circuited if-clause Target Milestone|--- |6.4 --- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> --- So when not optimizing we run the early uninit pass so that it also warns about maybe-uninit cases. The IL this pass sees is <bb 2> [0.00%]: retval.0_1 = 0; if (retval.0_1 != 0) goto <bb 3>; [0.00%] else goto <bb 4>; [0.00%] <bb 3> [0.00%]: i_3 = i_2(D) + 1; <bb 4> [0.00%]: return; which means to it there is an uninitialized use of 'i' in bb3. The FE produces if (<<cleanup_point 0>>) { <<cleanup_point <<< Unknown tree: expr_stmt (void) ++i >>>>>; } which we gimplify to retval.0 = 0; if (retval.0 != 0) goto <D.5469>; else goto <D.5470>; note that GCC 6.1 behaves the same way for me but GCC 5 does not warn as for it the FE produces if (0) { <<cleanup_point <<< Unknown tree: expr_stmt (void) ++i >>>>>; while it's possible to fix this in gimplification (elide the cleanup_point) eventually the FE can avoid building it in the first place?