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

[glisse at gcc dot gnu.org]

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

--- Comment #6 from Marc Glisse  ---
GMP's expression templates, which are based on libstdc++ valarray, have the
same issue. I tried using values in GMP (
https://gmplib.org/list-archives/gmp-bugs/2014-January/003319.html ). I never
committed it for lack of time, but it seemed to improve performance as well,
not just safety. Somehow gcc/llvm had an easier time seeing through the
expressions with (copied) values. Not sure this applies to valarray though,
since the expressions have bounded depth there.

The real solution is still to avoid mixing auto with expression templates, at
least until we get some version of what was once proposed as "operator auto".
Maybe invent some [[warn_auto]] attribute?

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

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org

--- Comment #5 from Jonathan Wakely  ---
I have a patch.

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

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to Richard Biener from comment #1)
> Confirmed.  Works with GCC 5

Well, it doesn't segfault, but ASan still shows the problem:



ASAN:SIGSEGV
=
==8343==ERROR: AddressSanitizer: SEGV on unknown address 0x0018 (pc
0x004017e9 bp 0x7ffc01d53a90 sp 0x7ffc01d53a80 T0)
#0 0x4017e8 in std::valarray::operator[](unsigned long) const
/home/jwakely/gcc/5.5.0/include/c++/5.5.0/valarray:571
#1 0x401792 in std::_BinBase::operator[](unsigned long) const
/home/jwakely/gcc/5.5.0/include/c++/5.5.0/bits/valarray_before.h:534
#2 0x4016b5 in std::_BinBase, std::valarray
>::operator[](unsigned long) const
/home/jwakely/gcc/5.5.0/include/c++/5.5.0/bits/valarray_before.h:534
#3 0x4015ea in std::_Expr, int>, int>::operator[](unsigned long) const
/home/jwakely/gcc/5.5.0/include/c++/5.5.0/bits/valarray_after.h:216
#4 0x4013fd in void std::__valarray_copy_construct, int>
>(std::_Expr, int>,
int> const&, unsigned long, std::_Array)
/home/jwakely/gcc/5.5.0/include/c++/5.5.0/bits/valarray_array.tcc:219
#5 0x4011a9 in std::valarray::valarray, int> >(std::_Expr, int>, int> const&)
/home/jwakely/gcc/5.5.0/include/c++/5.5.0/valarray:696
#6 0x400d1c in main /tmp/val.cc:6
#7 0x7f025472a889 in __libc_start_main (/lib64/libc.so.6+0x20889)
#8 0x400ae9 in _start (/tmp/val5+0x400ae9)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV
/home/jwakely/gcc/5.5.0/include/c++/5.5.0/valarray:571
std::valarray::operator[](unsigned long) const
==8343==ABORTING


The root cause is that binary operators for valarray return expression
templates that have reference semantics, not value semantics. The result of
va+vb+vc refers to a temporary object that goes out of scope at the end of the
full expression. When that result is stored in a valarray it works OK:

  std::valarray sum = va + vb + vc;

but when you use 'auto' you get an object of the expression template type,
which holds a dangling reference to an expired temporary.

Solution: Don't use 'auto' with expression templates.

I'll see if there's anything the library can do to make this less error-prone.

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|7.4 |6.5

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|7.3 |7.4

--- Comment #3 from Richard Biener  ---
GCC 7.3 is being released, adjusting target milestone.

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

[bruno.manga95 at gmail dot com]

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

--- Comment #2 from Bruno Manganelli  ---
Just to clarify, it still segfaults when using clang++ with libstdc++.

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||5.4.0
   Keywords||wrong-code
   Last reconfirmed||2018-01-16
 Ever confirmed|0   |1
Summary|valarray replacement type   |[6/7/8 Regression] valarray
   |breaks with auto and more   |replacement type breaks
   |than one operation  |with auto and more than one
   ||operation
   Target Milestone|--- |7.3
  Known to fail||6.4.1, 7.2.1

--- Comment #1 from Richard Biener  ---
Confirmed.  Works with GCC 5, requires -O1+ to segfault.  Doesn't segfault when
using clang++.

#include 
int main()
{
  std::valarray va(16), vb(16), vc(16);
  auto sum = va + vb + vc;
  std::valarray vsum = sum;
}