F77 FP screwup (i386 cross-compiler -> vax)
Matt Thomas
matt@3am-software.com
Tue Aug 27 12:37:00 GMT 2002
I've been trying to figure out why the g77 testsuite has so
many failures for a VAX target when my host is running
NetBSD/i386. Briefly, it comes down to g771 emitting
incorrect floating point numbers.
Given the following two small programs:
foo = acos(0.54030231)
end
And
x(void) { acos(0.54030231); }
I would expect them to generate approx. the same code.
However, g771 produces:
MAIN__:
.word 0x0
subl2 $8,%sp
movd $0d1.29016895825556275845e10,-(%sp)
calls $2,acos
while cc1 produces:
x:
.word 0x0
subl2 $4,%sp
movd $0d5.40302309999999993972e-1,-(%sp)
calls $2,acos
This leads me to conclude that g77 has a bug in where it converts text
FP strings to a binary repesentation. Now interestingly, the binary
pattern of $0d1.29016895825556275845e10 in IEEE FP is very close to
binary pattern of $0d5.40302309999999993972e-1 in VAX FP. As floats,
the former is 0x5040400a and the latter is 0x5140400a. Somehow that
doesn't seem to be a coincidence.
In output_operand, the RTL for FP value in g771 and cc1 are:
(const_double:DF 1728053248 [0x67000000] 171680655 [0xa3ba38f] 1075888192
[0x4020c040])
(const_double:DF -1560281088 [0xa3000000] 1083139899 [0x408f673b]
1073646161 [0x3ffe8a51])
Before I dig into the f77 sources, I was hoping this might trigger
someone who knows f77 to fix it for me. :)
--
Matt Thomas Internet: matt@3am-software.com
3am Software Foundry WWW URL: http://www.3am-software.com/bio/matt/
Cupertino, CA Disclaimer: I avow all knowledge of this message
More information about the Gcc-bugs
mailing list