>
>
>
>for a start, look at the sparc64 entries in doc/HACKS.  floating point
>is definately a problem.  there are multiple issues here from what i
>know.  our fpu emulation has bugs.  gcc has bugs in both the softfloat
>and hardfloat code it outputs.  we are missing the _Q_*(?) functions
>that the ELF abi specifies.  there are also issues with optimisation
>blowouts (eg, see the sha1.c entry in HACKS.)
>
>
>a scan of archives will also find other issues i think.

Gcc generates ok emulation for the 32bit versions of the quad float routines
(_Q_*) but generates incorrect code for the 64bit varieties (_Qp_*).

I'm working on back-porting the gcc 3.x changes which fix this, but the rtl
syntax is slightly different in places I'm having to adjust as I merge pieces
of the 2 md files together.

Past that once I can get the compiler to generate correct calls for the 
routines, the routines themselves are easy to produce using the softfloat
library and it's 128bit functions for quad math.

Beyond that our quad float emulation (in kernel) is broken in some places which
is the other reason for going down this road (fixing the kernel should be
done also, but it's much much slower to trap/emulate then just calling into
a softfloat routine for these ops).

James