public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jim Blandy <jimb@codesourcery.com>
To: Mark Mitchell <mark@codesourcery.com>
Cc: "Doug Kwan (關振德)" <dougkwan@google.com>,
	"Kenneth Zadeck" <zadeck@naturalbridge.com>,
	"Andrew Pinski" <pinskia@gmail.com>,
	gcc-patches@gcc.gnu.org, "Diego Novillo" <dnovillo@google.com>,
	"Nathan Froyd" <froydnj@codesourcery.com>
Subject: Re: [LTO][PATCH] Fix long double precision problem
Date: Thu, 13 Dec 2007 20:11:00 -0000	[thread overview]
Message-ID: <m33au65q7b.fsf@codesourcery.com> (raw)
In-Reply-To: <476047B6.3090704@codesourcery.com> (Mark Mitchell's message of "Wed, 12 Dec 2007 12:42:30 -0800")


Mark Mitchell <mark at codesourcery.com> writes:
> Doug Kwan (關振德) wrote:
>> I want ot use DW_AT_bit_size to represent the precision of 80-bit
>> extended floats, which are stored in
>> 96-bit (12 bytes) locations. For complex 80-bit extended floats, the
>> two 80-bits real and imaginary parts have padding between them.  The
>> dwarf3 spec does not say if DW_AT_bit_size & DW_AT_bit_offset are for
>> a contiguous chunk of bits but I am inclined to interpret this way.
>> 
>> If it is too confusing to use DW_AT_bit_size and DW_AT_bit_offset to
>> represent 80-bit floats stored in 96-bit storage locations, we might
>> add an extension to dwarf3.
>
> I see.  Jim, as someone whose participated in DWARF standardization, do
> you have an opinion about how these complex floats ought to be
> represented?

From my reading, DW_AT_bit_size/DW_AT_bit_offset are intended to
handle just this sort of case.  Floating-point types are base types;
Section 5.1, "Base Type Entries", says:

    If the value of an object of the given type does not fully occupy
    the storage unit described by the byte size attribute, the base
    type entry may have a DW_AT_bit_size attribute and a
    DW_AT_bit_offset attribute, both of whose values (see Section
    2.19) are integers. The bit size attribute describes the actual
    size in bits used to represent a value of the given type. The bit
    offset attribute describes the offset in bits of the high order
    bit of a value of the given type from the high order bit of the
    storage unit used to contain that value.

That sounds pretty much like the situation in hand.

Section 5.6.6, "Data Member Entries", shows how those same two
attributes are used to describe bitfields within a structure, in the
little-endian and big-endian cases; we should try to use them
consistently on base types.  The process described there identifies a
containing anonymous object some integral number of bytes in length,
lays out that object's bits with the most significant on the left and
least on the right, and then says that DW_AT_bit_offset counts from
the leftmost bit of the anonymous object to the leftmost bit of the
field of interest.

So, for the eighty-bit float occupying a 12-byte slot, assuming the
eighty meaningful bits appear at the low-addressed end of that slot
regardless of endianess, you'd have a DW_AT_byte_size of 12, a
DW_AT_bit_size of 80, and a DW_AT_bit_offset of 16 on little-endian
machines, or zero on big-endian machines.

  parent reply	other threads:[~2007-12-13 19:50 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-05  7:05 Doug Kwan (關振德)
2007-12-05 10:52 ` Andrew Pinski
2007-12-05 12:55   ` Kenneth Zadeck
2007-12-05 14:56     ` Diego Novillo
2007-12-05 16:28       ` Doug Kwan (關振德)
2007-12-05 19:02         ` Andrew Pinski
2007-12-05 16:34     ` Mark Mitchell
2007-12-05 18:42       ` Doug Kwan (關振德)
2007-12-05 19:01       ` Doug Kwan (關振德)
2007-12-05 23:52         ` Mark Mitchell
2007-12-11 23:15           ` Doug Kwan (關振德)
2007-12-12  9:22             ` Mark Mitchell
2007-12-12 20:23               ` Doug Kwan (關振德)
2007-12-12 20:45                 ` Mark Mitchell
2007-12-13  2:27                   ` Doug Kwan (關振德)
2007-12-13 11:02                     ` Andreas Schwab
2007-12-13 19:13                       ` Doug Kwan (關振德)
2007-12-14  9:50                         ` Andreas Schwab
2007-12-14 22:18                           ` Doug Kwan (關振德)
2007-12-13 20:11                   ` Jim Blandy [this message]
2007-12-13 20:40                     ` Doug Kwan (關振德)
2007-12-13 22:43                       ` Jim Blandy
     [not found]                         ` <4765FBC0.8020400@codesourcery.com>
2007-12-17 21:53                           ` Doug Kwan (關振德)
2007-12-18  4:29                             ` Mark Mitchell

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=m33au65q7b.fsf@codesourcery.com \
    --to=jimb@codesourcery.com \
    --cc=dnovillo@google.com \
    --cc=dougkwan@google.com \
    --cc=froydnj@codesourcery.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=mark@codesourcery.com \
    --cc=pinskia@gmail.com \
    --cc=zadeck@naturalbridge.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).