[Bug libstdc++/99117] [9/10/11 Regression] cannot accumulate std::valarray

["rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99117

--- Comment #8 from rguenther at suse dot de <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=99117
> 
> --- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
> (In reply to Jakub Jelinek from comment #5)
> > int* p = sum._M_data;
> > int* e1 = sum._M_data;
> > 
> > If p and e1 aren't __restrict__ too, shouldn't that be fine?
> 
> p (called __p below) doesn't use __restrict__:
> 
>   template<typename _Tp, class _Dom>
>     void
>     __valarray_copy(const _Expr<_Dom, _Tp>& __e, size_t __n, _Array<_Tp> __a)
>     {
>       _Tp* __p (__a._M_data);
>       for (size_t __i = 0; __i < __n; ++__i, ++__p)
>         *__p = __e[__i];
>     }
> 
> Here __e is the expression template which has two const valarray<int>& members,
> so maybe more accurately it's:
> 
> 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 = sum._M_data;
> const valarray& e1 = sum;
> const valarray& e2 = rhs;
> for (size_t i = 0; i < sum._M_size; ++i, ++p)
>   *p = e1._M_data[i] + e2._M_data[i];
> 
> So e1._M_data is marked with __restrict__.

Note the dump shown,

  _124 = MEM[(int * *)_221 + 8B clique 11 base 0];
  _115 = MEM[(const int &)_101 clique 11 base 0];
  _162 = MEM[(const int &)_124 clique 11 base 0];
  _140 = _115 + _162;
  MEM[(int *)_101 clique 11 base 1] = _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).