This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: A g++ bug ... or not ?
On 2018-09-08 11:58 +1000, Rob <sisyphus1@optusnet.com.au> wrote:
> -----Original Message-----
> From: Xi Ruoyao
> Sent: Saturday, September 08, 2018 1:43 AM
> To: sisyphus1@optusnet.com.au
> Cc: gcc-help@gcc.gnu.org ; Jonathan Wakely
> Subject: Re: A g++ bug ... or not ?
>
> [snip]
>
> > And libstdc++ is doing right thing (casting the `int` parameter to
> > `double`). But C++03 is not so clear and does not define what should
> > libstdc++ do. Libstdc++ chooses to call __builtin_powi. Unfortunately it
> > is not so precise.
>
> Based on that, I expected that another solution to the problem (ie instead
> of providing the explicit cast to double) would be to compile with
> "-fno-builtin".
> So I tried building the demo with "g++ -fno-builtin -std=c++03 -o try
> try.c", but the explicit cast to double was still required.
No. That won't work because libstdc++ is *explicitly* calling
`__builtin_powi`. `-fno-builtin` can only stop GCC to convert, for e.g.
`printf(...)` to `__builtin_printf(...)`.
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.
--
Xi Ruoyao <xry111@mengyan1223.wang>
School of Aerospace Science and Technology, Xidian University