[Bug c/48341] LDBL_EPSILON is wrong on IRIX 6.5

["joseph at codesourcery dot com" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48341

--- Comment #3 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2011-03-30 15:43:53 UTC ---
On Wed, 30 Mar 2011, ro at CeBiTec dot Uni-Bielefeld.DE wrote:

> --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> 2011-03-30 15:16:57 UTC ---
> > Why do you think this is bogus?  It's correct for IBM long double, where 
> > the mantissa bits can be discontiguous, and so the least value greater 
> > than 1 that is representable has such discontiguous bits.  See PR 19405 
> > and <http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00374.html>.
> 
> But why do both that exact testcase and the libstdc++ one fail with this
> LDFL_EPSILON value on IRIX, and disagree with both the one from the
> system headers, which is identical to the one found in the
> gcc.target/powerpc/rs6000-ldouble-2.c test?

Presumably the implementation of long double arithmetic being used on IRIX 
is less accurate in this case than the one being used on Power.

Perhaps it would make sense to look at using darwin-ldouble.c (with 
function names appropriately adjusted) in some way on IRIX, in place of 
the code in fp-bit.c.  Since IRIX is the only target using the IBM long 
double support in fp-bit.c, it would then be possible to simplify fp-bit.* 
by removing all the HALFFRACBITS code.

Alternatively, if the format on IRIX is actually defined differently so 
that the nonzero bits are always within a contiguous set of 106 bits - if 
that is what IRIX documentation and the IRIX system compiler / libraries 
always do - then the generic code could be taught about that difference 
and the code in fp-bit.c might be closer to being correct for that 
definition than darwin-ldouble.c