Re: RFC: TS 18661-3 and related floating-point interfaces

[Joseph Myers <joseph at codesourcery dot com>]

On Wed, 18 Jan 2017, Szabolcs Nagy wrote:

> _noerrno functions would be useful

I think we need to judge that case-by-case, i.e. have evidence of it 
making a significant performance difference for a function it wouldn't 
make sense for the compiler to inline.  (Taking into account that directly 
setting errno in the main implementations in the cases where errors are 
detected may well be more efficient than the existing wrappers through 
avoiding extra branches, so a new symbol version that still sets errno but 
doesn't do matherr / _LIB_VERSION may be a useful alternative for some 
functions.)

E.g. there's no point in __sqrt_noerrno, compilers can inline sqrt (and if 
-fno-math-errno, will omit the code dealing with setting errno for 
negative arguments by calling the out-of-line sqrt in that case or 
otherwise).  And probably no point in __fma_noerrno when we fix bug 6801, 
the case where fma uses a hardware fma instruction is also a case where it 
can be inlined, which GCC has done (ignoring errno issues, in fact) for 
several years, while the generic code in the absence of such instructions 
is quite complicated and slow anyway.

(I added a predefined macro __NO_MATH_ERRNO__ in GCC 5 to allow glibc's 
headers to cause such functions to be used in cases where we do consider 
it useful.  For older GCC __FAST_MATH__ is all we could rely on for that.)

-- 
Joseph S. Myers
joseph@codesourcery.com