From: Tejas Joshi <tejasjoshi9673@gmail.com>
To: gcc@gcc.gnu.org
Subject: Re: About GSOC.
Date: Wed, 08 May 2019 03:27:00 -0000 [thread overview]
Message-ID: <CACMrGjBV5PcUU7_yzpko1RrqxGmvMKO8e07mJ5opCLFpJ1pdOg@mail.gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.21.1905072053300.19308@digraph.polyomino.org.uk>
I should have taken all the test cases into consideration. Fool of me. I
will try to make changes taking all the test cases into consideration along
with the testsuite.
Thanks.
On Wed, 8 May 2019 at 02:31, Joseph Myers <joseph@codesourcery.com> wrote:
> 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-08 3:27 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
2019-05-08 3:27 ` Tejas Joshi [this message]
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=CACMrGjBV5PcUU7_yzpko1RrqxGmvMKO8e07mJ5opCLFpJ1pdOg@mail.gmail.com \
--to=tejasjoshi9673@gmail.com \
--cc=gcc@gcc.gnu.org \
/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).