On Wed, 19 Aug 2015, Richard Biener wrote: > As an additional point for many math functions we have to support errno > which means, like, BUILT_IN_SQRT can be rewritten to SQRT_EXPR > only if -fno-math-errno is in effect. But then code has to handle
I'd say that for functions like that (which can be expanded inline only for -fno-math-errno) there should be no-errno built-in function variants that users can call even if -fmath-errno (if not expanded inline, they'd still result in a call to a libm function that might set errno). An example of a use for that is AArch64 sqrt intrinsics that need an architecture-specific built-in __builtin_aarch64_sqrtdf when __builtin_sqrt_noerrno would do just as well if it existed. As another example: various libm functions are marked in builtins.def as not setting errno, even though their proper semantics mean they might set errno; see bug 64101 for the example of erf. One such function is fma. But if you limit fma inline expansion (for calls to fma / __builtin_fma in the user's program; obviously this doesn't affect expansion via contraction of a * b + c) to allow for the possibility of errno setting, you definitely want a way for user programs to get back the efficient inline expansion if they don't need errno set; for example, glibc uses __builtin_fma in various cases if _FP_FAST_FMA, and does not need errno setting in those cases, so would want to use __builtin_fma_noerrno in the event of any such change. -- Joseph S. Myers jos...@codesourcery.com
