[LTO][PATCH] Fix long double precision problem

[Doug Kwan (關振德)]

Jim,

   What about complex long double? There are padding bits between the
real and imaginary parts.

-Doug

2007/12/13, Jim Blandy <jimb@codesourcery.com>:
>
> 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.
>