This is the mail archive of the gcc-patches@gcc.gnu.org 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: [LTO][PATCH] Fix long double precision problem


Mark Mitchell <mark at codesourcery.com> writes:
> Doug Kwan (éæå) wrote:
>> I want ot use DW_AT_bit_size to represent the precision of 80-bit
>> extended floats, which are stored in
>> 96-bit (12 bytes) locations. For complex 80-bit extended floats, the
>> two 80-bits real and imaginary parts have padding between them.  The
>> dwarf3 spec does not say if DW_AT_bit_size & DW_AT_bit_offset are for
>> a contiguous chunk of bits but I am inclined to interpret this way.
>> 
>> If it is too confusing to use DW_AT_bit_size and DW_AT_bit_offset to
>> represent 80-bit floats stored in 96-bit storage locations, we might
>> add an extension to dwarf3.
>
> I see.  Jim, as someone whose participated in DWARF standardization, do
> you have an opinion about how these complex floats ought to be
> represented?

From my reading, DW_AT_bit_size/DW_AT_bit_offset are intended to
handle just this sort of case.  Floating-point types are base types;
Section 5.1, "Base Type Entries", says:

    If the value of an object of the given type does not fully occupy
    the storage unit described by the byte size attribute, the base
    type entry may have a DW_AT_bit_size attribute and a
    DW_AT_bit_offset attribute, both of whose values (see Section
    2.19) are integers. The bit size attribute describes the actual
    size in bits used to represent a value of the given type. The bit
    offset attribute describes the offset in bits of the high order
    bit of a value of the given type from the high order bit of the
    storage unit used to contain that value.

That sounds pretty much like the situation in hand.

Section 5.6.6, "Data Member Entries", shows how those same two
attributes are used to describe bitfields within a structure, in the
little-endian and big-endian cases; we should try to use them
consistently on base types.  The process described there identifies a
containing anonymous object some integral number of bytes in length,
lays out that object's bits with the most significant on the left and
least on the right, and then says that DW_AT_bit_offset counts from
the leftmost bit of the anonymous object to the leftmost bit of the
field of interest.

So, for the eighty-bit float occupying a 12-byte slot, assuming the
eighty meaningful bits appear at the low-addressed end of that slot
regardless of endianess, you'd have a DW_AT_byte_size of 12, a
DW_AT_bit_size of 80, and a DW_AT_bit_offset of 16 on little-endian
machines, or zero on big-endian machines.


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