[Cfp-interest 2707] Re: Floating point rounding modes

[Vincent Lefevre]

Replying to some points...

On 2023-02-26 21:35:33 -0800, Jim Thomas wrote:
> >  1. Implementations can't be counted on to implement it correctly. Without the FENV_ACCESS pragma, compilers perform optimizations that do not preserve rounding behavior. That fenv.h pragma is explicitly not required to be supported in C++, and hence C++ provides no guarantee that fesetround() behaves reasonably.
> > 
> Some compilers also perform optimizations that don’t honor other language semantics (e.g. they reassociate, replace division by multiplication, distribute * over +, skip conversions). There’s a general problem of aligning optimizations and strict floating-point semantics. 

With GCC, this is what happens when the -ffast-math option is enabled,
but it is disabled by default, even when asking for any level of
optimizations. But with Intel's compiler, it is automatically enabled
at some optimization levels. In any case, this is not allowed by the
C standard, and should never be allowed.

Note that C allows some transformations via contraction of floating
expressions when enabled (the default is implementation-defined),
but with the guarantee that this cannot increase the error at the
(sub-)expression level. At least, this is much more controllable by
the user, doesn't break *basic* error analysis, and may have some
benefits.

> > 2. In practice, it seems to be inconsistent, and somewhat unpredictable, what calls to standard math functions, and even more so, user-defined functions, do when invoked with non-standard rounding modes. (This is based on looking at some implementations. I didn't study this systematically) 
> 
> C (even with Annex F support for IEC 60559) does not require all standard math function to honor rounding directions. This reflects history and the state of the art. The correctly rounded math functions for which C reserves cr_ prefix names are required to honor rounding directions. Regarding user-defined functions, see 7.6 #4 (in e.g. C23 draft N3054).

While there should be no issues with the standard math functions,
except that the rounding direction may not be honored, this is much
worse with calls to non-standard library functions and plugins,
possibly yielding erratic behavior and vulnerabilities (this has
already been seen with the Mozilla JavaScript engine due to the
dynamic precision of the i387 architecture).

In the past, the standard math functions of the glibc had such an
issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=153022

> > 5. Compilers seem to commonly ignore rounding modes for compile-time evaluations, making it very hard for the programmer to predict what they are actually getting. (This is my reading anyway, though the current C standard seems to say otherwise?)
> 
> The intention in C (with Annex F) is that compile-time arithmetic is fully specified. Annex F supports IEC 60559. The general C specification for floating point gives great flexibility to the implementation, largely to avoid breaking existing (including non portable) code.

GCC also generates bad code when the rounding mode is changed
(not just for compile-time evaluations), due to optimizations:

  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
  https://gcc.gnu.org/wiki/FloatingPointMath

-- 
Vincent Lefèvre <vincent at vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)