[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

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

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

--- Comment #13 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(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.