http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57974
--- Comment #17 from Marc Glisse <glisse at gcc dot gnu.org> --- (In reply to Henner Sudek from comment #14) > First i want to thank you all for the quick response and solving my problem. > I just want to point out that std::pow(std::complex<long double>(0,0),1.) > still returns nan. Maybe there is an way to unify the behavior of these > functions? One thing that may be missing is a middle-end optimization that detects that the second argument to cpow is a simple constant (we have that for the real pow). But that wouldn't help for a runtime value of 1. (In reply to Paolo Carlini from comment #16) > Also, in practice, I think it's *very* hard to explain to the users why long > double is so special, why the middle-end can't handle it in complete analogy > with float and double. And since clang and icc are *already* doing it, > apparently, you can't just tell them, vaguely, "it's very tough to > implement" or "performance would be horrible" or something similar. Did you benchmark both versions? That would help move the conversation... I really don't think we want to give users too high expectations about -ffast-math. When you use complex numbers and the pow function, you know that along the negative real axis be dragons. Expecting -ffast-math to give standard results there is wrong, even if you may be lucky sometimes. We do a number of other transformations with fast-math that can be very wrong. Like we could have rounded the first argument of pow to a very small negative number before the call ;-)
