From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id B1F473857C4D; Wed, 19 Jan 2022 00:51:13 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B1F473857C4D From: "amacleod at redhat dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/104069] -Werror=use-after-free false positive on elfutils-0.186 Date: Wed, 19 Jan 2022 00:51:13 +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: 12.0 X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: normal X-Bugzilla-Who: amacleod at redhat dot com X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: msebor at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- 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 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2022 00:51:13 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D104069 --- Comment #11 from Andrew Macleod --- (In reply to Jakub Jelinek from comment #10) > It is not, because it emits a false positive on a fairly common code. > Anyway, if bb3 jumps to bb4, then bb3 should have in the ranger assertion > that in bb3 ret_17 is 0 (it is on the true branch of the ret_17 =3D=3D 0 = && > something test), > so for the PHI, while it is or, it is either 2->4 is the executable edge = and > then ret_7 =3D=3D 0 implies ret_17 =3D=3D 0, or 3->4 is the executable ed= ge and then > ret_17 =3D=3D 0 too because that was what was the assertion in bb 3. But > arguably it isn't a very common case for PHIs. So, either the ranger can > have special case for something like that, or the warning code can. I dont follow what you guys are looking at. so I looked in EVRP and i see: ret_17 =3D realloc (ptr_14(D), size_15(D)); _1 =3D ret_17 =3D=3D 0B; _2 =3D size_15(D) =3D=3D 0; _3 =3D _1 & _2; if (_3 !=3D 0) goto ; [INV] else goto ; [INV] 2->3 (T) ret_17 : void * [0B, 0B] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D BB 3 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _2 _Bool [1, 1] size_15(D) size_t [0, 0] : ret_19 =3D realloc (ptr_14(D), 1); =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D BB 4 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Imports: ret_7 Exports: ret_7 _2 _Bool VARYING size_15(D) long unsigned int VARYING : # ret_7 =3D PHI if (ret_7 =3D=3D 0B) goto ; [INV] So you are saying that ret_17 is 0 if we go 2->3, then 3->4 and set ret_7 to ret_19. And looking backwards, if ret_7 =3D=3D 0, then ret_7 is zero which implies = that ret_17 was zero on the path 2->4 if we came that way and therefore, if we take the branch 4->5, that ret_17 is 0 ? Thats not happening any time soon.=20 Theres way to much conditional context. Basic data flow says we track ret_= 17 as [0,0] on 2->3 and VARYING on 2->4 BB4 is also a merge point since 3->4, so the means, based on data flow, that ret_17 is now VARYING again. THe diamond has ended, contextual range information is gone. First, PHI arguments are not exports from a block, their aggregator the PHI def is... and there it ends. the computational complexities of generically doing arguments are exponential, esepcially since we know nothing about the edge taken. You need to see some of the crazy PHIs out there. What you are suggesting here is that because the PHI which uses ret_17 on o= ne path must be zero (or whatever range) , and it happens to be zero on the ot= her path, we must therefore know conclusively that it is also zero.=20=20 My guess is this would be fairly uncommon. Its possible down the road that we can use the gori unwinding to analyze ra= nges which end a PHI. Winding back from=20 if (ret_7 =3D=3D 0B) we get [0,0] =3D PHI that we can teach gori or some= other unit about PHIS (we do not understand them yet since GORI is purely a basic block concept) to make queries about ret_17 on each edge.. even 3->4 for = no apparent reason, except that we asked about ret_17. Union them all together and see what happens. I'll keep it in mind, but that is not a high priority. You can forget about it for this release tho :-) Besides, the information ranger is providing shouldn't be any different than what we got before... ranger doesn't know anything, neither did previous versions. This isnt a "= loss of information" or even a "too good of information" situation. Its basical= ly the same as before is it not?=