https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59666
--- Comment #6 from joseph at codesourcery dot com <joseph at codesourcery dot com> --- On Fri, 4 Mar 2016, vincent-gcc at vinc17 dot net wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59666 > > --- Comment #5 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> --- > (In reply to jos...@codesourcery.com from comment #4) > > 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.". > > But directed rounding mode requirements are different from just accuracy > requirements. For instance, with rounding toward negative infinity, one must > have ROUND(x) ≤ x. This allows one to get guaranteed bounds and to do interval There are no such requirements in ISO C for non-IEEE types; you need to use IEEE types (such as float, double or __float128) for interval arithmetic. Effectively, for non-IEEE types, arithmetic can be considered to work like most libm functions (where also there are no such requirements on how the results relate to the rounding mode). The problems as far as I'm concerned with the IBM long double code in libgcc are where (even given options such as -frounding-math) it does worse than the default glibc conventions for most libm functions.
