[PATCH] PR libstdc++/88204 disable std::complex<long double> tests

[Iain Sandoe]

> On 9 Jan 2019, at 10:14, Jakub Jelinek <jakub@redhat.com> wrote:
> 
> On Wed, Jan 09, 2019 at 09:37:40AM +0000, Jonathan Wakely wrote:
>> The IBM128 long double format isn't foldable in constant expressions, so
>> conditionally skip the std::complex<long double> cases when they'll
>> fail.
>> 
>> 	PR libstdc++/88204
>> 	* testsuite/26_numerics/complex/operators/more_constexpr.cc: Do not
>> 	test std::complex<long double> if long double format is IBM128.
>> 	* testsuite/26_numerics/complex/requirements/more_constexpr.cc:
>> 	Likewise.
>> 
>> Tested powerpc64le-linux, committed to trunk.
> 
> Thanks for doing that.  Due to the variable number of bits in the mantissa
> unless we represent the double-double constants in the compiler as a pair of
> doubles there will be always many cases that can't be folded.  That said,
> I've been wondering if we couldn't fold at least the basic arithmetics on
> some constants, essentially by emulating what will happen at runtime.  I.e.
> if we want to constant fold PLUS_EXPR (or MINUS_EXPR, MULT_EXPR, *DIV_EXPR,
> and a few others) of two double-double REAL_CSTs, split them into two
> double values by rounding to a double, subtracting that double and rounding
> the remainder to double, perform whatever we emit inline or the runtime
> library does for the basic operations and in the end check if the result of
> that operation fits in the canonical format we pretend for the double-double
> (i.e. the 106 bits mantissa etc.) and if it does, allow constant folding
> that.  E.g. in Red Hat bugzilla I think we have several spots where people
> complain about this lack of folding, it breaks a couple of real-world apps
> etc.  Or is double-double considered dead format that will hopefully soon go
> away, not worth spending more time on?

It’s also 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19779
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26374

in the latter, Andrew Pinski suggests using MPFR, but there’s no patch.

(there might be others in our BZ)

Iain