From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id CDA3A396D80C; Thu, 7 Jan 2021 08:12:54 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org CDA3A396D80C From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/98499] [11 Regression] Possibly bad std::string initialization in constructors Date: Thu, 07 Jan 2021 08:12:54 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Version: 11.0 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 11.0 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: Thu, 07 Jan 2021 08:12:54 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D98499 --- Comment #7 from Richard Biener --- (In reply to Sergei Trofimovich from comment #6) > (In reply to Richard Biener from comment #5) > > Possibly in discovering pure/constness. See uses of > > gimple_call_return_slot_opt_p in tree-ssa-structalias.c >=20 > Aha, that's useful! >=20 > Trying to understand the problem better myself: `-fdump-tree-all` has > seemingly relevant `036t.ealias` that precedes breaking `037t.fre1`. >=20 > I assume `036t.ealias` analyses individual functions locally and does not > take into account other details, thus main() analysis should be enough: Well - it does take into account fnspecs derived by modref analysis for Importer::Importer - specifically ... > ``` > ... > Points-to sets >=20 > ANYTHING =3D { ANYTHING } > ESCAPED =3D { ESCAPED NONLOCAL } > NONLOCAL =3D { ESCAPED NONLOCAL } > STOREDANYTHING =3D { } > INTEGER =3D { ANYTHING } > _ZN8ImporterC1Ev =3D { } > imp.0+64 =3D { ESCAPED NONLOCAL } same as _6 > imp.64+8 =3D { ESCAPED NONLOCAL } > __builtin_trap =3D { } > main =3D { } > CALLUSED(9) =3D { ESCAPED NONLOCAL imp.0+64 imp.64+8 } same as callarg(11) > CALLCLOBBERED(10) =3D { ESCAPED NONLOCAL imp.0+64 imp.64+8 } same as > callarg(11) > callarg(11) =3D { ESCAPED NONLOCAL imp.0+64 imp.64+8 } the above shows we do not consider 'imp' to escape, and thus > _6 =3D { ESCAPED NONLOCAL } _6 does not point to 'imp'. Relevant parts of handle_rhs_call are probably /* As we compute ESCAPED context-insensitive we do not gain any precision with just EAF_NOCLOBBER but not EAF_NOESCAPE set. The argument would still get clobbered through the escape solution. */ if ((flags & EAF_NOCLOBBER) && (flags & (EAF_NOESCAPE | EAF_NODIRECTESCAPE))) { ... specifically lines if (!(flags & (EAF_NOESCAPE | EAF_DIRECT))) make_indirect_escape_constraint (tem); probably do not trigger because of the invalid modref analysis. I suggest to look at the early modref pass dump (it's after FRE but still applies to callers) >=20 > Alias information for int main() >=20 > Aliased symbols >=20 > imp, UID D.2146, struct Importer, is addressable >=20 > Call clobber information >=20 > ESCAPED, points-to non-local, points-to vars: { } >=20 > Flow-insensitive points-to information >=20 > _6, points-to non-local, points-to escaped, points-to NULL, points-to var= s: > { } >=20 > int main () > { > struct Importer imp; > char * _6; >=20 > : > Importer::Importer (&imp); > _6 =3D MEM[(struct string *)&imp]._M_buf; > if (&MEM[(struct string *)&imp]._M_local_buf !=3D _6) > goto ; [0.00%] > else > goto ; [100.00%] >=20 > [count: 0]: > __builtin_trap (); >=20 > : > imp =3D{v} {CLOBBER}; > imp =3D{v} {CLOBBER}; > return 0; > } > ``` >=20 > I think this looks correct. As I understand we care about a few things in > the analysis here: > 1. imp.0+64 and _6 both point to the same flow-insensitive classes (both = are > ESCAPED NONLOCAL) > 2. imp.0+64 and _6 both point to the same field in flow-sensitive analysis > (both do according to `imp.0+64 =3D { ESCAPED NONLOCAL } same as _6`. >=20 > I don't see problems here. >=20 > Mechanically looking at incorrect gcc's decision for `imp.0+64 !=3D _6`: >=20 > ptrs_compare_unequal( > ptr1 =3D &MEM[(struct string *)&imp]._M_local_buf, > ptr2 =3D _6 > ) >=20 > returns `TRUE` because >=20 > pt_solution_includes( > info =3D ptr2->pt, > obj1 =3D imp > ) >=20 > returns `FALSE`. That seems to be a bug. >=20 > Do arguments to `pt_solution_includes` look correct so far? Does it try to > answer "could _6 point at any field of 'imp' type"?=