Re: IA64 bootstrap problem for Ada

["Zack Weinberg" <zack at codesourcery dot com>]

kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:

>     > That's not what the code in layout_type does.  What it does is copy
>     > GET_MODE_BITSIZE to TYPE_SIZE and GET_MODE_SIZE to TYPE_UNIT_SIZE.  The
>     > right thing happens here by accident due to the alignment.
>
>     That needs to be fixed then.
>
> Do you want to do that?

I'll get to it eventually (I bet I have to fix it in order to make
MODE_BITSIZE of XFmode be 80) but I don't expect "eventually" to be
this side of December.

>     I do not understand the problem.  The number of significant bits is
>     GET_MODE_BITSIZE (mode).  The number of bits in the stored data is
>     GET_MODE_SIZE (mode) * BITS_PER_UNIT.  How is this mixed?
>
> The issue is *types*, not modes.  If we say that TYPE_SIZE is 128,
> then that means that the value is stored (somewhere) within 128 bits
> and that's the programmer-relevant size.
>
> So, in C, sizeof (long double) is 128/8 and, in Ada,
> Long_Long_Float'Size is 128.
>
> But LONG_DOUBLE_TYPE_SIZE, which purports to be the same value, is 96.
>
> That's the primary source of the confusion.

LONG_DOUBLE_TYPE_SIZE is misnamed; it ought to be
LONG_DOUBLE_TYPE_PRECISION.  It is appropriately used to initialize
TYPE_PRECISION, but *not* TYPE_SIZE (let layout_type do that).

> In Ada, the sizes of primitive types are static and hence known by the
> front end.  They get them from the _TYPE_SIZE values.

That's what needs to change.  Lay out the types first, then extract
the numbers from the TYPE_SIZE fields.

> Then Ada's decl.c, when given a size value for an FP type, does:
>
>       gnu_type = make_node (REAL_TYPE);
>       TYPE_PRECISION (gnu_type) = esize;
>       layout_type (gnu_type);

I'm not sure I understand what is meant by "when given a size value
for an FP type."  Does Ada allow the programmer to specify the desired
storage size of a floating point type, as a number of bits?  If so,
that specification is intrinsically ambiguous on ia64, where XFmode
(__float80), TFmode (__float128), and the eventual YFmode (__fpreg)
are ALL 128 bits wide.  There's nothing I can do about that; it's the
platform ABI.

> So we need to decide whether the _TYPE_SIZE values mean the *precision*
> or the *size*.

They are being used as precision elsewhere, and I think that's the
right thing.

> If the latter, then how does one create the REAL_TYPE node for the
> precision corresponding to that size?

You can't; it's ambiguous.  See above.

zw