gcc-4_1-branch backports of the long double changes

[Jakub Jelinek]

On Sun, Feb 05, 2006 at 10:31:24PM -0800, Mark Mitchell wrote:
> Alexandre Oliva wrote:
> > On Feb  5, 2006, Jakub Jelinek <jakub@redhat.com> wrote:
> 
> > I don't think there's any good reason to duplicate the forward
> > declaration of locale here.
> 
> I understood that the libstdc++ changes would not be going into 4.1 at
> all.  I think that's too risky, and the patch is too big to accept at
> this point.

That's why I separated the patches.
The first one is the one I want to see in GCC 4.1 (and also some kind of the
ppc32 long double patch).

For the second and third patch I'd like to see it on the trunk,
redhat/gcc-4_1-branch and if there is enough interest on say
gcc-4_1-long-double-branch where that would be the only changes from
gcc-4_1-branch.  Whether that could be then merged to 4.1.1, 4.1.2 or not at any
4.1.x is certainly your (as RM) decision.

I think it is quite obvious that
http://gcc.gnu.org/ml/gcc-patches/2006-02/txt00024.txt
doesn't affect code unless -mlong-double-128 (not the default and really not
usable on Linux up to now) on the few selected linux targets (ppc{,64},
s390{,x}, sparc (32-bit) and alpha) plus if Hurd shares the same headers
also on Hurd if Hurd is at all supported on those arches.

http://gcc.gnu.org/ml/gcc-patches/2006-01/msg01907.html
likewise, though it requires a little bit more reading.
All the changes are:
1) either guarded by TARGET_LONG_DOUBLE_128, therefore it doesn't affect
-mlong-double-64 code
2) or are in dealing with TFmode, again, something that doesn't show up
in -mlong-double-64 code
3) rs6000_ieeequad switch setup, but as TARGET_IEEEQUAD is only used
together in 1) or 2) contexts, it doesn't affect -mlong-double-64
4) addition of cum->fregno = FP_ARG_V4_MAX_REG + 1; line, but
here we know that with DFmode fregno is always incremented by one and
when this line is executed, cum->fregno > FP_ARG_V4_MAX_REG
5) replaced cum->fregno++ with cum->fregno += (GET_MODE_SIZE (mode) + 7) >> 3
and n_reg = 1 with n_reg = (size + 7) / 8 (in both cases, they are
equivalent for SFmode and DFmode).
6) n_reg == 2 => n_reg == 2 && reg == gpr (here, n_reg == 2 with non-gpr
is only possible for TFmode
7)   #define CANNOT_CHANGE_MODE_CLASS(FROM, TO, CLASS)                        \
 -  (((DEFAULT_ABI == ABI_AIX || DEFAULT_ABI == ABI_DARWIN)                \
 -    && GET_MODE_SIZE (FROM) >= 8 && GET_MODE_SIZE (TO) >= 8)               \
 +  (!TARGET_IEEEQUAD                                                      \
 +   && GET_MODE_SIZE (FROM) >= 8 && GET_MODE_SIZE (TO) >= 8                 \
     ? 0                                                                   \
     : GET_MODE_SIZE (FROM) != GET_MODE_SIZE (TO)                                  \
     ? reg_classes_intersect_p (FLOAT_REGS, CLASS)                         \
ppc64-linux uses ABI_AIX and the change doesn't affect AIX nor Darwin,
so it only affects 32-bit code.  But, TImode is unsupported in 32-bit code,
so the only case where GET_MODE_SIZE (FROM) != GET_MODE_SIZE (TO) is
when one of them is TFmode, or possibly DCmode.  That is the only place
where it could affect -mlong-double-64 code I guess.

Now, another thing is to show that it won't affect AIX, Darwin.
Most of the changes are of the
(DEFAULT_ABI == ABI_AIX || DEFAULT_ABI == ABI_DARWIN) -> !TARGET_IEEEQUAD
kind, as TARGET_IEEEQUAD is defined to 0 on both AIX and Darwin this is
really no change for those two targets.  The other changes are in
ABI_V4 code, so don't affect these either.

	Jakub