[LTO][PATCH] Fix long double precision problem

[LTO][PATCH] Fix long double precision problem

[Doug Kwan (關振德)]

[-- Attachment #1: Type: text/plain, Size: 176 bytes --]

Hi,

    Could someone review this patch.  This fixes a problem where long
double type has BLK mode instead of the correct XF mode.  It fixes
about 20 dejagnu failures.

-Doug

[-- Attachment #2: patches.txt --]
[-- Type: text/plain, Size: 1505 bytes --]

2007-12-04  Doug Kwan  <dougkwan@google.com>

	* lto.c (lto_real_type_precision): New.
	(lto_read_base_type_DIE): Use type size to compute precision of
	a scalar real base type instead of using type size as precision.

Index: gcc/lto/lto.c
===================================================================
--- gcc/lto/lto.c	(revision 130614)
+++ gcc/lto/lto.c	(working copy)
@@ -2899,6 +2899,20 @@ lto_read_subrange_type_DIE (lto_info_fd 
   return type;
 }
 
+static int
+lto_real_type_precision (int size)
+{
+  if (size == TREE_INT_CST_LOW (TYPE_SIZE (float_type_node)))
+    return TYPE_PRECISION (float_type_node);
+  if (size == TREE_INT_CST_LOW (TYPE_SIZE (double_type_node)))
+    return TYPE_PRECISION (double_type_node);
+  if (size == TREE_INT_CST_LOW (TYPE_SIZE (long_double_type_node)))
+    return TYPE_PRECISION (long_double_type_node);
+
+  gcc_unreachable ();
+  return 0;
+}
+
 static tree
 lto_read_base_type_DIE (lto_info_fd *fd, 
 			lto_die_ptr die ATTRIBUTE_UNUSED,
@@ -3003,14 +3017,14 @@ lto_read_base_type_DIE (lto_info_fd *fd,
 
     case DW_ATE_float:
       type = make_node (REAL_TYPE);
-      TYPE_PRECISION (type) = bits;
+      TYPE_PRECISION (type) = lto_real_type_precision (bits);
       layout_type (type);
       break;
 
     case DW_ATE_complex_float:
       {
 	tree base = make_node (REAL_TYPE);
-	TYPE_PRECISION (base) = bits / 2;
+	TYPE_PRECISION (base) = lto_real_type_precision (bits / 2);
 	layout_type (base);
 	type = build_complex_type (base);
       }

Re: [LTO][PATCH] Fix long double precision problem

[Andrew Pinski]

On 12/4/07, Doug Kwan (關振德) <dougkwan@google.com> wrote:
> Hi,
>
>     Could someone review this patch.  This fixes a problem where long
> double type has BLK mode instead of the correct XF mode.  It fixes
> about 20 dejagnu failures.

I think for ia64-hpux, you can use both TFmode and XFmode so maybe
this is not going to work for that.

--Pinski

Re: [LTO][PATCH] Fix long double precision problem

[Kenneth Zadeck]

Andrew Pinski wrote:
> On 12/4/07, Doug Kwan (關振德) <dougkwan@google.com> wrote:
>   
>> Hi,
>>
>>     Could someone review this patch.  This fixes a problem where long
>> double type has BLK mode instead of the correct XF mode.  It fixes
>> about 20 dejagnu failures.
>>     
>
> I think for ia64-hpux, you can use both TFmode and XFmode so maybe
> this is not going to work for that.
>
> --Pinski
>   
is the right solution to just serialize the size and restore it from that?

kenny

Re: [LTO][PATCH] Fix long double precision problem

[Diego Novillo]

On 12/5/07 7:54 AM, Kenneth Zadeck wrote:

> is the right solution to just serialize the size and restore it from that?

Unless there is already a target hook for doing this, I think it's 
safest to just serialize these bits.


Diego.

Re: [LTO][PATCH] Fix long double precision problem

[Doug Kwan (關振德)]

Agree. I will change my patch and send it out when it's ready.

2007/12/5, Diego Novillo <dnovillo@google.com>:
> On 12/5/07 7:54 AM, Kenneth Zadeck wrote:
>
> > is the right solution to just serialize the size and restore it from that?
>
> Unless there is already a target hook for doing this, I think it's
> safest to just serialize these bits.
>
>
> Diego.
>

Re: [LTO][PATCH] Fix long double precision problem

[Andrew Pinski]

On 12/5/07, Doug Kwan (關振德) <dougkwan@google.com> wrote:
> Agree. I will change my patch and send it out when it's ready.

I think this can fix bit fields too if you emit the TYPE_PRECISION for them.

-- Pinski

Re: [LTO][PATCH] Fix long double precision problem

[Mark Mitchell]

Kenneth Zadeck wrote:

>> I think for ia64-hpux, you can use both TFmode and XFmode so maybe
>> this is not going to work for that.
>>
>> --Pinski
>>   
> is the right solution to just serialize the size and restore it from that?

Yes, and that's what the current code is doing; it looks at
DW_AT_bit_size in the DWARF information to determine how many bits to
use.  If that's not sufficient because, for example, DW_AT_bit_size is
the number of bits consumed in memory, but TYPE_PRECISION is supposed to
be the number of bits of useful data, then we should add a
DW_AT_gnu_precision attribute to the DWARF.

This is exactly the kind of DWARF extension we want to make: in addition
to being useful for LTO, we get better information for the debugger.
Please make sure that any new DWARF attributes are clearly documented,
without reference to GCC internals; the right documentation for
DW_AT_gnu_precision is not "this is TYPE_PRECISION".

However, first we should check if DW_AT_bit_size is being emitted correctly.

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: [LTO][PATCH] Fix long double precision problem

[Doug Kwan (關振德)]

2007/12/5, Mark Mitchell <mark@codesourcery.com>:

> However, first we should check if DW_AT_bit_size is being emitted correctly.

On i386, 80-bit extended floating point format is stored in 12 bytes
(96 bits).  It is a problem even if DW_AT_bit_size is being emitted
correctly.

-Doug

Re: [LTO][PATCH] Fix long double precision problem

[Doug Kwan (關振德)]

The reason why I did the patch that way is to avoid changing the
external debugging interface. If we need to serialize precisions, we
may not need another GNU dwarf extension.  Currently already gcc emits
DW_AT_bit_size and DW_AT_bit_offset pairs for integral types whose
precisions are less than their bit width.  We can just add code to
handling real scalar types.

I am not sure what changes, if any, are required on the client side of
the debugging information (e.g. gdb).  I am willing to implement those
changes though.

-Doug

2007/12/5, Mark Mitchell <mark@codesourcery.com>:

> This is exactly the kind of DWARF extension we want to make: in addition
> to being useful for LTO, we get better information for the debugger.
> Please make sure that any new DWARF attributes are clearly documented,
> without reference to GCC internals; the right documentation for
> DW_AT_gnu_precision is not "this is TYPE_PRECISION".

Re: [LTO][PATCH] Fix long double precision problem

[Mark Mitchell]

Doug Kwan (關振德) wrote:
> The reason why I did the patch that way is to avoid changing the
> external debugging interface. If we need to serialize precisions, we
> may not need another GNU dwarf extension.  Currently already gcc emits
> DW_AT_bit_size and DW_AT_bit_offset pairs for integral types whose
> precisions are less than their bit width.  We can just add code to
> handling real scalar types.

Yes, I think you're 100% right.  I've reviewed the DWARF spec and,
indeed, DW_AT_bit_size/DW_AT_bit_offset are designed for exactly this
case.  So, we should just arrange to emit that information in dwarf2out.c.

> I am not sure what changes, if any, are required on the client side of
> the debugging information (e.g. gdb).  I am willing to implement those
> changes though.

I'm certainly not a GDB expert so I don't know what impact that might
have either.  It's just making the debug information more complete, so,
hopefully, it should Just Work, but it could of course also be the case
that something goes wrong.  Running the GDB testsuite is probably a good
first cut.  I'd suggest asking on the GDB mailing list.

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: [LTO][PATCH] Fix long double precision problem

[Doug Kwan (關振德)]

I got no reply from gdb mailing list. Apparently no one care :)

There is another wrinkle. The complex extended float type has the same
issue.  I don't really think it is correct to use DW_AT_bit_size &
DW_AT_bit_offset for this case since the bits are not contiguous.
However, in the name of not complicating things, I prefer using
existing DW_AT_bit_size and DW_AT_bit_offset than adding a new GNU
extension.  I am fine either way. What do you guys think?

-Doug

2007/12/5, Mark Mitchell <mark@codesourcery.com>:
> Doug Kwan (關振德) wrote:
> > The reason why I did the patch that way is to avoid changing the
> > external debugging interface. If we need to serialize precisions, we
> > may not need another GNU dwarf extension.  Currently already gcc emits
> > DW_AT_bit_size and DW_AT_bit_offset pairs for integral types whose
> > precisions are less than their bit width.  We can just add code to
> > handling real scalar types.
>
> Yes, I think you're 100% right.  I've reviewed the DWARF spec and,
> indeed, DW_AT_bit_size/DW_AT_bit_offset are designed for exactly this
> case.  So, we should just arrange to emit that information in dwarf2out.c.
>
> > I am not sure what changes, if any, are required on the client side of
> > the debugging information (e.g. gdb).  I am willing to implement those
> > changes though.
>
> I'm certainly not a GDB expert so I don't know what impact that might
> have either.  It's just making the debug information more complete, so,
> hopefully, it should Just Work, but it could of course also be the case
> that something goes wrong.  Running the GDB testsuite is probably a good
> first cut.  I'd suggest asking on the GDB mailing list.
>
> Thanks,
>
> --
> Mark Mitchell
> CodeSourcery
> mark@codesourcery.com
> (650) 331-3385 x713
>

Re: [LTO][PATCH] Fix long double precision problem

[Mark Mitchell]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=Big5, Size: 611 bytes --]

Doug Kwan (Ãö®¶¼w) wrote:

> There is another wrinkle. The complex extended float type has the same
> issue.  I don't really think it is correct to use DW_AT_bit_size &
> DW_AT_bit_offset for this case since the bits are not contiguous.
> However, in the name of not complicating things, I prefer using
> existing DW_AT_bit_size and DW_AT_bit_offset than adding a new GNU
> extension.  I am fine either way. What do you guys think?

What do you mean about the bits not being contiguous?  Can you explain
that a little bit?

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: [LTO][PATCH] Fix long double precision problem

[Doug Kwan (關振德)]

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.

-Doug

在 2007/12/11，Mark Mitchell <mark@codesourcery.com> 撰寫：

> What do you mean about the bits not being contiguous?  Can you explain
> that a little bit?

Re: [LTO][PATCH] Fix long double precision problem

[Mark Mitchell]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=Big5, Size: 974 bytes --]

Doug Kwan (Ãö®¶¼w) 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?

Doug, in the near term, I don't think we need to worry about the
padding.  We should just use DW_AT_bit_{size,offset} for floating-point
types.

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: [LTO][PATCH] Fix long double precision problem

[Doug Kwan (關振德)]

[-- Attachment #1: Type: text/plain, Size: 192 bytes --]

Hi,

   Here is another attempt to fix this issue by emitting
DW_AT_bit_size and DW_AT_bit_offset for float types which have
precisions smaller than their storage size.  Please review.

-Doug

[-- Attachment #2: patches-2.txt --]
[-- Type: text/plain, Size: 2555 bytes --]

ChangleLog.lto

2007-12-12  Doug Kwan  <dougkwan@google.com>

	* dwarf2out.c (base_type_die): Emit extra DW_AT_bit_size and
	DW_AT_bit_offset pair for scalar and complex float types that
	have precisions smaller than storage sizes.

lto/ChangeLog

2007-12-12  Doug Kwan  <dougkwan@google.com>

	* lto.c (lto_read_base_type_DIE): Add support for float types in
	code that deals with DW_AT_bit_size and DW_AT_bit_offset.

Index: gcc/dwarf2out.c
===================================================================
--- gcc/dwarf2out.c	(revision 130795)
+++ gcc/dwarf2out.c	(working copy)
@@ -8494,7 +8494,8 @@ base_type_die (tree type)
 
   /* Emit extra information for integral types whose precision is less
      than the bit width of their containing object.  */
-  if (TREE_CODE (type) == INTEGER_TYPE
+  if ((TREE_CODE (type) == INTEGER_TYPE
+       || SCALAR_FLOAT_TYPE_P (type))
       && TYPE_PRECISION (type) < byte_size * BITS_PER_UNIT)
     {
       add_AT_unsigned (base_type_result, DW_AT_bit_size,
@@ -8502,6 +8503,20 @@ base_type_die (tree type)
       add_AT_unsigned (base_type_result, DW_AT_bit_offset,
 		       byte_size * BITS_PER_UNIT - TYPE_PRECISION (type));
     }
+  else if (COMPLEX_FLOAT_TYPE_P (type))
+    {
+      tree scalar_type = TREE_TYPE (type);
+      int bits_used = TYPE_PRECISION (scalar_type) * 2;
+      if (bits_used < byte_size * BITS_PER_UNIT)
+      {
+	/* FIXME: If the scalar type has precision smaller than half of the
+ 	   storage size, the bits are possibly not contiguous.  We are
+	   probably abusing the DW_AT_bit_size/DW_AT_bit_offset semantics. */ 
+	add_AT_unsigned (base_type_result, DW_AT_bit_size, bits_used);
+	add_AT_unsigned (base_type_result, DW_AT_bit_offset,
+			 byte_size * BITS_PER_UNIT - bits_used);
+      }
+    }
 
   return base_type_result;
 }
Index: gcc/lto/lto.c
===================================================================
--- gcc/lto/lto.c	(revision 130795)
+++ gcc/lto/lto.c	(working copy)
@@ -3012,8 +3012,11 @@ lto_read_base_type_DIE (lto_info_fd *fd,
     {
       if (bits > maxbits)
 	lto_file_corrupt_error ((lto_fd *)fd);
-      if (encoding != DW_ATE_unsigned && encoding != DW_ATE_signed)
-	sorry ("bit size attribute only supported for signed/unsigned types");
+      if (encoding != DW_ATE_unsigned
+	  && encoding != DW_ATE_signed
+	  && encoding != DW_ATE_float
+	  && encoding != DW_ATE_complex_float)
+	sorry ("bit size attribute only supported for some types");
       if (offset != maxbits - bits)
 	sorry ("unaligned base type not supported");
     }

Re: [LTO][PATCH] Fix long double precision problem

[Andreas Schwab]

""Doug Kwan (關振德)"" <dougkwan@google.com> writes:

> Index: gcc/dwarf2out.c
> ===================================================================
> --- gcc/dwarf2out.c	(revision 130795)
> +++ gcc/dwarf2out.c	(working copy)
> @@ -8494,7 +8494,8 @@ base_type_die (tree type)
>  
>    /* Emit extra information for integral types whose precision is less
>       than the bit width of their containing object.  */
> -  if (TREE_CODE (type) == INTEGER_TYPE
> +  if ((TREE_CODE (type) == INTEGER_TYPE
> +       || SCALAR_FLOAT_TYPE_P (type))
>        && TYPE_PRECISION (type) < byte_size * BITS_PER_UNIT)
>      {

What if the padding is internal?

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [LTO][PATCH] Fix long double precision problem

[Doug Kwan (關振德)]

At I have mentioned earlier. That may not be a correct thing to do. On
the x86, the 80-bit extended floating point formating is stored using
one instruction and there is no internal padding.  However, there is
internal padding in complex long double.  Any thing expecting a
contiguous chunk of bits may be surprised.

I have done some simple testing with gdb by compiling test and
stepping them under gdb.  The long double case worked but complex long
double caused gdb to crash.  That was more likely that it was a bug in
gdb as gdb crashed with debug info generated from stock gcc also.

In the long term, we need an appropriate dwarf extension.

-Doug

2007/12/13, Andreas Schwab <schwab@suse.de>:

> What if the padding is internal?
>
> Andreas.

Re: [LTO][PATCH] Fix long double precision problem

[Andreas Schwab]

""Doug Kwan (關振德)"" <dougkwan@google.com> writes:

> At I have mentioned earlier. That may not be a correct thing to do.

It doesn't handle endianess correctly either, AFAICS.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [LTO][PATCH] Fix long double precision problem

[Doug Kwan (關振德)]

At least for the LTO, we only care about the number of bit used. The
bit offset is bogus.   Also long as gcc and recover the floating point
type based on the number of bits used, it is okay.

Instead of abusing the DW_AT_bit_size and DW_AT_bit_offset pair, I can
use a new dwarf extension as I mentioned earlier in this thread.

-Doug

2007/12/14, Andreas Schwab <schwab@suse.de>:
> ""Doug Kwan (關振德)"" <dougkwan@google.com> writes:

> It doesn't handle endianess correctly either, AFAICS.

Re: [LTO][PATCH] Fix long double precision problem

[Jim Blandy]

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.

Re: [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.
>

Re: [LTO][PATCH] Fix long double precision problem

[Jim Blandy]

""Doug Kwan (關振德)"" <dougkwan at google.com> writes:
>    What about complex long double? There are padding bits between the
> real and imaginary parts.

My understanding is that the base types are not meant to completely
specify how the debugger should interpret a type it's never seen
before; they're just meant to distinguish the source language's base
types.  For example, DWARF just has DW_ATE_float, not
DW_ATE_ieee_float, nor DW_ATE_float with DW_AT_mantissa_bits and
DW_AT_exponent_bias.  Once the DWARF has identified the type, it's up
to the ABI to specify the details of its representation.

Under that interpretation, all GCC should do for long double complex
is emit a DW_TAG_base_type with DW_ATE_complex_float and
DW_AT_byte_size == 24.  That's enough to distinguish long double
complex from double complex or float complex.  It's not necessary for
the DWARF to explicitly mention the 80-bit length if the ABI dictates
that for a lone 24-byte complex type.  (Do you also have a full
12-byte floating point complex format that would be ambiguous with
that?)

But that interpretation doesn't square too well with providing data
like DW_AT_bit_size and DW_AT_bit_offset.  So the interpretation is
unclear to me.  I don't remember this coming up; it may simply not
have been considered.

Re: [LTO][PATCH] Fix long double precision problem

[Doug Kwan (關振德)]

Would that easier and less error prone if we just emit the precision?
I looked at the i386 and ia64 backend and found float types with
precisions 32, 64, 80, 82 and 128. I am not sure if there is an easy
way to do the search in an architecture-indepedent manner?

-Doug

2007/12/16, Mark Mitchell <mark@codesourcery.com>:

> That seems reasonable enough.  I guess the LTO front end can process a
> complex type by dividing its size by two, and then searching for a
> matching integral or floating-point base type, and using that information.

Re: [LTO][PATCH] Fix long double precision problem

[Mark Mitchell]

Doug Kwan (關振德) wrote:
> Would that easier and less error prone if we just emit the precision?
> I looked at the i386 and ia64 backend and found float types with
> precisions 32, 64, 80, 82 and 128. I am not sure if there is an easy
> way to do the search in an architecture-indepedent manner?

You could look at how things like type_for_mode/type_for_size (sp?) are
implemented.  I don't think we can easily go by the names of the types,
since the "same type" will have different names in C, Ada, and Fortran
for example.

But, I think we're trying too hard for complex types, right at the
moment.  The bit_offset/bit_size thing is right for ordinary floating
point types and we should be able to handle that easily.  My guess is
that for complex types we could add DW_AT_GNU_real_type that indicates
which base type is in use.

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713