11706 vs ([lno] Canonical iv creation)

[Paolo Carlini]

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?

Paolo.

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