This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: 11706 vs ([lno] Canonical iv creation)
- From: Paolo Carlini <pcarlini at suse dot de>
- To: Richard Guenther <rguenth at tat dot physik dot uni-tuebingen dot de>
- Cc: Roger Sayle <roger at eyesopen dot com>, gcc-patches at gcc dot gnu dot org,libstdc++ <libstdc++ at gcc dot gnu dot org>,Gabriel Dos Reis <gdr at integrable-solutions dot net>
- Date: Sat, 13 Mar 2004 21:23:48 +0100
- Subject: Re: 11706 vs ([lno] Canonical iv creation)
- References: <Pine.LNX.4.44.0403130458210.11330-100000@www.eyesopen.com> <40531B32.1090300@tat.physik.uni-tuebingen.de>
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!