TFmode support with and without INTEL_EXTENDED_IEEE_FORMAT

[Steve Ellcey <sje at cup dot hp dot com>]

There was some discussion (more of just a comment actually) a couple of
weeks ago about having GCC support both "types" of TFmode in a single
compiler, where TFmode could be the current TFmode with
INTEL_EXTENDED_IEEE_FORMAT == 0 and something like a TXFmode would be
like TFmode is now with INTEL_EXTENDED_IEEE_FORMAT != 0.

I have been looking into this idea a little because the HP IA64 compiler
supports both of these (one as long double and one as __float80) and it
would be useful if GCC on HP IA64 could support them as well.

The first problem I ran into that I don't know how to deal with is in
machmode.def, currently all the modes of a particular class have different
sizes and this is used to differentiate between them.  We currently
have:

DEF_MACHMODE (SFmode, "SF", MODE_FLOAT, BITS_PER_UNIT*4, 4, 4, DFmode)
DEF_MACHMODE (DFmode, "DF", MODE_FLOAT, BITS_PER_UNIT*8, 8, 8, XFmode)
DEF_MACHMODE (XFmode, "XF", MODE_FLOAT, BITS_PER_UNIT*12, 12, 12, TFmode)
DEF_MACHMODE (TFmode, "TF", MODE_FLOAT, BITS_PER_UNIT*16, 16, 16, VOIDmode)

But if I add

DEF_MACHMODE (TXFmode, "TXF", MODE_FLOAT, BITS_PER_UNIT*16, 16, 16, TFmode)

(and modify the "next largest" type on XFmode to be TXFmode instead of
TFmode) then we have two types, TFmode and TXFmode with the same size
and I don't think GCC can handle that situation.  The tree node that is
set up for long_double_type_node for example will have a mode of
MODE_FLOAT and a precision of 128 regardless of whether is it supposed
to be TFmode or TXFmode and thus the two will be indistinguashable at
the tree level.

Can anyone think of a way to address this issue?

Steve Ellcey
sje@cup.hp.com