Re: 128 bit floats on PA64

[Jeff Law <law at porcupine dot slc dot redhat dot com>]

In message <200209031957.g83Jvsfk007936@hiauly1.hia.nrc.ca>, "John David Anglin
" writes:
 >Here is the PA portion of a patch to implement 128-bit long doubles
 >for TARGET_64BIT.
Great!  This is something that has needed to be fixed for a long long time.

 >CLASS_CANNOT_CHANGE_MODE_P is revised so that now the only mode changes
 >that are inhibited are those from SImode.  This is because SImode loads
 >to floating-point registers do not zero-extend.  I believe that this
 >is necessary as we do SImode loads to FPRs for the xmpy patterns.
 >They might happen in other rare situations as well.
Yes, it can happen in other rare situations.  This sounds correct to me.


 >Based on my reading of the "64-Bit Runtime Architecture for PA-RISC 2.0,
 >Version 3.3" (see pages 18 and 19), function_arg was grossly mishandling
 >DCmode and TCmode.  I believe that these should be treated in a manner
 >similar to that for other aggregates (BLKmode).  The same is also true
 >for TFmode quad-precision values.  As a result, I was able to considerably
 >simplify the TARGET_64BIT code.
You're probably correct.  I never got around to actually testing the
Complex modes or the 128bit FP support for PA64, so it's entirely possible
that function_arg was horribly wrong in how such arguments were handled.

 >Let me know ASAP if you have any comments, particularly if you believe
 >that I have misinterpreted the ABI wrt quad-precision floating point
 >and complex parameters.
I'm pretty sure you've got the ABI correct.

 >I think that this patch is a candidate for
 >the branch.  Although this fixes a problem in code that likely never
 >worked, I think it is a good idea to minimize the amount of code using
 >an incorrect ABI.
My gut tells me it's a branch candidate -- PA64 GCC doesn't have a lot of
users right now and fixing these ABI problems would probably be greatly
appreciated by the few users PA64 actually has :-)


jeff