From: Joseph Myers <joseph@codesourcery.com>
To: Ulrich Weigand <uweigand@de.ibm.com>
Cc: <gcc@gcc.gnu.org>, <gdb@sourceware.org>
Subject: Re: Debugger support for __float128 type?
Date: Fri, 02 Oct 2015 15:41:00 -0000 [thread overview]
Message-ID: <alpine.DEB.2.10.1510021531530.25102@digraph.polyomino.org.uk> (raw)
In-Reply-To: <20151002151753.C9DCF123D8@oc7340732750.ibm.com>
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
joseph@codesourcery.com
next prev parent reply other threads:[~2015-10-02 15:41 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-30 17:33 Ulrich Weigand
2015-09-30 20:12 ` Joseph Myers
2015-10-01 17:23 ` Ulrich Weigand
2015-10-01 20:40 ` Joseph Myers
2015-10-02 15:18 ` Ulrich Weigand
2015-10-02 15:41 ` Joseph Myers [this message]
2015-10-02 16:01 ` Ulrich Weigand
2015-09-30 22:42 ` Mark Kettenis
2015-10-01 9:46 ` Gabriel Paubert
2015-10-01 16:16 ` Ulrich Weigand
2015-10-02 9:41 ` Jonas Maebe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.10.1510021531530.25102@digraph.polyomino.org.uk \
--to=joseph@codesourcery.com \
--cc=gcc@gcc.gnu.org \
--cc=gdb@sourceware.org \
--cc=uweigand@de.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox