Re: Debugger support for __float128 type?
"Ulrich Weigand" <[email protected]>
| Newsgroups | gmane.comp.gdb.devel,gmane.comp.gcc.devel |
|---|---|
| Message-ID | <[email protected]> |
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 [email protected]