From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 9743F3858D39; Mon, 27 Feb 2023 14:38:25 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9743F3858D39 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1677508705; bh=r5RcsTHB++G5d7NFYcA3F9tf0MwoNR57rWiGVGpw/wU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Opa3p1EaPLnXA8tUdBv0H0oqIc/jT6LZfR7yAS6l1+VWi4VjJs/VzcB4zNzIiAPEl V+s4JSdmpv32x+hGHeCBqL82/eH6g9luHLeeivczrupN8mb6IjIYLB8Erqf0j58i6Z 0beN9vM4WSbG+2tEnNs8Ee3PyzrMq7l8oCSt/iYU= From: "redi at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/107561] [13 Regression] g++.dg/pr71488.C and [g++.dg/warn/Warray-bounds-16.C -m32] regression due to -Wstringop-overflow problem Date: Mon, 27 Feb 2023 14:38:25 +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: 13.0 X-Bugzilla-Keywords: diagnostic, missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: redi at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org X-Bugzilla-Target-Milestone: 13.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 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D107561 --- Comment #13 from Jonathan Wakely --- (In reply to Richard Biener from comment #11) > We can again work around this in libstdc++ by CSEing ->_M_size ourselves. > The following helps: >=20 > diff --git a/libstdc++-v3/include/std/valarray > b/libstdc++-v3/include/std/valarray > index 7a23c27a0ce..7383071f98d 100644 > --- a/libstdc++-v3/include/std/valarray > +++ b/libstdc++-v3/include/std/valarray > @@ -647,8 +647,13 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION > inline > valarray<_Tp>::valarray(const valarray<_Tp>& __v) > : _M_size(__v._M_size), > _M_data(__valarray_get_storage<_Tp>(__v._M_size)) > - { std::__valarray_copy_construct(__v._M_data, __v._M_data + _M_size, > - _M_data); } > + { > + auto __v_M_size =3D __v._M_size; > + _M_size =3D __v_M_size; > + _M_data =3D __valarray_get_storage<_Tp>(__v_M_size); > + std::__valarray_copy_construct(__v._M_data, __v._M_data + __v_M_si= ze, > + _M_data); > + } >=20=20 > #if __cplusplus >=3D 201103L > template Ugh, gross. This makes no sense to me. this->_M_size is already a local copy of __v._M_= size that cannot have escaped, because its enclosing object hasn't been construc= ted yet. Why do we need another "more local" copy of it? _M_size is a copy of __v._M_size, which is passed to the get_storage functi= on. The compiler thinks that the get_storage call might modify __v, but it can't modify this->_M_size. So then _M_size still has the same value when passed = to the copy_construct call. Since it would be undefined for users to modify this->_M_size or __v._M_size from operator new (because they cannot access an object under construction,= and cannot modify an object while it's in the process of being copied), I wish = we could say that a specific call to operator new does not modify anything reachable from the enclosing function's arguments, including `this`. Or maybe we just teach the compiler that operator new will not touch anythi= ng defined in namespace std, on pain of death.=