-----Original Message-----
From: Xi Ruoyao
Sent: Saturday, September 08, 2018 1:43 AM
To: sisyphus1@xxxxxxxxxxxxxxx
Cc: gcc-help@xxxxxxxxxxx ; 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.
"-ansi" means "-std=c++98". Now GCC is defaulted to C++14.
Don't use -ansi, use -std= . Most likely you did not mean to use
std=c++98.
The current perl5 source contains a pow call that raises 2.0 to an "int"
power.
When (and only when) perl is built with recent g++, that pow() call will
return 0 whenever it should be returning a subnormal value. (No problems
with normal values.)
I'm not sure how the "-ansi" switch is being invoked for the building of
perl with g++, and I'll check on that.
I think the solution of providing the explicit cast is ok, but I had kept
wondering whether the behaviour was something that should be reported to the
gcc developers.
In the replies received, I've also gained a better understanding of what's
going on - and I thank you for that.
I very rarely have any involvement with the g++ compiler (or C++ code), but
this particular perl5 bug grabbed my interest.
Cheers,
Rob
