[patch] libstdc++/69116 Constrain std::valarray functions and operators

[Jonathan Wakely]

The example in the PR is a sneaky little problem. When <valarray> is
included the following overload is declared:

template<typename _Tp>
_Expr</* here be expression templates */>
operator<<(const _Tp& __t, const valarray<_Tp>& __v);

This is a candidate function for any "a << b" expression with
namespace std as an associated namespace. In order to do overload
resolution valarray<decltype(a)> gets instantiated to see if there is
a conversion from decltype(b). When decltype(a) is an abstract type
valarray<decltype(a)> results in an error outside the immediate
context, and overload resolution stops with an error.

This could happen for any of the overloaded operators and functions
that work with valarray, so my solution is to adjust the __fun<> class
template so that the result type of valarray operations is not defined
for types that cannot be used in valarray.  When the result_type is
missing the valarray operators give a SFINAE deduction failure not a
hard error.

Currently the check is !__is_abstract(_Tp) but it could be tweaked to
also check other conditions that cause a problem.

The new test uses -std=gnu++98 because if it uses a later standard
then it fails due to similar unconstrained operators in <complex>, and
std::complex<T> also fails if is_abstract<T>, so I'll have to fix that
next.

Tested powerpc64-linux, comimtted to trunk.

This is a regression, caused by the front end starting to diagnose the
invalid library instantiations more eagerly. The fix seems simple and
safe, so I plan to backport it to the branches too.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch.txt
Type: text/x-patch
Size: 3125 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20160122/04428240/attachment.bin>