From: Simon Marchi <simon.marchi@polymtl.ca>
To: Ulrich Weigand <uweigand@de.ibm.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [RFC][02/19] Target FP: Simplify floatformat_from_type
Date: Mon, 18 Sep 2017 16:21:00 -0000 [thread overview]
Message-ID: <af503ff0ff491144f47af6d538b9b022@polymtl.ca> (raw)
In-Reply-To: <20170918114951.28349D8083B@oc3748833570.ibm.com>
On 2017-09-18 13:49, Ulrich Weigand wrote:
> Simon Marchi wrote:
>
>> On 2017-09-05 20:20, Ulrich Weigand wrote:
>> > size_t len = bit / TARGET_CHAR_BIT;
>> > - gdb_assert (len >= floatformat_totalsize_bytes (floatformats[0]));
>> > - gdb_assert (len >= floatformat_totalsize_bytes (floatformats[1]));
>> > + gdb_assert (len * TARGET_CHAR_BIT >= floatformat->totalsize);
>>
>> That looks funny now. Is there a reason not to do
>>
>> gdb_assert (bit >= floatformat->totalsize);
>>
>> directly?
>
> Well, that would use different rounding ... Of course, this only
> matters when floatformat->totalsize is not a multiple of
> TARGET_CHAR_BIT,
> which doesn't happen for any of the floatformats GDB supports, so it
> is probably moot. Maybe we should instead use an assert to verify that
> floatformat->totalsize is in fact a multiple of TARGET_CHAR_BIT?
I indeed think we should add an assert that the type size in bits is a
multiple of TARGET_CHAR_BIT. But it should not be in
verify_floatformat, because it's not specific to float. In most calls
to arch_type/init_type, we have that division that rounds down:
t = init_type (objfile, TYPE_CODE_FLT, bit / TARGET_CHAR_BIT, name);
Let's say we try to add an integer with bit == 24 and TARGET_CHAR_BIT ==
16, we'll create a type with a size of 1 target byte, and things will
likely break down the line. Since this is where we do the division by
TARGET_CHAR_BIT, and therefore assume (implicitly) that bit is a
multiple of TARGET_CHAR_BIT, I think this is where the assert should be
added. To avoid adding them everywhere, we could make
arch_type/init_type take a size in bits, and do the division and assert
there.
As long as verify_floatformat is concerned, its job is to verify (IIUC)
that the type you want to create with BIT bits has enough room to hold a
float of that kind. It doesn't have to know that we'll later divide
that value by TARGET_CHAR_BIT. So here I think asserting "bit >=
floatformat->totalsize)" is fine.
I don't think floatformat->totalsize has any requirement to be a
multiple of TARGET_CHAR_BIT. For example, my hardware could have a
float of 29 bits, but when stored in memory it uses 32 bits (just like
on x86 long double is an 80 bit float stored in a 96 bit data type).
Then, bit would be 32 and floatformat->totalsize would be 29.
Simon
next prev parent reply other threads:[~2017-09-18 16:21 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-05 18:20 Ulrich Weigand
2017-09-17 15:29 ` Simon Marchi
2017-09-18 11:49 ` Ulrich Weigand
2017-09-18 16:21 ` Simon Marchi [this message]
2017-09-18 19:01 ` Ulrich Weigand
2017-09-20 16:30 ` Ulrich Weigand
2017-09-27 17:08 ` Ulrich Weigand
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=af503ff0ff491144f47af6d538b9b022@polymtl.ca \
--to=simon.marchi@polymtl.ca \
--cc=gdb-patches@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