Re: [PATCH v3] Change default to -fno-math-errno

[Wilco Dijkstra <Wilco dot Dijkstra at arm dot com>]

Joseph Myers wrote:
> On Mon, 8 Oct 2018, Richard Biener wrote:

>> So I think it would be fine if we'd have -fno-math-errno as documented
>> and then the C library would annotate their math functions according
>> to whether they will ever set errno or not.  Once a math function is
>> const or pure it cannot ever set errno so -fno-math-errno shouldn't have
>> any effect.
>
> Note that "will ever set errno" includes possibly setting it in the 
> future, since code may be built with one libm version and used with 
> another.  So it wouldn't be correct to have a "never sets errno" attribute 
> on glibc logb / lround / llround / lrint / llrint / fma / remquo (missing 
> errno setting is a known bug).  

Math functions don't require errno to be set if math_errhandling doesn't
specify MATH_ERRNO. So it's certainly feasible to guarantee errno
won't ever be set. It would even be feasible to decide per application
whether GLIBC sets errno or not.

My feeling is that errno from math functions has been dead for long enough
that removing support for it from libraries is very reasonable - and many
libraries have already done so. Have there been any reports of this breaking
large numbers of applications?

> It also wouldn't be correct to have it on 
> many complex.h functions, because while a requirement to set errno is 
> never part of their interface, they may call real functions which may set 
> errno (and may sometimes move from not setting it to setting it; e.g., 
> they call the internal exp, sincos etc. functions, which for 
> implementations using a wrapper do not set errno, but for implementations 
> without a wrapper have errno setting integrated; whether this results in 
> errno set by complex functions depends on details of exactly how they 
> handle overflow etc. cases).

Math functions (with or without a wrapper) can conditionally set errno if required.
You could save/restore errno in really complicated math functions, as is done for
rounding modes and exception flags.

For the new math functions all errno handling is already done in a single function
so you could do something like: if (want_errno) set_errno (error).

>> glibc has the ieee entry points but I'm not sure if it has any way
>> to use those by default.

Adding more entry points is a bad idea, the __finite entry points and slow
wrappers are bad enough as it is. The new optimized math functions use a
much more efficient and maintainable approach.

Wilco