[Bug c/60488] New: missing -Wmaybe-uninitialized on a conditional with goto

[Bug c/60488] New: missing -Wmaybe-uninitialized on a conditional with goto

[msebor at gmail dot com]

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

            Bug ID: 60488
           Summary: missing -Wmaybe-uninitialized on a conditional with
                    goto
           Product: gcc
           Version: 4.8.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: msebor at gmail dot com

The -Wmaybe-uninitialized option is documented like so: "For an automatic
variable, if there exists a path from the function entry to a use of the
variable that is initialized, but there exist some other paths for which the
variable is not initialized, the compiler emits a warning if it cannot prove
the uninitialized paths are not executed at run time."

In the program below, when f(&a) returns zero, the variable b is considered to
have been initialized by the call to f(&b) when it's used as the argument in
the first call to g(b). However, when f(&a) returns non-zero, the variable b is
used uninitialized in the second call to g(b). Therefore, there exists a path
through the function where b is used initialized as well as one where it's used
uninitialized. Thus, GCC should issue a warning. It, however, does not.

$ cat t.c && gcc -O2 -Wuninitialized -Wmaybe-uninitialized -c -o/dev/null t.c
int f (int**);
void g (int*);

int foo (void) {
    int *a, *b;

    if (f (&a) || f (&b))
        goto end;

    g (a);
    g (b);
    return 0;
end:
    g (b);
    return 1;
}

[Bug middle-end/60488] missing -Wmaybe-uninitialized on a conditional with goto

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

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

--- Comment #1 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
Sorry, this is too large to analyze. Maybe you can reduce it following the
ideas here: https://gcc.gnu.org/bugs/minimize.html
>From gcc-bugs-return-454953-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jun 25 19:44:10 2014
Return-Path: <gcc-bugs-return-454953-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 27482 invoked by alias); 25 Jun 2014 19:44:09 -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 27429 invoked by uid 48); 25 Jun 2014 19:44:05 -0000
From: "mpolacek at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/61534] Wlogical-op should not warn when either operand comes from macro expansion
Date: Wed, 25 Jun 2014 19:44: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.10.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: mpolacek 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:
Message-ID: <bug-61534-4-uQn5rtb0op@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61534-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61534-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-06/txt/msg02035.txt.bz2
Content-length: 410

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

--- Comment #4 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
BTW, clang doesn't warn even when neither operand comes from a macro expansion;
and clang version 3.4 doesn't know -Wlogical-op warning option (so I tried
-Wall -Wextra -Weverything, but still no warning).  Yes, I don't have mainline
clang, but I don't see that option in clang code base.

[Bug middle-end/60488] missing -Wmaybe-uninitialized on a conditional with goto

[manu at gcc dot gnu.org]

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

--- 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)
> Sorry, this is too large to analyze. Maybe you can reduce it following the
> ideas here: https://gcc.gnu.org/bugs/minimize.html

Wrong bug! Sorry.
>From gcc-bugs-return-454955-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jun 25 19:45:18 2014
Return-Path: <gcc-bugs-return-454955-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 29152 invoked by alias); 25 Jun 2014 19:45:14 -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 29098 invoked by uid 48); 25 Jun 2014 19:45:07 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/60239] False positive maybe-uninitialized in for loop
Date: Wed, 25 Jun 2014 19:45: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.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: manu at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
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-60239-4-iKVOZg7DvD@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60239-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60239-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-06/txt/msg02037.txt.bz2
Content-length: 544

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

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

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

--- Comment #1 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
Sorry, this is too large to analyze. Maybe you can reduce it following the
ideas here: https://gcc.gnu.org/bugs/minimize.html
>From gcc-bugs-return-454956-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jun 25 20:06:41 2014
Return-Path: <gcc-bugs-return-454956-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 13708 invoked by alias); 25 Jun 2014 20:06:41 -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 13653 invoked by uid 48); 25 Jun 2014 20:06:37 -0000
From: "pault at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/57019] [4.8/4.9/4.10 Regression] Compiler crashes (and make wrong assignments) at some combinations of pointers
Date: Wed, 25 Jun 2014 20:06:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 4.6.3
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: pault at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P4
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.8.4
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: assigned_to
Message-ID: <bug-57019-4-zhTxHR8WmW@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57019-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57019-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-06/txt/msg02038.txt.bz2
Content-length: 670

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

Paul Thomas <pault at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|pault at gcc dot gnu.org           |unassigned at gcc dot gnu.org

--- Comment #8 from Paul Thomas <pault at gcc dot gnu.org> ---
This will be fixed once the work on fortran-dev is finished and the branch is
merged into trunk.

Kludges night be possible but I do not think that the diversion of effort is
worth it.

Thanks for the report - the PR will remain but it will take a few months yet to
get it fixed.

Paul

[Bug middle-end/60488] missing uninitialized warning (address taken, VOP)

[msebor at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2016-08-23 00:00:00         |2021-3-26
      Known to fail|7.0                         |11.0

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

The problem is that when the address of a variable escapes, because GCC doesn't
track when, when the function from which it escapes calls another that might
access the escaped variable, the warning (as a result of relying on the
conservative assumptions the optimizers must make) assumes the called function
initializes the variable.  Another example of this is function h() below.

The irony (and I'd say the bug) here is that the warning uses the same
conservative assumptions to trigger in cases when an equivalent same situation
might lead to the variable not having been initialized such as in g() below. 
These conflicting assumptions make the warning seem unpredictable.

$ cat z.c && gcc -O2 -S -Wall z.c
void f (void);

int i, *p;

int g (int j)
{
  int x;
  if (i)           // assume i is zero
    x = j + 1;

  f ();            // assume call sets i

  if (i)
    return x;      // issue -Wmaybe-uninitalized

  return i;
}

int h (int j)
{
  int x;

  p = &x;          // address of x escapes

  f ();            // assume call sets x

  return x;        // avoid warning here
}

z.c: In function ‘g’:
z.c:14:12: warning: ‘x’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
   14 |     return x;      // issue -Wmaybe-uninitalized
      |            ^
z.c:7:7: note: ‘x’ was declared here
    7 |   int x;
      |       ^

[Bug middle-end/60488] missing uninitialized warning (address taken, VOP)

[manu at gcc dot gnu.org]

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

--- Comment #7 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Martin Sebor from comment #6)
> The problem is that when the address of a variable escapes, because GCC
> doesn't track when, when the function from which it escapes calls another
> that might access the escaped variable, the warning (as a result of relying
> on the conservative assumptions the optimizers must make) assumes the called
> function initializes the variable.  Another example of this is function h()
> below.

I don't think these are equivalent testcases. It is OK to assume that the
invisible function initializes the variable. The problem arises when there is a
path that never calls the function but GCC does not see that.

The key here is the logical operator splits the possible paths in two. In one
of the paths, b (comment #5) is never initialized, no matter what you assume
about f(). It also happens with a simple if():

int f (int*);
int g(void);
int foo (void)
{
  int b;
  if (g()) {
    f(&b);
  }
  return b;
}

However, a similar construct without &b works:

int g(void);
int foo (void)
{
  int b;
  if (g()) {
    b = g();
  }
  return b;
}

If you look at the VOPs, there is a chain that goes from the VUSE of b to the
VDEF<(D)> through at least one PHI node.

The "return 0" is problematic because CPP (PR18501) will trigger and mess up
things even more. But the above testcases avoid PR18501 and still show this
bug.

[Bug middle-end/60488] missing uninitialized warning (address taken, VOP)

[msebor at gcc dot gnu.org]

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

--- Comment #8 from Martin Sebor <msebor at gcc dot gnu.org> ---
You're right, the test cases aren't equivalent, or meant to be.  What I want to
highlight is that in the test case in comment #6, in g() and other similar ones
like it the warning is most likely going to be a false positive, while in h(),
not warning most likely a false negative.  Both of these "problems" are due to
the same underlying assumption: that a variable whose address escapes may be
modified by a subsequent call to an unknown function.

The upshot is that the warning (indeed, all flow-based warnings) should
consider not just what can be proven might happen based on the IL but also the
likelihood with which it might happen.  I'm not saying there's a coding bug in
the implementation of the warning, rather that the heuristics it implements
aren't sufficient to capture this distinction.

[Bug middle-end/60488] missing uninitialized warning (address taken, VOP)

[manu at gcc dot gnu.org]

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

--- Comment #9 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Martin Sebor from comment #8)
> You're right, the test cases aren't equivalent, or meant to be.  What I want
> to highlight is that in the test case in comment #6, in g() and other
> similar ones like it the warning is most likely going to be a false
> positive, while in h(), not warning most likely a false negative.  Both of
> these "problems" are due to the same underlying assumption: that a variable
> whose address escapes may be modified by a subsequent call to an unknown
> function.

Sure, but that assumption is not the problem in this PR, since assuming one
thing or the other only matters for distinguishing between "is" and "may be",
but a warning should have been given and it is not given.

[Bug middle-end/60488] missing uninitialized warning (address taken, VOP)

[msebor at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |matthew at wil dot cx

--- Comment #10 from Martin Sebor <msebor at gcc dot gnu.org> ---
*** Bug 88518 has been marked as a duplicate of this bug. ***