Re: [PATCH v5] rtl: builtins: (not just) rs6000: Add builtins for fegetround, feclearexcept and feraiseexcept [PR94193]

[Joseph Myers <joseph@codesourcery.com>]

On Wed, 4 Nov 2020, Richard Biener wrote:

> AFAICS you do nothing to marshall with the actually used libc
> implementation which AFAIU can choose arbitrary values for
> the FE_* macros.  I'm not sure we require the compiler to be
> configured for one specific C library and for example require
> matching FE_* macro definitions for all uses of the built
> compiler.

The compiler is definitely expected to match a given C library.  This 
applies for <stdint.h> and other typedefs, for example (various of which 
are used for printf format checking).  It also applies to FE_* in some 
cases where relevant for __atomic_feraiseexcept for floating-point atomic 
compound assignment.

> Now, I wonder whether _GCC_ should provide the FE_* macros, thus
> move (parts of) fenv.h to GCC like we do for stdint.h?

I think that would be a bad idea.  fenv.h involves library functionality 
that can sometimes need to do things beyond simply modifying hardware 
registers.  Consider e.g. the TLS exception and rounding mode state for 
soft-float powerpc-linux-gnu.  Or the TLS decimal rounding mode in libdfp.  
Or how exception enabling can involve a prctl call on powerpc.  Getting 
libgcc involved in storing such TLS state seems problematic.  And whether 
an FE_* macro should be defined may depend on whether the library supports 
the underlying functionality (consider the case of FE_TONEARESTFROMZERO 
for RISC-V, where defining it should mean library code actually works in 
that rounding mode, not just that hardware supports it).

The natural way to handle the rule in C2x that "The strictly conforming 
programs that shall be accepted by a conforming freestanding 
implementation that defines __STDC_IEC_60559_BFP__ or 
__STDC_IEC_60559_DFP__ may also use features in the contents of the 
standard headers <fenv.h> and <math.h> and the numeric conversion 
functions (7.22.1) of the standard header <stdlib.h>." would be to say 
that GCC provides the compiler pieces of a freestanding implementation, 
not necessarily the whole freestanding implementation.  (Those macros 
would only be defined via implicit preinclusion of stdc-predef.h anyway.)

-- 
Joseph S. Myers
joseph@codesourcery.com