Re: A g++ bug ... or not ?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxxx>
School of Aerospace Science and Technology, Xidian University




[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux