From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 898473858402; Mon, 11 Mar 2024 15:20:29 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 898473858402 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1710170429; bh=/Re9RioK4ALGZ7AC7hEi1T1mpxhm0U/2YtBk5dNxVQ4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=crvqMI/VS7uFrGjG3rPpNkGy8JR851quygo/3lQWZF3O6L+MAOAoEJmvpl8tcNVi7 2XUzU8XLvhGZ/nTmauWW8Se2j4jgmTAyPj7FtHkx1THANMWn+aIzwGPxDpNNpIStur tkgYNkgAzvsXQezbFPojwZDnHIFTXs9zDv0qF5OY= From: "amacleod at redhat dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/96564] [11/12/13/14 Regression] New maybe use of uninitialized variable warning since r11-959 Date: Mon, 11 Mar 2024 15:20:28 +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: 11.0 X-Bugzilla-Keywords: alias, diagnostic, missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: amacleod at redhat dot com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 11.5 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: 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 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D96564 --- Comment #15 from Andrew Macleod --- (In reply to Richard Biener from comment #13) > (In reply to Jeffrey A. Law from comment #12) > > So I think we could solve this with a bit of help from the alias oracle= . We > > have the routine ptrs_compare_unequal, but points-to-null is going to = get > > in the way. > >=20 > > I think VRP and DOM have enough information to rule out NULL for both > > objects in question. So if we could query the points-to information, > > ignoring NULL then we could likely solve this particular bug. > >=20 > > Essentially VRP or DOM would prove NULL isn't in the set of possible va= lues > > at the comparison point. Then we query the alias information ignoring = NULL. > > Voila we compute a static result for the comparison of the two pointers= and > > the problematical block becomes unreachable and the bogus warning goes = away. > >=20 > > Richi, any thoughts in viability of such an API? >=20 > We now treat pt.null conservatively and track non-null-ness derived from > range-info in it. That means when VRP/DOM can prove a pointer is always > not NULL they can do set_ptr_nonnull (p) on it. >=20 > This means the >=20 > /* ??? We'd like to handle ptr1 !=3D NULL and ptr1 !=3D ptr2 > but those require pt.null to be conservatively correct. */ >=20 > is no longer true and we could finally implement it, like with >=20 > diff --git a/gcc/tree-ssa-alias.cc b/gcc/tree-ssa-alias.cc > index e7c1c1aa624..5b6d9e0aa6a 100644 > --- a/gcc/tree-ssa-alias.cc > +++ b/gcc/tree-ssa-alias.cc > @@ -479,9 +479,25 @@ ptrs_compare_unequal (tree ptr1, tree ptr2) > } > return !pt_solution_includes (&pi->pt, obj1); > } > - > - /* ??? We'd like to handle ptr1 !=3D NULL and ptr1 !=3D ptr2 > - but those require pt.null to be conservatively correct. */ > + else if (TREE_CODE (ptr1) =3D=3D SSA_NAME) > + { > + struct ptr_info_def *pi1 =3D SSA_NAME_PTR_INFO (ptr1); > + if (!pi1 > + || pi1->pt.vars_contains_restrict > + || pi1->pt.vars_contains_interposable) > + return false; > + if (integer_zerop (ptr2) && !pi1->pt.null) > + return true; > + if (TREE_CODE (ptr2) =3D=3D SSA_NAME) > + { > + struct ptr_info_def *pi2 =3D SSA_NAME_PTR_INFO (ptr2); > + if (!pi2 > + || pi2->pt.vars_contains_restrict > + || pi2->pt.vars_contains_interposable) > + if (!pi1->pt.null || !pi2->pt.null) > + return !pt_solutions_intersect (&pi1->pt, &pi2->pt); > + } > + } >=20=20 > return false; > } >=20 >=20 > but the testcase shows the non-null-ness is only conditional which means > we'd have to use a range query above which necessarily falls back to > the global ranges given we don't have any context available here. The > old EVRP adjusted global ranges during the walk but this is no longer don= e. >=20 You mean it lied? because x_1 is not NULL until after _8 =3D *x_1(D); exec= utes.=20 It can still be NULL on that stmt can it not? Did it reset the global val= ue afterwards? Contextually ranger knows both are non-null at EVRP time: a.0_27 : [irange] int[0:D.xxxx] * [1, +INF] 2->3 (T) x_1(D) : [irange] int * [1, +INF] 2->3 (T) a.0_27 : [irange] int[0:D.xxxx] * [1, +INF] 2->4 (F) x_1(D) : [irange] int * [1, +INF] 2->4 (F) a.0_27 : [irange] int[0:D.xxxx] * [1, +INF] So we know x_1 is non-NULL after the de-reference for the rest of the block (and function). It also sets a.0_27 globally to be [1, +INF]. > Note it's enough that one pointer is nonnull, so for your idea the > API could be extended with a bool one_ptr_nonnull parameter. ranger currently sets a.0 globally to be non-null in EVRP.=