From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 31D903858288; Tue, 29 Nov 2022 11:47:00 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 31D903858288 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1669722420; bh=Yhx/jXs/7FvIt5iK+lZ6xs+Wtfkzs2sTEVLWoZ609pA=; h=From:To:Subject:Date:In-Reply-To:References:From; b=ddydqS8x7uD14LVUdIWq8Y7E7ZuWmfyYGQcY24xSb+K7TzE2VMpFeyBjTR+Ge2WFo Ob+/y3G5hgMu1i2skjs2E3j1Wg/TYmkjvFWy+LCVsW+D+KGwXExGOUt65/Oewsa3/7 BRwcH8f6kAFPYqCXXxjYwv70e5EQON7lYIBCVJ9I= From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/107852] [12/13 Regression] Spurious warnings stringop-overflow and array-bounds copying data as bytes into vector Date: Tue, 29 Nov 2022 11:46:58 +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.2.0 X-Bugzilla-Keywords: diagnostic, missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth 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: 12.3 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status cf_reconfirmed_on everconfirmed keywords 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=3D107852 Richard Biener changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Last reconfirmed| |2022-11-29 Ever confirmed|0 |1 Keywords| |missed-optimization --- Comment #4 from Richard Biener --- The array bound diagnostic happens on __builtin_memcpy (_48, _137, _Num.12_51); where we have _89 =3D operator new (4); _48 =3D _89 + 4; so the destination has no space left, thus _Num.12_51 must be zero but the actual guard of the memcpy is: if (_Num_50 !=3D 0) goto ; [33.00%] else goto ; [67.00%] [local count: 72751929]: _Num.12_51 =3D (long unsigned int) _Num_50; __builtin_memcpy (_48, _137, _Num.12_51); so the value-range of that is known > 0. There's a missed optimization: [local count: 1073741824]: _5 =3D bytes.D.25336._M_impl.D.24643._M_start; _6 =3D bytes.D.25336._M_impl.D.24643._M_finish; pretmp_66 =3D bytes.D.25336._M_impl.D.24643._M_end_of_storage; if (_5 !=3D _6) goto ; [70.00%] else goto ; [30.00%] ... [local count: 329045359]: # _137 =3D PHI <_6(4), _5(3)> _89 =3D operator new (4); _43 =3D bytes.D.25336._M_impl.D.24643._M_start; _Num_44 =3D _137 - _43; if (_Num_44 !=3D 0) goto ; [33.00%] else goto ; [67.00%] here we could see that _137 is equal to _5 and thus _Num_44 is zero (not sure why _43 was not yet CSEd to _5 here, supposedly this is exposed too late for the last FRE?). Knowing this would make the memcpy unreachable. So there's some std::__throw_length_error unresolved still which clobbers 'bytes'. I have a patch to elide the PHI node but the issue with bytes.D.25336._M_impl.D.24643._M_start not CSEd remains, it's in this case possibly clobbered by operator new (4). There's the possible option to avoid re-loading from 'this' in the involved(?) std::vector implementation (vector.tcc around line 800 which is where eventually the operator new originates from). IIRC we removed an optimization that 'new' cannot clobber global memory because of correctness issues recently.=