From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 25FD6385773E; Thu, 11 May 2023 08:05:44 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 25FD6385773E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1683792344; bh=xsswE1WlgjJ7x/JGD4ltWGBj0vQ5SlXAK2GYvs2Vh/0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=e+bBc1pelbdk/wNG0oSHdWdw6UN/N4ExVp8CQC6FzmLxBxbeeamYKocLc2YyIlgBe a9HvyikHoC6libmGqeMBEtO9r76q1WR2DSj718CN/v4h9HsbMQ5/wGnSjolT2zLCAd 7n0m1Zn2xylhuI2gtPQAZqZx8/9BdAgHtSsAstf8= From: "aldyh at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/109791] -Wstringop-overflow warning with -O3 and _GLIBCXX_USE_CXX11_ABI=0 Date: Thu, 11 May 2023 08:05:41 +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: 12.1.1 X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: normal X-Bugzilla-Who: aldyh 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: 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=3D109791 --- Comment #3 from Aldy Hernandez --- (In reply to Richard Biener from comment #2) > Confirmed. This is a missed optimization, we fail to optimize the loop g= uard >=20 > [local count: 329643239]: > _4 =3D (unsigned long) &MEM [(void *)&str + 2B]; > _6 =3D (unsigned long) __i_14; > _50 =3D -_6; > _100 =3D _4 + 18446744073709551615; > _40 =3D _100 - _6; > _41 =3D _40 > 13; > if (_41 !=3D 0) Do we even get a non-zero range for _4? I'm assuming that even if we get t= hat, we can't see that &str+2B minus 1 is also nonzero? >=20 > with __i_14 being >=20 > [local count: 452186132]: > # __i_14 =3D PHI <&MEM [(void *)&str + 1B](10), &MEM > [(void *)&str + 2B](9)> >=20 > I'll note that the strlen pass runs before VRP (but after DOM), but I'll > also note that likely ranger isn't very good with these kind of > "symbolic" ranges? How would we handle this? Using two > relations, __i_14 >=3D &str + 1 && __i_14 <=3D &str + 2? Yeah, we don't do much with that. Although the pointer equivalency class should help in VRP's case. We do some simple pointer tracking and even call into gimple fold to simplify statements, but it's far from perfect and as y= ou say, strlen is running before VRP, so it wouldn't help in this case. >=20 > DOM has >=20 > Optimizing block #16 >=20 > 1>>> STMT 1 =3D &MEM [(void *)&str + 2B] ge_expr __i_14 > 1>>> STMT 1 =3D &MEM [(void *)&str + 2B] ne_expr __i_14 > 1>>> STMT 0 =3D &MEM [(void *)&str + 2B] eq_expr __i_14 > 1>>> STMT 1 =3D &MEM [(void *)&str + 2B] gt_expr __i_14 > 1>>> STMT 0 =3D &MEM [(void *)&str + 2B] le_expr __i_14 > Optimizing statement _4 =3D (unsigned long) &MEM [(void *)&str = + 2B]; > LKUP STMT _4 =3D nop_expr &MEM [(void *)&str + 2B] > 2>>> STMT _4 =3D nop_expr &MEM [(void *)&str + 2B] > Optimizing statement _6 =3D (unsigned long) __i_14; > LKUP STMT _6 =3D nop_expr __i_14 > 2>>> STMT _6 =3D nop_expr __i_14 > Optimizing statement _50 =3D -_6; > Registering value_relation (_6 pe64 __i_14) (bb16) at _6 =3D (unsigned l= ong) > __i_14; > LKUP STMT _50 =3D negate_expr _6 > 2>>> STMT _50 =3D negate_expr _6 > Optimizing statement _100 =3D _4 + 18446744073709551615; > LKUP STMT _100 =3D _4 plus_expr 18446744073709551615 > 2>>> STMT _100 =3D _4 plus_expr 18446744073709551615 > Optimizing statement _40 =3D _100 - _6; > Registering value_relation (_100 < _4) (bb16) at _100 =3D _4 + > 18446744073709551615; > LKUP STMT _40 =3D _100 minus_expr _6 > 2>>> STMT _40 =3D _100 minus_expr _6 > Optimizing statement _41 =3D _40 > 13; > LKUP STMT _41 =3D _40 gt_expr 13 > 2>>> STMT _41 =3D _40 gt_expr 13 > LKUP STMT _40 le_expr 14 > Optimizing statement if (_41 !=3D 0) >=20 > Visiting conditional with predicate: if (_41 !=3D 0) >=20 > With known ranges > _41: [irange] bool VARYING Ranger won't do anything, but can DOM's scoped tables do anything here? The hybrid threader in DOM first asks DOM's internal mechanism before asking ra= nger (which seems useless in this case): dom_jt_simplifier::simplify (gimple *stmt, gimple *within_stmt, basic_block bb, jt_state *state) { /* First see if the conditional is in the hash table. */ tree cached_lhs =3D m_avails->lookup_avail_expr (stmt, false, true); if (cached_lhs) return cached_lhs; /* Otherwise call the ranger if possible. */ if (state) return hybrid_jt_simplifier::simplify (stmt, within_stmt, bb, state); return NULL; } Our long term plan for pointers was providing a prange class and separating pointers from irange. This class would track zero/nonzero mostly, but it w= ould also do some pointer equivalence tracking, thus subsuming what we do with pointer_equiv_analyzer which is currently restricted to VRP and is an on-the-side hack. The prototype I had for it last release tracked the equivalence plus an off= set, so we should be able to do arithmetic on a prange of say [&str + X]. I had= to put it aside because the frange work took way longer than expected, plus le= gacy got in the way. Neither of this is an issue now, so we'll see.. but that's= the plan. I should dust off those patches :-/.=