[Bug libstdc++/57997] Segmentation fault after returning valarray expression from an auto function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57997 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.0 --- Comment #11 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++/57997] Segmentation fault after returning valarray expression from an auto function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57997 --- Comment #10 from Jonathan Wakely --- Author: redi Date: Wed May 2 16:41:46 2018 New Revision: 259844 URL: https://gcc.gnu.org/viewcvs?rev=259844&root=gcc&view=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++/57997] Segmentation fault after returning valarray expression from an auto function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57997 --- Comment #9 from Marc Glisse --- I'd rather work on improving the warnings so we can tell the user how bad his code is, but in case, we had a similar request in GMP, a code that was inspired by libstdc++ valarray: https://gmplib.org/list-archives/gmp-bugs/2014-January/003315.html and the discussion may contain hints relevant to the valarray case.
[Bug libstdc++/57997] Segmentation fault after returning valarray expression from an auto function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57997 Jonathan Wakely changed: What|Removed |Added Severity|normal |enhancement --- Comment #8 from Jonathan Wakely --- I'm pretty sure our implementation conforms to the standard, expression templates don't mix well with auto/decltype, but libc++ does seem to make code like this work somehow so it is a reasonable enhancement request.
[Bug libstdc++/57997] Segmentation fault after returning valarray expression from an auto function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57997 --- Comment #7 from Paolo Carlini --- I think so, yes. Your help is welcome anyway, worst case, we'll apply the changes for the next release series instead of 4.9. In a few hours I will send you privately the questionnaire to request the official Copyright Assignment forms to FSF.
[Bug libstdc++/57997] Segmentation fault after returning valarray expression from an auto function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57997 --- Comment #6 from Roy Stogner --- Copyright assignment shouldn't be a problem. The one serious non-technical problem is going to be finding time to work on a patch. The only technical issue I've discovered so far is that making this robust with no efficiency penalty seems to be impossible without operator overloads that take rvalue references. libstdc++ policy is that C++11 features are fine to use if wrapped in #if __cplusplus >= 201103L and C++03 compatibility is maintained?
[Bug libstdc++/57997] Segmentation fault after returning valarray expression from an auto function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57997 --- Comment #4 from Roy Stogner --- I oversimplified the code here to try and make the failure as easy to reproduce as possible. The term here isn't con-fusion, it's "kernel fusion", which the original user code is trying to do with libstdc++ valarray expressions (and VexCL expressions, and Eigen expressions, etc; those cases work); this is essentially the opposite of assuming that expression templates match their input types. To keep equations in their own functions (for maintainability) while still doing parallel evaluation in a single loop (for efficiency), those functions need to return the expression templates which embody their equations. However, this does assume that expression template move constructors (or copy constructors if move constructors aren't defined) don't do a shallow copy of the representations of subexpression objects, and I can't see anything in C++2011 or C++2014 standards drafts *mandating* anything about those constructors. If my amateur standards-lawyering is correct, it would be fair for you to mark this as "wontfix" or whatever bugzilla term signifies "go_bug_standards_committee_instead". On the third hand, there's nothing in the current standard mandating that the implementation *not* be robust when doing kernel fusion with user functions, either. Storing subexpressions by value in _BinBase (specializing to store by reference when the subexpression is just a valarray) might be a sufficient fix.
[Bug libstdc++/57997] Segmentation fault after returning valarray expression from an auto function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57997 --- Comment #5 from Paolo Carlini --- In my opinion it would be great if you could concretely propose a patch. I'm sure that both Gaby and the other library maintainers, like me, would be fast at reviewing it. Of course, if large it would require a Copyright assignment, but maybe not.
[Bug libstdc++/57997] Segmentation fault after returning valarray expression from an auto function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57997 --- Comment #3 from Gabriel Dos Reis --- Also, there might be some interactions with move semantics; I don't know.
[Bug libstdc++/57997] Segmentation fault after returning valarray expression from an auto function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57997 --- Comment #2 from Gabriel Dos Reis --- (In reply to Paolo Carlini from comment #1) > Gaby, can you help me with this? I think this is typical confusion about what valarray expressions are. f1() has some complicated return type that has essentially reference semantics (as permitted by the standard) and it returns a "morally" reference to the locally constructed temporary. The simplest fix is in the user code: do not assume valarray expressions in general have valarray types.
[Bug libstdc++/57997] Segmentation fault after returning valarray expression from an auto function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57997 Paolo Carlini changed: What|Removed |Added CC||gdr at gcc dot gnu.org Severity|major |normal --- Comment #1 from Paolo Carlini --- Gaby, can you help me with this?
