This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug target/59666] IBM long double arithmetic results invalid in non-default rounding modes


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59666

--- Comment #4 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Tue, 1 Mar 2016, vincent-gcc at vinc17 dot net wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59666
> 
> --- Comment #2 from Vincent LefÃvre <vincent-gcc at vinc17 dot net> ---
> (In reply to Joseph S. Myers from comment #0)
> > I think the right approach for a fix will probably involve setting
> > round-to-nearest temporarily within the functions, then adjusting
> > overflowing and underflowing results based on the original rounding mode.
> 
> This would not be sufficient. Even without overflow/underflow, the rounding
> direction needs to be honored for the basic arithmetic operations.

For a non-IEEE type where the accuracy is specified as within 3ulp 
(depending on the operation in question), there is no definition of what 
honouring the rounding mode means.  Such types fall within 5.2.4.2.2#6, 
"The accuracy of the floating-point operations (+, -, *, /) ... is 
implementation-defined ... The implementation may state that the accuracy 
is unknown.".

Note the proposed TC for DR#441: "The value of FLT_ROUNDS applies to all 
IEC 60559 types supported by the implementation, but need not apply to 
non-IEC 60559 types.".

Temporary setting of round-to-nearest and adjusting results suffices for 
uses in glibc; I have a libgcc patch to that effect (not suitable for 
inclusion because it doesn't condition things on a non-default configure 
option), together with an in-progress set of glibc patches to fix most of 
the glibc bugs shown up by test-ldouble failures.  I think roughly four 
such glibc fixes plus libm-test-ulps regeneration should allow 
test-ldouble to pass with patched libgcc (with unpatched libgcc needing 
also some extension of the existing set of XFAILs for this bug, before a 
default glibc build can pass test-ldouble on powerpc by default).  
(Passing with patched libgcc without XFAILs enables the use of random test 
generation to find bugs in glibc libm.  Passing with unpatched libgcc with 
XFAILs enabled the use of this test to detect regressions.)

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]