A g++ bug ... or not ?

[Xi Ruoyao]

On 2018-09-08 10:59 +0800, Xi Ruoyao wrote:
> On Fri, 7 Sep 2018 23:47:48 +0100, Jonathan Wakely wrote:
> 
> > Maybe. I think that might resolve
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78851 too
> 
> We both try to make C++11 and C++03 behavior consistent but Vadim intend
> to use __builtin_pow for both of them...  I believe he is wrong because
> Rob has shown that __builtin_pow is inprecise and evil.  And, C++11
> *defines* `double pow(double x, int y)` to behave *exactly* whatv
> `pow(x, (double)y)` does.
> 
> Like Marc, I can't reproduce Vadim's result and think Vadim's libm is
> buggy.
> 
> I'll try to make C++03 `pow(float, int)`, `pow(double, int)` and
> `pow(long double, int)` to call libm functions instead of builtin
> functions, then do a regression test.

It's difficult to do for `__builtin_powif` because casting `int` to
`float` will lose precision.

See also PR11706, PR48738, 32503, and 72099.  Someone demends even
more "optimization" while the others demends precision.  In my point
of view such "optimizations" should only be applied with
`-ffast-math`, unless we can prove they won't lose precision.
-- 
Xi Ruoyao <xry111@mengyan1223.wang>
School of Aerospace Science and Technology, Xidian University