Mirror of the gdb mailing list
 help / color / mirror / Atom feed
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


  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