This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: 11706 vs ([lno] Canonical iv creation)
Paolo Carlini <pcarlini@suse.de> writes:
| 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.
That is partly true. But, remember that std::pow() is required to
operator on things behond "C" pow() domain.
| Perhaps we are presenting the issue in the wrong way, however, talking
Definitely, in the wrong way.
| 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"!
That is right.
| 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); }
Yes. However, there is a subtle issue here. Contrary to C, C++
overloads pow() for (double, int). So, while in C pow(3.14, 4) would
call pow(double, double), in C++ it would call pow(double, int).
I'm under the impression that Richard seems to overlook that point.
A way to refine this is to use class template specilizations to
dispatch to appropriate built-ins. Despite Richard G. shouting, I
don't want to see ::pow() in std_cmath.h.
| Why "using ::pow" is there in the first place? (*)
A carry over from the days we did not have built-ins support and we
were just trumping everybody.
| Why not removing it, the version taking integer arguments (and
| __pow_helper), and adding the above instead?
You can remove call to ::pow(), but you cannot remove __pow_helper().
We have to support templated versions of pow().
-- Gaby