From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id D5FBE384A87C; Tue, 16 Feb 2021 11:54:53 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D5FBE384A87C From: "rguenther at suse dot de" To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/99117] [9/10/11 Regression] cannot accumulate std::valarray Date: Tue, 16 Feb 2021 11:54:53 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libstdc++ X-Bugzilla-Version: 10.1.0 X-Bugzilla-Keywords: needs-reduction, wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenther at suse dot de X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 9.4 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: Tue, 16 Feb 2021 11:54:53 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D99117 --- Comment #8 from rguenther at suse dot de --- On Tue, 16 Feb 2021, redi at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D99117 >=20 > --- Comment #7 from Jonathan Wakely --- > (In reply to Jakub Jelinek from comment #5) > > int* p =3D sum._M_data; > > int* e1 =3D sum._M_data; > >=20 > > If p and e1 aren't __restrict__ too, shouldn't that be fine? >=20 > p (called __p below) doesn't use __restrict__: >=20 > template > void > __valarray_copy(const _Expr<_Dom, _Tp>& __e, size_t __n, _Array<_Tp> = __a) > { > _Tp* __p (__a._M_data); > for (size_t __i =3D 0; __i < __n; ++__i, ++__p) > *__p =3D __e[__i]; > } >=20 > Here __e is the expression template which has two const valarray& me= mbers, > so maybe more accurately it's: >=20 > struct valarray { > int* __restrict__ _M_data; > size_t _M_size; > }; > valarray sum{ new int[2]{1,1}, 2 }; > valarray rhs{ new int[2]{2,2}, 2 }; > int* p =3D sum._M_data; > const valarray& e1 =3D sum; > const valarray& e2 =3D rhs; > for (size_t i =3D 0; i < sum._M_size; ++i, ++p) > *p =3D e1._M_data[i] + e2._M_data[i]; >=20 > So e1._M_data is marked with __restrict__. Note the dump shown, _124 =3D MEM[(int * *)_221 + 8B clique 11 base 0]; _115 =3D MEM[(const int &)_101 clique 11 base 0]; _162 =3D MEM[(const int &)_124 clique 11 base 0]; _140 =3D _115 + _162; MEM[(int *)_101 clique 11 base 1] =3D _140; proves that the destination pointer was __restrict (it got base 1) and the sources were not (well, PTA conservatively didn't honor restrict even if it were present). But they are still disambiguated against the store since an access through a __restrict qualified pointer is disambiguated against everything else. One could say we maybe should honor the appearant must-alias here (*_101 and *_101 definitely alias), similar to how we'd done that in case the accesses are to the same decl through TBAA incompatible types. As QOI measure. But that still means the testcase or the valarray code has a bug somewhere (and will trigger in case the must-alias isn't as obvious as in the above case).=