[Bug tree-optimization/56654] New: uninit warning behaves erratically

[Bug tree-optimization/56654] New: uninit warning behaves erratically

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56654

             Bug #: 56654
           Summary: uninit warning behaves erratically
    Classification: Unclassified
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: tree-optimization
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: rguenth@gcc.gnu.org
                CC: xinliangli@gmail.com


For c-c++-common/uninit-17.c we currently expect the uninit use at:

static void bar(int a, int *ptr)
{
  do
  {
    int b;   /* { dg-message "declared" } */
    if (b < 40) {
      ptr[0] = b;
    }
    b += 1; /* { dg-warning "may be used uninitialized" } */
    ptr++;
  }
  while (--a != 0);
}

where I would expect it at the if stmt.  Now, when I exchange the late
DOM and the late VRP passes I instead get the warning two lines earlier
(inside the guarded BB).  But there is no change in the IL:

> diff -u a/uninit-17.c.131t.uninit1 b/uninit-17.c.131t.uninit1 
--- a/uninit-17.c.131t.uninit1  2013-03-18 14:27:16.677116283 +0100
+++ b/uninit-17.c.131t.uninit1  2013-03-18 14:26:58.956922876 +0100
@@ -3,7 +3,13 @@

 [WORKLIST]: add to initial list: b_5 = PHI <b_13(D)(2), b_7(6)>
 [CHECK]: examining phi: b_5 = PHI <b_13(D)(2), b_7(6)>
-[CHECK]: Found unguarded use: b_7 = b_5 + 1;
+
+Use in stmt *ptr_6 = b_5;
+is guarded by :
+if (b_5 <= 39)
+
+[CHECK] Found def edge 1 in b_5 = PHI <b_13(D)(2), b_7(6)>
+[CHECK]: Found unguarded use: *ptr_6 = b_5;
 void foobar(int, int*) (int a, int * ptr)
 {
   int b;

the only difference is in the order of b_5 immediate uses.

That is, find_uninit_use should impose an ordering when walking over
immediate uses - for example visit the most dominating use first.

[Bug tree-optimization/56654] uninit warning behaves erratically

[manu at gcc dot gnu.org]

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

--- Comment #2 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Manuel López-Ibáñez from comment #1)
> But while this is not simple a "is used" because of "if (b < 40)"? That
> seems to be the major bug here.

Wow, I should not type in a hurry. What I meant to say is:

Given "if (b < 40)", why is this not warned as "is used uninit"?
>From gcc-bugs-return-461628-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Sep 11 22:14:33 2014
Return-Path: <gcc-bugs-return-461628-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 23176 invoked by alias); 11 Sep 2014 22:14:33 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 23129 invoked by uid 48); 11 Sep 2014 22:14:29 -0000
From: "pinskia at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/52954] Missing bounds check warning without optimization
Date: Thu, 11 Sep 2014 22:14:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.8.0
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: pinskia at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-52954-4-IYDq0O1nL0@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-52954-4@http.gcc.gnu.org/bugzilla/>
References: <bug-52954-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-09/txt/msg01462.txt.bz2
Content-length: 439

https://gcc.gnu.org/bugzilla/show_bug.cgi?idR954

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |leis at in dot tum.de

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 63233 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/56654] uninit warning behaves erratically (always executed block, "is" vs "may", order when walking uses)

[msebor at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |diagnostic
   Last reconfirmed|2014-09-12 00:00:00         |2021-3-26
      Known to fail|                            |10.2.0, 11.0, 4.9.3, 5.3.0,
                   |                            |6.2.0, 7.5.0, 8.3.0, 9.3.0
                 CC|                            |msebor at gcc dot gnu.org

--- Comment #4 from Martin Sebor <msebor at gcc dot gnu.org> ---
Reconfirming with GCC 11.

[Bug tree-optimization/56654] uninit warning behaves erratically (always executed block, "is" vs "may", order when walking uses)

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

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

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
We do now diagnose "is used uninitialized", the ordering issue remains and I
have a patch for that that sorts after RPO but doesn't sort within the block if
there is more than one candidate.

[Bug tree-optimization/56654] uninit warning behaves erratically (always executed block, "is" vs "may", order when walking uses)

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:

https://gcc.gnu.org/g:8a63343a744a8584a9dfcbc3817f66755baafe8a

commit r13-2261-g8a63343a744a8584a9dfcbc3817f66755baafe8a
Author: Richard Biener <rguenther@suse.de>
Date:   Mon Aug 29 16:16:44 2022 +0200

    tree-optimization/56654 - sort uninit candidates after RPO

    The following sorts the immediate uses of a possibly uninitialized
    SSA variable after their RPO order so we prefer warning for an
    earlier occuring use rather than issueing the diagnostic for the
    first uninitialized immediate use.

    The sorting will inevitably be imperfect but it also allows us to
    optimize the expensive predicate check for the case where there
    are multiple uses in the same basic-block which is a nice side-effect.

            PR tree-optimization/56654
            * tree-ssa-uninit.cc (cand_cmp): New.
            (find_uninit_use): First process all PHIs and collect candidate
            stmts, then sort those after RPO.
            (warn_uninitialized_phi): Pass on bb_to_rpo.
            (execute_late_warn_uninitialized): Compute and pass on
            reverse lookup of RPO number from basic block index.

[Bug tree-optimization/56654] uninit warning behaves erratically (always executed block, "is" vs "may", order when walking uses)

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed.