On Mon, 29 Jun 2020, Richard Biener via Gcc-patches wrote: > I'm not sure if the actual choice of macro values for the fe* builtins > need glueing logic or if we want them to be determined statically > by the target configuration - see how we handle folding of > fpclassify. At least without -frounding-math fegetround could be > constant folded to FE_TONEAREST for which we'd need the > actual value of FE_TONEAREST.
In most cases, target architectures have fixed values for the exceptions, independent of the target OS, but on SPARC there is OS dependence, which the SPARC_LOW_FE_EXCEPT_VALUES macro deals with (for the interface between atomic compound assignment and libatomic's __atomic_feraiseexcept). I'd guess they tend to have fixed values for the rounding modes as well. If GCC had a built-in fegetround that was always expanded inline and always know the correct value for each rounding mode, that would allow fixing bug 30569 (making FLT_ROUNDS depend on the rounding mode at runtime - note that expanding the FLT_ROUNDS macro mustn't introduce a dependency on libm, hence the need to expand inline). That bug could also be fixed incrementally, target by target, if the target-independent code had some way to determine whether the target would expand the built-in fegetround inline and what the rounding mode values would be. (I've tended to suppose that defining a separate __builtin_flt_rounds would be the way to go for fixing bug 30569, but that could easily wrap __builtin_fegetround and return a constant value for targets that can't expand __builtin_fegetround inline.) -- Joseph S. Myers jos...@codesourcery.com
