From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 75E733858D28; Mon, 25 Apr 2022 17:50:46 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 75E733858D28 From: "amacleod at redhat dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/105329] Bogus restrict warning when assigning 1-char string literal to std::string Date: Mon, 25 Apr 2022 17:50:46 +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.0 X-Bugzilla-Keywords: diagnostic, missed-optimization, needs-bisection X-Bugzilla-Severity: normal X-Bugzilla-Who: amacleod at redhat dot com 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 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: Mon, 25 Apr 2022 17:50:46 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D105329 --- Comment #5 from Andrew Macleod --- Before inlining, the general code see: if (_27 <=3D __s_53(D)) goto ; [INV] else goto ; [INV] _34 =3D _27 - __s_53(D); __nleft_64 =3D (const size_type) _34 THe branch now registers the relation that __s_53 < _27, and this allows us= to now determine that _34 and _nleft_64 is [1, 0x7FFFFFFF]=20 THen we inline this code, and by the time we get to the restrict code, we h= ave the following IL: [local count: 89889908]: if (_22 >=3D &MEM [(void *)"5" + 1B]) goto ; [50.00%] else goto ; [50.00%] <..> [local count: 44944954]: if (_22 <=3D "5") goto ; [50.00%] else goto ; [50.00%] <...> [local count: 22472477]: _48 =3D _22 - "5"; if (_48 =3D=3D 1) goto ; [34.00%] else goto ; [66.00%] [local count: 7640642]: MEM[(char_type &)_22] =3D 53; pretmp_64 =3D MEM[(const struct basic_string *)s_2(D)]._M_dataplus._M_p; goto ; __nleft_49 =3D (const size_type) _48; __builtin_memcpy (_22, "5", __nleft_49); _28 =3D 1 - __nleft_49; _29 =3D _22 + 1; _140 =3D _22 + __nleft_49; __builtin_memcpy (_140, _29, _28); Our problem seems rooted in the calculation of _28.=20 Ranger has figured out via feeding calculations based on the comparisons th= at nleft_49 cannot be 0 or 1 either, and therefore must be [2, 0x7FFFFFFF] But it means that=20 _28 =3D 1 - __nleft_49; becomes a calculated range of [9223372036854775810, +INF]=20=20 And that makes the warning code very unhappy when it is used as the number = of bytes in the second memcpy. Previously, we hadn't made some of these conclusions, so we were looking at VARYING, so the warning code presumably ignored it.=20 This code is actually dead, but its not being figured out. the pointer tracking does not recognize that if this branch is NOT taken: if (_22 >=3D &MEM [(void *)"5" + 1B]) then we follow the following sequence: [local count: 44944954]: if (_22 <=3D "5") goto ; [50.00%] else goto ; [50.00%] [local count: 22472477]: _42 =3D "5" - _22; _43 =3D (long unsigned int) _42; __poff_45 =3D _43 + 1; _46 =3D _22 + __poff_45; _47 =3D MEM[(const char_type &)_46]; MEM[(char_type &)_22] =3D _47; pretmp_83 =3D MEM[(const struct basic_string *)s_2(D)]._M_dataplus._M_p; goto ; [100.00%] [local count: 22472477]: _48 =3D _22 - "5"; if (_48 =3D=3D 1) I believe the very first if can never take the edge 11->13... and thus the = rest of that code should go. for the general case, The tracking of _22 needs to recognize that when we g= et to bb12 that the expression "5" - 22 and in bb13 _22 - "5" have very strict ranges. in fact, they are [0,0] in think case I think.=20=20 That is certainly beyond rangers current capabilities. I thought that the reference tracking used by the warning system tried to do that. Regardless, when we introduce prange (pointer ranges) next cycle perhaps there is somet= hing we can do to track the base an offsets based on the conditions.=