This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: IA64 bootstrap problem for Ada

    > That's not what the code in layout_type does.  What it does is copy
    > 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;
      layout_type (gnu_type);

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?

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]