A g++ bug ... or not ?

[sisyphus1@optusnet.com.au]

-----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.

> "-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