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.
