https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59666
--- Comment #1 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> --- (In reply to Joseph S. Myers from comment #0) > The IBM long double functions in ibm-ldouble.c, when called in rounding > modes other than round-to-nearest, can produce results that are invalid [...] It seems to be like that "by design" (though this is not satisfactory) and part of the ppc64 ABI for instance: http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi.html#PREC "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." > ISO C does not allow for arithmetic operations simply not working - > producing invalid results - for some types and rounding modes, although for > non-IEEE types they need not be correctly rounding. I suppose that this is the case only when the FENV_ACCESS pragma is ON. ISO C99 §7.6.1 says (and ditto for C11): "If part of a program tests floating-point status flags, sets floating-point control modes, or runs under non-default mode settings, but was translated with the state for the FENV_ACCESS pragma ‘‘off’’, the behavior is undefined." The important point is "runs under non-default mode settings". So, I suppose that any performance impact would be limited to programs that are translated with the FENV_ACCESS pragma set to ON. However this would still be an issue for libraries or users of these libraries, depending on what convention is chosen.
