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?
