[Bug libstdc++/83860] valarray replacement type breaks with auto and more than one operation

2018-05-02 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83860

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
  Known to fail||8.1.0

--- Comment #10 from Jonathan Wakely  ---
The original testcase works on trunk, although it's still possible to create
dangling references from valarray expressions by using `auto` (especially in
functions returning `auto` or `decltype(auto)` which end up returning an
expression template referring to a local valarray on the function's stack).

[Bug libstdc++/83860] valarray replacement type breaks with auto and more than one operation

2018-05-02 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83860

--- Comment #9 from Jonathan Wakely  ---
Author: redi
Date: Wed May  2 16:41:46 2018
New Revision: 259844

URL: https://gcc.gnu.org/viewcvs?rev=259844=gcc=rev
Log:
PR libstdc++/83860 avoid dangling references in valarray closure types

Store nested closures by value not by reference, to prevent holding
invalid references to temporaries that have been destroyed. This
changes the layout of the closure types, so change their linkage names,
but moving them to a different namespace.

PR libstdc++/57997
PR libstdc++/83860
* include/bits/gslice_array.h (gslice_array): Define default
constructor as deleted, as per C++11 standard.
* include/bits/mask_array.h (mask_array): Likewise.
* include/bits/slice_array.h (slice_array): Likewise.
* include/bits/valarray_after.h (_GBase, _GClos, _IBase, _IClos): Move
to namespace __detail.
(_GBase::_M_expr, _IBase::_M_expr): Use _ValArrayRef for type of data
members.
* include/bits/valarray_before.h (_ValArrayRef): New helper for type
of data members in closure objects.
(_FunBase, _ValFunClos, _RefFunClos, _UnBase, _UnClos, _BinBase)
(_BinBase2, _BinBase1, _BinClos, _SBase, _SClos): Move to namespace
__detail.
(_FunBase::_M_expr, _UnBase::_M_expr, _BinBase::_M_expr1)
(_BinBase::_M_expr2, _BinBase2::_M_expr1, _BinBase1::_M_expr2)
(_SBase::_M_expr): Use _ValArrayRef for type of data members.
* include/std/valarray (_UnClos, _BinClos, _SClos, _GClos, _IClos)
(_ValFunClos, _RefFunClos): Move to namespace __detail and add
using-declarations to namespace std.
* testsuite/26_numerics/valarray/83860.cc: New.

Added:
trunk/libstdc++-v3/testsuite/26_numerics/valarray/83860.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/gslice_array.h
trunk/libstdc++-v3/include/bits/mask_array.h
trunk/libstdc++-v3/include/bits/slice_array.h
trunk/libstdc++-v3/include/bits/valarray_after.h
trunk/libstdc++-v3/include/bits/valarray_before.h
trunk/libstdc++-v3/include/std/valarray

[Bug libstdc++/83860] valarray replacement type breaks with auto and more than one operation

2018-04-06 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83860

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug libstdc++/83860] valarray replacement type breaks with auto and more than one operation

2018-04-06 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83860

--- Comment #8 from Jonathan Wakely  ---
N.B. compiling with -fstack-reuse=none will prevent the optimizer from reusing
the stack space immediately, so the dangling references can still be used to
access the temporaries after their lifetime ends.

[Bug libstdc++/83860] valarray replacement type breaks with auto and more than one operation

2018-04-06 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83860

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||patch
  Known to work|5.4.0   |
   Target Milestone|6.5 |---
Summary|[6/7/8 Regression] valarray |valarray replacement type
   |replacement type breaks |breaks with auto and more
   |with auto and more than one |than one operation
   |operation   |

--- Comment #7 from Jonathan Wakely  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00292.html

I'm unmarking this as a regression, since the stack-use-after-scope problem has
always been there.