[Bug c++/16607] Incorrect FP code generated in member data initialization

["npr1 at suomi24 dot fi" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From npr1 at suomi24 dot fi  2004-07-19 02:58 -------
I'm taking it back now. (skip to --- if you're in a hurry)

It took so long to understand, now I feel ashamed. I'm not a floating point 
guru, which you might have guessed. I have read about the extra precision within 
FPU, but didn't understand the same might apply between float and double /and/ 
that grammatically, in double = float * float the right side is actually of the 
type float, and so the result /may or may not/ contain extra precision relative 
to that float. To add to the matter, it obviously also can both have the extra 
precision and not have it in the same run.

It's quite weird how the compiler only in this case goes through extra hoops 
(with a minor performance loss, too) to lose the extra precision. If the program 
is modified in any great way, and in all other uses of y even this way, it uses 
the value with extra precision.

This came up in such a complicated program spun across function calls that I 
just couldn't imagine the cause being so simple. Sorry for overlooking the 
possibility so long.

---

I'm still wondering if the standards allow this extra precision to happen across 
function calls, albait inlined by the compiler. If it does, feel free to once 
again mark this as a duplicate of report 323, forget this issue, and I'll go 
repent and not bother you any more.

I'm sorry I didn't find an authoritative source and must still speculate. I 
don't have the standard or know where else to look.

I've learned from this in any case. The lesson, sadly, is that even within the 
insides of one function, I can't rely on a double argument to hold it's value to 
more precision than that of a float. I'm still hoping this is not the case, so a 
confirmation either way would be greatly appreciated.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16607