This is the mail archive of the
mailing list for the GCC project.
Re: IA64 bootstrap problem for Ada
- From: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- To: zack at codesourcery dot com
- Cc: gcc at gcc dot gnu dot org
- Date: Thu, 30 Oct 03 16:51:18 EST
- Subject: Re: IA64 bootstrap problem for Ada
> 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 don't see how to make Ada work with this sort of definition, though,
> because it mixes the number of signifcant bits and number of bits in the
> stored data in a way that I don't see how to separate.
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.
In Ada, the sizes of primitive types are static and hence known by the
front end. They get them from the _TYPE_SIZE values.
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;
which I think is reasonable. However, the *size* of the resulting type
when "esize" is 96 is 128, which now does not agree with the front end.
So we need to decide whether the _TYPE_SIZE values mean the *precision*
or the *size*. If the latter, then how does one create the REAL_TYPE
node for the precision corresponding to that size?