From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
 id DC3EE385801A; Sat, 27 Mar 2021 08:57:03 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DC3EE385801A
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/60488] missing uninitialized warning (address taken, 
 VOP)
Date: Sat, 27 Mar 2021 08:57:03 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 4.8.2
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: manu at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
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-60488-4-ygCh5jdU25@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60488-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60488-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-BeenThere: gcc-bugs@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-bugs mailing list <gcc-bugs.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Sat, 27 Mar 2021 08:57:04 -0000

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

--- Comment #7 from Manuel L=C3=B3pez-Ib=C3=A1=C3=B1ez <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 relyi=
ng
> on the conservative assumptions the optimizers must make) assumes the cal=
led
> 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 o=
ne
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 =3D g();
  }
  return b;
}

If you look at the VOPs, there is a chain that goes from the VUSE of b to t=
he
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.=