On Sat, 4 Jan 2014, Alan Modra wrote: > On Thu, Jan 02, 2014 at 09:46:56PM +0000, Joseph S. Myers wrote: > > (Note that there remain other bugs in the IBM long double code, some > > causing glibc test failures, at least (a) invalid results in rounding > > modes other than FE_TONEAREST, (b) spurious overflow and underflow > > exceptions, mainly but not entirely where discontiguous mantissa bits > > are involved.) > > Thing is, the algorithms in rs6000/ibm-ldouble.c require round to > nearest to generate correct results. Quoting from the PowerPC64 ABI:
Which means that the functions need to set round-to-nearest internally (maybe only in __gcc_*_round versions used if -frounding-math - one possibility I suggested in bug 59666 discussing that issue). > * The software support is restricted to round-to-nearest mode. > Programs that use extended precision must ensure that this rounding > mode is in effect when extended-precision calculations are performed. This is not a valid statement for an ABI to make as it is contrary to the requirements of ISO C, as I note in bug 59666. When -frounding-math is used, arithmetic must work in all rounding modes (producing valid results, not necessarily correctly rounded for non-IEEE formats). > * Does not support the IEEE status flags for overflow, underflow, and > other conditions. These flag have no meaning in this format. The semantics of all except probably "inexact" are perfectly meaningful for this format. The glibc libm test results for IBM long double are unfortunately rather a mess (more so than for other floating-point formats) as various problems shown up by increased test coverage have languished unfixed for some time - I'm trying to fix some of the more obvious problems to get to a saner state of expected failures. -- Joseph S. Myers jos...@codesourcery.com
