Re: Debugger support for __float128 type?

["Ulrich Weigand" <uweigand@de.ibm.com>]

Joseph Myers wrote:
> On Fri, 2 Oct 2015, Ulrich Weigand wrote:
> > I see.  Well, one could add a DW_ATE_decimal_interchange_float for
> > completeness, if necessary.
> 
> Since both DPD and BID are interchange encodings, that doesn't actually 
> determine things without some way to say which was used (that is, both 
> DW_ATE_decimal_float and DW_ATE_decimal_interchange_float would rely on 
> platform-specific information to determine the format).  I don't know if 
> DW_ATE_decimal_float is being used anywhere for something that's not an 
> interchange format.

Ah, yes.  I missed that both DPD and BID are defined as interchange
formats.  This suggestion doesn't make sense then ...

> > As an alternative to specifying the well-defined interchange format,
> > another option might be to simply add a second DWARF attribute,
> > e.g. DW_AT_encoding_variant, to floating-point and related base types.
> > This would simply be an integer with platform-specific semantics.
> > So DWARF producers could simply describe a type as:
> >   this is a floating-point number of size N encoded as defined by
> >   platform ABI encoding variant #V
> 
> Do you want entirely platform-specific semantics?  Or would it be better 
> to define standard values to mean it's an IEEE interchange format (or, for 
> decimal floating point, to specify whether it's DPD or BID), plus space 
> for future standard values and space for platform-specific values?

Hmm, I had been thinking of leaving that entirely platform-specific.
I guess one could indeed define some values with well-defined standard
semantics; that would assume DWARF would want to start getting into the
game of defining floating-point formats -- not sure what the position
of the committee would be on this question ...

[ Back when DW_ATE_decimal_float was added, the initial proposal did
indeed specify the encoding should follow IEEE-754R, but that was
removed when the proposal was actually added to the standard.  ]

> Would existing consumers safely ignore that attribute (so that producers 
> could safely specify IEEE interchange encoding for float, double etc. if 
> applicable, without breaking existing consumers)?

Yes, existing consumers should simply ignore attributes they are not
aware of.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  Ulrich.Weigand@de.ibm.com