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?

Reply via email to