[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

["rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #15 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #13)
> (In reply to Richard Biener from comment #11)
> > We can again work around this in libstdc++ by CSEing ->_M_size ourselves.
> > The following helps:
> > 
> > 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 = __v._M_size;
> > +      _M_size = __v_M_size;
> > +      _M_data = __valarray_get_storage<_Tp>(__v_M_size);
> > +      std::__valarray_copy_construct(__v._M_data, __v._M_data + __v_M_size,
> > +                                    _M_data);
> > +    }
> >  
> >  #if __cplusplus >= 201103L
> >    template<typename _Tp>
> 
> 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 constructed 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
> function. 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
> anything defined in namespace std, on pain of death.

The compiler doesn't know that the allocation function cannot clobber *this.
The C++ frontend tries to communicate this by making 'this' restrict qualified
and we make use of that info, but for calls we do not know how to use the
info.

Maybe we can special-case directly the actual parameter case and compute
the restrictness info for the call arguments.  The canonical example is

void bar (void);
struct X {
  X (int);
  int i;
  int j;
};

X::X(int k)
{
  i = k;
  bar ();
  j = i != k;
}

where if I understand you correctly, bar () is not allowed to modify *this
(unless I pass it an argument to it, of course), even if *this is for
example

char *storage;

void bar ()
{
  ((X *)storage)->i = 0; // the cast is invalid, no object of type X yet there?
}

int main()
{
  storage = new char[8];
  new (storage) X (1);
}