[Bug c/42184] Same literal behaves differently as a double than as a long double

[kargl at gcc dot gnu dot org]

--- Comment #1 from kargl at gcc dot gnu dot org  2009-11-26 17:13 ---
I think that you may be looking at a library issue
and the conversion of a decimal string to binary.

Add
printf(%La\n%La\n%La\n%La\n, value1, value2, value3, value4);

to your program yields
REMOVE:kargl[209] ./z
0x1.68f5c2c528fa3p+70
0x1.68f5c2c528fa3p+70
0x1.68f5c2c528fa3p+70
0x1.68f5c2c528fa36p+70
1 1 1 0

on FreeBSD.  If I replace 1.6646342e21 everywhere in your program
with 0x1.68f5c2c528fa3p+70, I get the result you expect, ie.,

REMOVE:kargl[212] ./z
0x1.68f5c2c528fa3p+70
0x1.68f5c2c528fa3p+70
0x1.68f5c2c528fa3p+70
0x1.68f5c2c528fa3p+70
1 1 1 1


-- 


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

[Bug c/42184] Same literal behaves differently as a double than as a long double

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2009-11-26 21:11 ---
Well FreeBSD has slightly different default x87 precision setting .


-- 


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

[Bug c/42184] Same literal behaves differently as a double than as a long double

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2009-11-26 21:15 ---
1.6646342e21 will produce a double and then that is extended into long double.
On the other hand 1.6646342e21L is a long double so it is parsed what you
expect into a long double.

1 0 1 0 is the correct value for x87 (80bit long double).


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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