This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: 128 bit floats on PA64
- From: Jeff Law <law at porcupine dot slc dot redhat dot com>
- To: "John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>
- Cc: gcc-patches at gcc dot gnu dot org, sje at cup dot hp dot com
- Date: Fri, 30 Aug 2002 14:32:52 -0600
- Subject: Re: 128 bit floats on PA64
- Reply-to: law at redhat dot com
In message <200208301937.g7UJbNZc000339@hiauly1.hia.nrc.ca>, "John David
Anglin
" writes:
>> change the header order in config.gcc and make long-double.h last so it
>> sets LONG_DOUBLE_TYPE_SIZE to 128 after pa-64.h sets it to 64. Linux
>> does not include the long-double.h header. This still leaves the
>> CLASS_CANNOT_CHANGE_MODE, CLASS_CANNOT_CHANGE_MODE_P changes as
>> something that could affect 64 bit linux. 128 bit floats on HP-UX will
>> not work without removing these macros (or defining
>> CLASS_CANNOT_CHANGE_MODE as NOREGS). FYI: I also removed them from
>> pa32-regs.h and so no problems on PA32 HP-UX.
>
>There is a problem. LOAD_EXTEND_OP(MODE) is defined as ZERO_EXTEND
>but loads to FPRs don't ZERO_EXTEND. So, I don't think the macros
>can be removed. I don't fully understand why pa32-regs.h uses
>NO_REGS but this appears to work on the 32-bit port.
I believe CLASS_CANNOT_* were introduced to deal with ambiguities with
SUBREGS of floating point modes. The set of bits you'd get differed
depending on whether or not you were looking at a pseudo or hard
register (and even which hard register you looked at). So we tried
hard to keep the compiler from doing such things.
Between not exposing the 32bit halves of the 64bit FP regs and the
SUBREG_BYTE work I believe the CLASS_CANNOT* macros can probably
disappear.
jeff