26_numerics/complex/13450.cc and IBM long double

[Joseph S. Myers]

On Tue, 14 Nov 2006, Paolo Carlini wrote:

> Joseph S. Myers wrote:
> 
> > The libstdc++ test 26_numerics/complex/13450.cc cannot work reliably for IBM
> > long double, since we define epsilon correctly for this type which means 100
> > * epsilon can be smaller than 1ulp for a particular long double value (and
> > so the test is only likely to pass if all three computed complex values are
> > actually identical).  Thus this patch disables the long double testing in
> > this testcase for the IBM long double case.
> > 
> If I understand correctly the issue, we could as well figure out a generic
> fix, care to propose one?

What do you mean by a generic fix?  This is not a generic bug; it's a bug 
specific to floating-point types that do not follow the standard C model 
because they can have discontiguous bits in the mantissa.  Testing in 
terms of epsilon is reasonable for results known to be near to a known 
constant - as long as the mantissa must be contiguous.  With IBM long 
double, the epsilon test is still reasonable for float and double - but a 
correct test for long double would be something completely different.  
Testing LDBL_MANT_DIG != 106 is the current method used in the testsuite 
to avoid problems with IBM long double (see 
gcc.dg/torture/fp-int-convert-timode.c).

-- 
Joseph S. Myers
joseph@codesourcery.com