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

[Joseph Myers <joseph at codesourcery dot com>]

On Thu, 11 Oct 2018, Wilco Dijkstra wrote:

> Hi,
> 
> > 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).  
> 
> If these functions should set errno, there are many issues both in GCC and
> GLIBC. GCC treats fma and remquo always as const/pure, so inlines fma
> always even with -fmath-errno. GLIBC targets which support fma as a
> single instruction always inline it as a single instruction, as expected.
> 
> GCC incorrectly treats many other math functions as const/pure, for 
> example GCC "knows" that the C89 sin function will never set errno with
> -fmath-errno:

That (for sin) is bug 80042.  (While bug 37073 is enabling for FreeBSD the 
same optimizations as on Darwin and bug 64101 deals with a case where 
glibc's rules for errno setting on underflow do not require errno to be 
set, ISO C leaving that as implementation-defined, but some 
implementations, including the one used by the bug reporter, follow 
different rules that do involve setting errno.)

I suspect the current settings in GCC are based on someone's observations 
of what one particular implementation did around 2003; they aren't based 
on the standard.

> So if anything this is good evidence that nobody is using errno in actual
> applications, otherwise these bugs would have been found many years ago.

People *did* find such bugs, referenced above (but many uses likely would 
be such that the code movement in question does not occur and so the errno 
tests work anyway).

I think it would be reasonable to move to a -fno-math-errno default that 
actually matches the standard semantics (various functions may set errno 
but aren't required to, so replacing with single instructions is OK - 
without requiring a fix for the existing functions wrongly marked as never 
setting errno).  A stronger default (assume the functions never set errno) 
is appropriate on Darwin and FreeBSD (and potentially for some functions 
on some other platforms, if those platforms define no-errno-setting 
semantics for those functions rather than simply not setting errno by 
accident for them), and an explicit option could be used to enable such a 
stronger version on other platforms, and we could provide a way for libm 
implementations to declare that a function variant will never set errno.

-- 
Joseph S. Myers
joseph@codesourcery.com