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

[Joseph Myers <joseph at codesourcery dot com>]

On Tue, 17 Jan 2017, Zack Weinberg wrote:

> Yes, but math is different.  First, for math functions, the documented
> errno codes (EDOM, ERANGE) are fully redundant to the IEEE in-band
> error values (+/-Inf and NaN); there's never any reason to look at the
> errno code once you've noticed the in-band error.  (IEEE floating

Only if you know the function and its arguments are such that the only way 
those values (or 0 for underflow) can occur is such an error.

> experience it isn't _useful_ detail.)  Second, math functions are
> subject to more potential optimization (most importantly inlining and
> vectorization, but CSE, code motion, and constant folding may also be
> relevant) than anything else that can set errno, and needing to set
> errno interferes with all of those optimizations.  Third, because

Inlining and vectorization aren't going to happen with the functions in 
libm, only with special vector versions or functions the compiler knows 
how to inline (or that are defined inline in bits/mathinline.h, etc.).  
The libmvec functions for x86_64 only get used with -ffast-math anyway 
(and generically I expect people to use -ffast-math or similar for 
vectorization; vector instructions may well fail to handle IEEE special 
cases in other ways; at least ARM NEON is like that).  All the others can 
similarly be enabled with -fno-math-errno (possibly together with 
-fno-trapping-math) or combination options such as -ffast-math that enable 
those options.

> people don't think about the possibility of math functions clobbering
> errno, they can interfere with reliable error handling for other
> operations (I have actually tripped over a case where a complicated

That's generically an issue with the rule that a function can change errno 
when it succeeds (because some function it called internally failed).

> I'd actually like to see us bump all the libm symbol versions and make
> the default behavior of _all_ the math functions be to set _neither_
> errno nor IEEE exception flags (i.e. math_errhandling=0); requiring
> the use of -f options and/or FENV_ACCESS pragmas to turn either of
> them _on_.

I don't consider that sort of non-conforming mode an appropriate default.  
The default functions in libm are suitable for a wide range of uses with 
different requirements, while leaving open the possibility that we can 
provide alternative versions of functions, e.g. vector versions or 
__*_noerrno, where useful, and that compilers can inline functions such as 
sqrt or fma taking due account of the options passed for that compilation.  
(I've argued that such built-in functions should have variants such as 
__builtin_sqrt_noerrno for which the compiler knows it doesn't need to 
insert special code to check for error cases and call the out-of-line 
function or otherwise set errno in those cases, even if -fno-math-errno is 
not in use.)

-- 
Joseph S. Myers
joseph@codesourcery.com