[Bug c/101793] New: Incorrect production of ‘may be used uninitialized in this function [-Werror=maybe-uninitialized]'

[Bug c/101793] New: Incorrect production of ‘may be used uninitialized in this function [-Werror=maybe-uninitialized]'

[thutt at vmware dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101793

            Bug ID: 101793
           Summary: Incorrect production of ‘may be used uninitialized in
                    this function [-Werror=maybe-uninitialized]'
           Product: gcc
           Version: 9.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: thutt at vmware dot com
  Target Milestone: ---

/*
  When compiled with the following options using the C compiler:

   -Werror                                      \
   -Wmaybe-uninitialized                        \
   -O1                                          \
   -fno-diagnostics-show-caret                  \

  this code produces the following diagnostic

    ./rk.c: In function ‘f’:
    ./rk.c:26:16: error: ‘saved’ may be used uninitialized in this function
[-Werror=maybe-uninitialized]
    cc1: all warnings being treated as errors

 This warning is erroneously produced, since 'state' is saved and
 restored under the same condition ('cond').

*/

unsigned fn(void);

extern unsigned state;

unsigned
f(unsigned p)
{
   unsigned  saved;
   unsigned  v0   = fn();
   unsigned  cond = p != 0;

   if (cond) {
      saved = state;

      if (v0 != 0) {
         p = 0;
      }
   }

   if (v0 > 0) {
      return 0;
   }

   if (fn()) {
      if (cond) {
         state = saved;
      }
      return p;
   }
   return 0;
}

[Bug c/101793] Incorrect production of ‘may be used uninitialized in this function [-Werror=maybe-uninitialized]'

[thutt at vmware dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101793

--- Comment #1 from thutt at vmware dot com ---
Also using godbolt.org, this sample fails from 4.9.0 to trunk.

[Bug tree-optimization/101793] Incorrect production of ‘may be used uninitialized in this function [-Werror=maybe-uninitialized]'

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101793

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2021-08-05
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
[WORKLIST]: add to initial list: saved_20 = PHI <saved_10(D)(15), saved_11(11)>
[CHECK]: examining phi: saved_20 = PHI <saved_10(D)(15), saved_11(11)>
[CHECK]: Found unguarded use: state = saved_20;

;;   basic block 7, loop depth 0, count 89223651 (estimated locally), maybe hot
;;    prev block 14, next block 16, flags: (NEW, VISITED)
;;    pred:       6 [34.8% (guessed)]  count:89223651 (estimated locally)
(TRUE_VALUE,EXECUTABLE)
  if (p_9(D) != 0)
    goto <bb 15>; [0.00%]
  else
    goto <bb 16>; [100.00%]
;;    succ:       15 [never (guessed)]  count:0 (estimated locally)
(TRUE_VALUE,EXECUTABLE)
;;                16 [always (guessed)]  count:89223651 (estimated locally)
(FALSE_VALUE,EXECUTABLE)

....

;;   basic block 15, loop depth 0, count 0 (estimated locally)
;;    prev block 16, next block 8, flags: (NEW)
;;    pred:       7 [never (guessed)]  count:0 (estimated locally)
(TRUE_VALUE,EXECUTABLE)
;;    succ:       8 [always]  count:0 (estimated locally) (FALLTHRU)

;;   basic block 8, loop depth 0, count 89223651 (estimated locally), maybe hot
;;    prev block 15, next block 9, flags: (NEW, VISITED)
;;    pred:       15 [always]  count:0 (estimated locally) (FALLTHRU)
;;                11 [always]  count:89223650 (estimated locally) (FALLTHRU)
  # p_15 = PHI <0(15), p_9(D)(11)>
  # saved_20 = PHI <saved_10(D)(15), saved_11(11)>
  state = saved_20;
;;    succ:       9 [always]  count:89223651 (estimated locally)
(FALLTHRU,EXECUTABLE)


I don't know enough about the uninit predicated code to understand why it can't
find that bb15 is predicated on p_9(D) != 0

[Bug tree-optimization/101793] Incorrect production of ‘may be used uninitialized in this function [-Werror=maybe-uninitialized]'

[thutt at vmware dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101793

--- Comment #3 from thutt at vmware dot com ---
Thanks for the quick triage.  If the optimizer is getting confused about
control / data flow, is it possible that it's making bad decisions for codegen?

[Bug tree-optimization/101793] Incorrect production of ‘may be used uninitialized in this function [-Werror=maybe-uninitialized]'

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101793

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to thutt from comment #3)
> Thanks for the quick triage.  If the optimizer is getting confused about
> control / data flow, is it possible that it's making bad decisions for
> codegen?

No, the cfg is cleaned up sometime after the uninitialized warning happens.

>From optimized:
Removing basic block 10
Removing basic block 11
Removing basic block 12
Removing basic block 13
Removing basic block 14
Removing basic block 15
Removing basic block 16
....
  <bb 7> [local count: 89223651]:
  if (p_9(D) != 0)
    goto <bb 8>; [0.00%]
  else
    goto <bb 9>; [100.00%]

  <bb 8> [local count: 89223651]:
  # p_15 = PHI <_8(7), p_9(D)(4)>
  # saved_20 = PHI <saved_10(D)(7), saved_11(4)>
  state = saved_20;

[Bug tree-optimization/101793] Incorrect production of ‘may be used uninitialized in this function [-Werror=maybe-uninitialized]'

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101793

Martin Sebor <msebor at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |msebor at gcc dot gnu.org

--- Comment #5 from Martin Sebor <msebor at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #2)
> I don't know enough about the uninit predicated code to understand why it
> can't find that bb15 is predicated on p_9(D) != 0

The pass sees that saved_10(D)(15) is uninitialized in bb 8 where the PHI with
it as an operand is used and it's missing logic to figure out that the
predicate guarding the uninitialized operand's definition is impossible to
satisfy (i.e., that bb 15 is unreachable).   The condition is p == 0 && v == 0
&& fn () != 0 && p != 0 but the pass doesn't even compute it.

[Bug tree-optimization/101793] Incorrect -Wmaybe-uninitialized on an unreachable use at -O1

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101793

Martin Sebor <msebor at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |msebor at gcc dot gnu.org

--- Comment #6 from Martin Sebor <msebor at gcc dot gnu.org> ---
Let me see if I can handle this.

[Bug tree-optimization/101793] Incorrect -Wmaybe-uninitialized on an unreachable use at -O1

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101793

Martin Sebor <msebor at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |NEW
           Assignee|msebor at gcc dot gnu.org          |unassigned at gcc dot gnu.org

--- Comment #7 from Martin Sebor <msebor at gcc dot gnu.org> ---
I'm not working on this anymore.

[Bug tree-optimization/101793] Incorrect -Wmaybe-uninitialized on an unreachable use at -O1

[law at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101793

Jeffrey A. Law <law at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |law at gcc dot gnu.org

--- Comment #8 from Jeffrey A. Law <law at gcc dot gnu.org> ---
I'm pretty sure this is a case where -O1 throttles jump threading.  Jump
threading is critical to avoiding the false positive warning in this testcase. 
 At -O2 the first full jump threading pass cleanings things up enough that the
false positive will ultimately be avoided.  In general, you'll find that -O2
will be much more precise for these kinds of warnings.

So, yes, this is a bug.  But it's not likely to get fixed anytime soon.