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

[Joseph Myers <joseph at codesourcery dot com>]

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).  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).

(Also, directly setting const/pure on most libm functions runs into issues 
of what exactly that means regarding floating-point exceptions and 
rounding modes - and the need to avoid libm specifying a stricter 
attribute than the built-in function if that results in diagnostics from 
GCC.  glibc specifies const on a few functions that don't raise exceptions 
or depend on the rounding mode, and even some of those are questionable if 
raising "invalid" for signaling NaNs is an issue.)

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

__ieee754_* have never been exported from shared libm.

The old -lieee mechanism, no longer supported, involved libm function 
wrappers reading a writable global variable _LIB_VERSION to determine how 
to handle errors; depending on writable global data like that was itself 
obviously problematic.

-- 
Joseph S. Myers
joseph@codesourcery.com