Hi Jeff,
> So I went back and reviewed all the discussion around this. I'm still
> having trouble getting comfortable with flipping the default -- unless
> we know ahead of time that the target runtime doesn't set errno on any
> of the math routines. That implies a target hook to describe the
> runtime's handling off errno in math functions. It also introduces
> target dependencies early in the GIMPLE pipeline which is generally
> counter to design goals around GIMPLE.
The goal of my patch was to inline single-instruction functions, so for
these cases you can be 100% sure errno will never be set. No target
hooks are required for this, and it works exactly as documented.
It turns out -fmath-errno is already quite broken since GCC treats
many math functions as never setting errno when in fact GLIBC does
set errno in almost all math functions.
> Essentially if we flip the default, we run the risk that user code which
> does check this stuff will silently break. That's not a good position
> to take IMHO.
-fmath-errno is already broken today for many math functions. That's a
much more serious issue than setting errno when we don't care about
errno anyway.
> That led me to wonder if we could prove that for the majority of FP
> intensive codes that even if the library set errno that nobody could
> possibly be reading it, then we could in large part treat those builtin
> calls as -fno-math-errno (we'd mark them somehow and check the mark at
> GIMPLE->RTL expansion time (and possibly other points) to allow us to
> generate machine instructions rather than library calls). That would
> get most of the benefit without the possibility to breaking user code.
I don't believe any of this is worth the effort. Errno for math functions has
been dead for several decades. A user who really cares about errno can find
the correct option, like one needs for similar rare cases (eg. -frounding-math
which is not the default).
Wilco
