11706 vs ([lno] Canonical iv creation)

[Richard Guenther]

Paolo Carlini wrote:
> Gabriel Dos Reis wrote:
> 
>> | 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.
>>  
>>
> Excellent Gaby! Thanks for your puntualization about the "special" C++
> overaload for (double, int), I had *completely* overlooked it.
> 
> So, let's start with the basic clean-up (patch in testing), then let's 
> try to
> figure out together the template specialization you are mentioning above.

I didn't overlook the pow(, int) overloads, but instead "fixed" only 
pow(float, int), pow(double, int) and pow(long double, int), not 
touching the templated implementation (which wouldn't be supported by 
__builtin_pow() anyway).  Also talking about ::pow() is my lazyness 
only, of course we'd use __builtin_pow() here.  Wether we need 
__builtin_powi() I don't know - the existing __builtin_pow() seems to 
recognize integer exponents already.

This "fix" would also work for 3.4, while touching 3.3 is probably out 
of the question anyway - the only working "fix" for me is to use 
__builtin_constant_p() and __attribute__((always_inline)) here.

Richard.