F77 FP screwup (i386 cross-compiler -> vax)

[Matt Thomas <matt at 3am-software dot com>]

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