Joseph Myers wrote:
> On Thu, 21 Jun 2018, Jeff Law wrote:
>
> > I think all this implies that the setting of -fno-math-errno by default
> > really depends on the math library in use since it's the library that
> > has to arrange for either errno to get set or for an exception to be raised.
>
> If the library does not set errno, clearly -fno-math-errno by default is
> appropriate (and is the default on Darwin).
Various librarys no longer set errno nowadays, for example BSD, MUSL, Bionic
etc. For GLIBC 3.0 I'd propose to drop setting of errno as well since very few
applications check errno after math functions that may set it (C89 support
could be added using wrappers that set errno if required).
> If the library does set errno, but the user doesn't care about the errno
> setting, -fno-math-errno is useful to that user; the question here is
> whether it's also an appropriate default to assume the user doesn't care
> about errno setting and so require them to pass -fmath-errno if they do.
> There are separate cases here for if the library does or does not set
> exceptions (the latter including most soft-float cases).
For C99 and higher an application could check math_errhandling and report
an error if the libary does not support the required error handling. However
error checks are feasible even if the floating point runtime does not to set
exceptions since the return value will be NaN or Inf (of course in the case
of non-IEEE754 FP all bets are off).
Note errno is not guaranteed to not be set even if there is no error, so you
need to check the return value first before checking errno.
> Then there are various built-in functions in GCC that use
> ATTR_MATHFN_FPROUNDING when they should use ATTR_MATHFN_FPROUNDING_ERRNO -
> because there are legitimate error cases for those functions for which
> errno setting is appropriate. sin, cos, tan (domain errors for infinite
> arguments) are obvious examples. (We have bug 64101 for erf, which is a
> case where the glibc model of when to set errno for underflow does *not*
> ever involve setting errno for this function, but some other
> implementations might have other models for when setting errno is
> appropriate.)
That looks incorrect indeed but that's mostly a problem with -fmath-errno as it
would result in GCC assuming the function is const/pure when in fact it isn't.
Does ATTR_MATHFN_FPROUNDING imply that errno is dead after the call?
Wilco
