From: Joseph Myers <joseph@codesourcery.com>
To: Tejas Joshi <tejasjoshi9673@gmail.com>
Cc: <gcc@gcc.gnu.org>, Martin Jambor <mjambor@suse.cz>
Subject: Re: About GSOC.
Date: Tue, 07 May 2019 21:01:00 -0000 [thread overview]
Message-ID: <alpine.DEB.2.21.1905072053300.19308@digraph.polyomino.org.uk> (raw)
In-Reply-To: <CACMrGjDFkKzH5Dwahe-yHF6crFLvsR-YQxNv8dJuNn2T=7Zg0g@mail.gmail.com>
On Wed, 8 May 2019, Tejas Joshi wrote:
> Hello.
> As per my understanding, 3.5 would be represented in GCC as follows :
> r->uexp = 2
> and
> r->sig[2] = 1110000....00 in binary 64 bit. (first 2 bits being 3 and
> following 1000....0 being 0.5, which later only happens for halfway cases)
> So, if we clear out the significand part and the immediate bit to the right
> which represent 0.5, the entire significand would become 0 due to bit-wise
> ANDing.
>
> > + tempsig[w] &= (((unsigned long)1 << ((n % HOST_BITS_PER_LONG) - 1)) -
> > 1);
> >
>
> That is what the following line intend to do. The clearing part would
> change the significand, that's why significand was copied to a temporary
That much is fine. My issues are two other things:
* The function would wrongly return true for 3, not just for 3.5, because
it never checks the bit representing 0.5. (If you don't care what it
returns for 3, see my previous point about every function needing a
comment defining its semantics. Without such a comment, I have to guess,
and my guess here is that the function should return true for 3.5 but
false for 3 and for 3.5000...0001.)
* The function would wrongly return true for 3.5000...0001, if there are
enough 0s that all those low bits in sig[2] are 0, but some low bits in
sig[1] or sig[0] are not 0.
And also:
* You should never need to modify parts of (a copy of) the significand in
place. Compare low parts of the significand (masked as needed) with 0.
If not 0, just return false. Likewise for comparing the 0.5 bit with 1.
It's not that copying and modifying in place results in incorrect logic,
it's simply excessively convoluted compared to things like:
if ((something & mask) != 0)
return false
(the function is probably twice as long as necessary because of that
copying).
> array for checking. This logic is inspired by the clear_significand_below
> function. Or isn't this the way it was meant to be implemented? Also, why
> unsigned long sig[SIGSZ] has to be an array?
What would it be other than an array? It can't be a single scalar because
floating-point significands may be longer than any supported integer type
on the host (remember the IEEE binary128 case). And if you made it a
sequence of individually named fields, a load of loops would need to be
manually unrolled, which would be much more error prone and hard to read.
--
Joseph S. Myers
joseph@codesourcery.com
next prev parent reply other threads:[~2019-05-07 21:01 UTC|newest]
Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CACMrGjCeaZ7EoYqjLYiAJXjOtOfpJNo9zcbWhfarfkiLMN8YYA@mail.gmail.com>
2018-10-13 4:43 ` Tejas Joshi
2018-10-23 10:47 ` Martin Jambor
2018-10-23 16:51 ` Joseph Myers
2018-11-16 16:50 ` Tejas Joshi
2018-11-16 19:00 ` Joseph Myers
2019-01-21 19:13 ` Tejas Joshi
2019-01-21 23:03 ` Joseph Myers
2019-01-23 2:55 ` Tejas Joshi
2019-01-23 4:00 ` Tejas Joshi
2019-01-23 17:37 ` Joseph Myers
2019-01-25 19:52 ` Tejas Joshi
2019-01-25 21:32 ` Joseph Myers
2019-01-28 17:00 ` Tejas Joshi
2019-02-04 14:39 ` Tejas Joshi
2019-02-04 15:06 ` Prathamesh Kulkarni
2019-02-04 15:56 ` Tejas Joshi
2019-02-04 16:44 ` Prathamesh Kulkarni
2019-02-04 17:22 ` Tejas Joshi
2019-02-24 12:05 ` Tejas Joshi
2019-03-30 11:24 ` Tejas Joshi
2019-04-01 19:53 ` Joseph Myers
2019-04-04 13:04 ` Tejas Joshi
2019-05-04 11:20 ` Tejas Joshi
2019-05-07 17:18 ` Joseph Myers
2019-05-07 19:38 ` Tejas Joshi
2019-05-07 21:01 ` Joseph Myers [this message]
2019-05-08 3:27 ` Tejas Joshi
2019-05-08 7:30 ` Tejas Joshi
2019-05-08 14:21 ` Tejas Joshi
2019-05-09 17:01 ` Joseph Myers
2019-05-09 16:55 ` Joseph Myers
2019-05-20 15:49 ` Martin Jambor
2019-05-20 21:48 ` Joseph Myers
2019-05-29 11:21 ` Tejas Joshi
2019-05-29 18:45 ` Tejas Joshi
2019-05-30 17:08 ` Martin Jambor
2019-05-30 21:38 ` Segher Boessenkool
2019-05-31 10:11 ` Martin Jambor
2019-05-31 10:28 ` Tejas Joshi
2019-06-03 16:38 ` Joseph Myers
2019-06-04 7:03 ` Tejas Joshi
2019-06-05 12:19 ` Tejas Joshi
2019-06-06 16:43 ` Joseph Myers
2019-06-09 4:48 ` Tejas Joshi
2019-06-10 20:26 ` Joseph Myers
2019-06-12 18:52 ` Tejas Joshi
2019-06-13 12:33 ` Tejas Joshi
2019-06-13 17:19 ` Expanding roundeven (Was: Re: About GSOC.) Martin Jambor
2019-06-13 21:16 ` Joseph Myers
2019-06-14 12:49 ` Tejas Joshi
2019-06-14 17:32 ` Martin Jambor
2019-06-17 7:50 ` Tejas Joshi
2019-06-17 17:15 ` Joseph Myers
2019-06-19 13:32 ` Tejas Joshi
2019-06-22 17:11 ` Tejas Joshi
2019-06-22 17:37 ` Jan Hubicka
2019-06-17 17:10 ` Joseph Myers
2019-05-31 11:13 ` About GSOC Segher Boessenkool
2019-05-31 11:16 ` Nathan Sidwell
2019-05-31 13:30 ` Eric Gallager
2019-06-03 9:37 ` Tejas Joshi
2019-06-06 16:56 ` Committing patches and other conventions (Was: Re: About GSOC) Martin Jambor
2019-06-09 4:57 ` Tejas Joshi
2019-06-12 13:48 ` Tejas Joshi
2019-06-13 17:02 ` Martin Jambor
2024-03-04 6:57 About gsoc mokshagnareddyc
2024-03-04 10:06 ` Jonathan Wakely
2024-03-05 2:02 ` Dave Blanchard
2024-03-05 9:31 ` Jonathan Wakely
2024-03-05 9:32 ` Jonathan Wakely
2024-03-11 1:17 ` Dave Blanchard
2024-03-11 9:08 ` Mark Wielaard
2024-03-07 12:26 ` Martin Jambor
2024-03-11 12:41 Julian Waters
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.21.1905072053300.19308@digraph.polyomino.org.uk \
--to=joseph@codesourcery.com \
--cc=gcc@gcc.gnu.org \
--cc=mjambor@suse.cz \
--cc=tejasjoshi9673@gmail.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).