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: Debugger support for __float128 type?

On Fri, 2 Oct 2015, Ulrich Weigand wrote:

> Joseph Myers wrote:
> > On Thu, 1 Oct 2015, Ulrich Weigand wrote:
> > 
> > > The _DecimalN types are already supported by DWARF using a base type with
> > > encoding DW_ATE_decimal_float and the appropriate DW_AT_byte_size.
> > 
> > Which doesn't actually say whether the DPD or BID encoding is used, but as 
> > long as each architecture uses only one that's not a problem in practice.
> 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.

> The new DW_ATE_interchange_float encoding would say instead; this is
> a floating-point number of size N encoded as defined by the IEEE
> interchange format.
> On platforms where the ABI-defined format actually *is* the interchange
> format, a DWARF producer would be free to use either DW_ATE_float or
> DW_ATE_interchange_float.  This decision could of course take into
> consideration compatibility requirements with older debuggers etc.
> However, having two encoding definitions would allow platforms to use
> both the interchange format and one additional platform-defined
> non-interchange format of the same size, if needed.

That makes sense to me.

> 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?

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)?

Joseph S. Myers

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