http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57974
Marc Glisse <glisse at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |glisse at gcc dot gnu.org
--- Comment #19 from Marc Glisse <glisse at gcc dot gnu.org> ---
Ah, I think I understand now. For the exp function, getting an infinite
argument violates the assumptions of fast-math, so anything goes (though of
course it would be good to have the right result if it wasn't slower). But the
user used the pow function, which even if it has a branch cut along the
negative axis remains close to 0 around 0. The C++ standard does define pow in
terms of exp and log, but I understand why it is surprising in this case.
Ok, forget I posted anything, I am not taking any side...
Ah, your reply arrived in the meantime:
(In reply to Paolo Carlini from comment #18)
> Couple of clarifications: this doesn't go through cpow at all, the second
> argument isn't complex;
Might have made sense to convert the second argument to a complex, call
__builtin_cpow and let the middle-end deal with it.
> this isn't -ffast-math,
-funsafe-math-optimizations is pretty close to -ffast-math...
> and in general in my
> experience whatever you throw at clang and icc (in fact, clang++ accepts the
> very same -f gcc accepts) like -Ofast, it never happens that exp(-inf)
> becomes nan (now I don't have the time to actually run benchmarks
If someone does, that would help.
> but since
> we are talking about compile-time constants I don't think we are beating
> them performance-wise on this);
Don't we handle constant propagation using libmpc? That looks like a bug to me,
we should indeed compute a constant in the middle-end.
> why long double is so special for exp(-inf),
It isn't long double that is special, it is float/double that get lucky ;-)
Though I admit that this surprising behavior is only ok if it comes with a
significant speed gain.
