This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: 11706 vs ([lno] Canonical iv creation)

Richard Guenther wrote:

But I am worried about having ::pow() and std::pow() produce different results for same arguments. So the question is, does the standard say anything about this? Also, as ::pow() with -ffast-math optimizes better than std::pow() for constant exponent, the question is again why we don't use ::pow() for std::pow() ... which would also be faster in compilation speed.

Well, Richard, I think that you have a point. I'm under the impression, I may be wrong indeed, that the whole __pow_helper machinery had a real reason to exist when a (well optimized) builtin pow wasn't available. Now we have it, able to deal in an optimal (but at the same time correct) way with constant integer arguments.

Perhaps we are presenting the issue in the wrong way, however, talking too much of "::pow" (remember that, strictly speaking, ::pow shouldn't be there when you include <cmath>! See libstdc++/6257 about this *nasty* issue) instead of the correct "__builtin_pow"!

And, probably (as Gaby pointed out in the audit trail), in std_cmath.h we shouldn't have "using ::pow" for double arguments but instead:

 inline double
 pow(double __x, double __y)
 { return __builtin_pow(__x, __y); }

Why "using ::pow" is there in the first place? (*)

Why not removing it, the version taking integer arguments (and __pow_helper), and adding the above instead?


(*) Same issue also for lots of other math functions! Now we have a /complete/ set of builtins!

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]