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
