From: Tejas Joshi <tejasjoshi9673@gmail.com>
To: gcc@gcc.gnu.org
Cc: Martin Jambor <mjambor@suse.cz>, hubicka@ucw.cz, joseph@codesourcery.com
Subject: Re: About GSOC.
Date: Tue, 04 Jun 2019 07:03:00 -0000 [thread overview]
Message-ID: <CACMrGjAe0V2ei4A0QJvkEQ+OfT3SrVSdCs-mj_9WWxLButUXWg@mail.gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.21.1906031555010.14124@digraph.polyomino.org.uk>
Hello.
> NaN, and you should make sure it behaves accordingly. (If it should never
> be called for them, a gcc_assert would be appropriate.)
I can't find any documentation about how and when to use gcc_assert.
But I used it looking at the comment at its definition and locations
it is used, is this appropriate? Or is it supposed to be used before
calling the function? :
+bool
+is_even (REAL_VALUE_TYPE *r)
+{
+ /* The function is not supposed to use for Inf and NaN. */
+ gcc_assert (r->cl != rvc_inf);
+ gcc_assert (r->cl != rvc_nan);
> So n is the bit position, and w is the word position, of the bit with
> value 1; n-1 is the position of the bit with value 0.5.
> If n is a multiple of HOST_BITS_PER_LONG (that is, the bits with values
> 0.5 and 1 are in different words), this will incorrectly return false when
> the 0.5 bit is set.
I did not understand this. What is the bit with value 1?
But when n is a multiple of HOST_BITS_PER_LONG, the function was
computing value of w wrong (e.g. for number 2^63 + 0.5). At such time,
would the following improvisation be acceptable in is_halfway_below?
+bool
+is_halfway_below (const REAL_VALUE_TYPE *r)
+{
+ /* The function is not supposed to use for Inf and NaN. */
+ gcc_assert (r->cl != rvc_inf);
+ gcc_assert (r->cl != rvc_nan);
+ int i;
+
+ /* For numbers (-0.5,0) and (0,0.5). */
+ if (REAL_EXP (r) < 0)
+ return false;
+
+ else if (REAL_EXP (r) <= SIGNIFICAND_BITS)
+ {
+ unsigned int n = SIGNIFICAND_BITS - REAL_EXP (r);
+ int w = n / HOST_BITS_PER_LONG;
+
+ if (n % HOST_BITS_PER_LONG == 0)
+ {
+ if (w > 0)
+ w = w - 1;
+ else
+ w = 0;
+ }
+
+ for (i = 0; i < w; ++i)
+ {
+ if (r->sig[i] != 0)
+ return false;
+ }
Thanks.
On Mon, 3 Jun 2019 at 22:08, Joseph Myers <joseph@codesourcery.com> wrote:
>
> On Fri, 31 May 2019, Tejas Joshi wrote:
>
> > +/* Return true if integer part of R is even, else return false. */
> > +
> > +bool
> > +is_even (REAL_VALUE_TYPE *r)
> > +{
> > + if (REAL_EXP (r) <= 0)
> > + return false;
>
> But the integer part (truncation towards 0) of something in the interval
> (-1, 1) is of course even.
>
> > + else if (REAL_EXP (r) < SIGNIFICAND_BITS)
> > + {
> > + unsigned int n = SIGNIFICAND_BITS - REAL_EXP (r);
> > + int w = n / HOST_BITS_PER_LONG;
> > +
> > + unsigned long num = ((unsigned long)1 << (n % HOST_BITS_PER_LONG));
> > +
> > + if ((r->sig[w] & num) == 0)
> > + return true;
> > + }
> > + return false;
> > +}
>
> Suppose REAL_EXP (r) == SIGNIFICAND_BITS. Then you still need to check
> the low bit in that case.
>
> Suppose REAL_EXP (r) > SIGNIFICAND_BITS. Then the number is definitely
> even, so you should return true, not false.
>
> The comment on this function needs to define what it does for infinity /
> NaN, and you should make sure it behaves accordingly. (If it should never
> be called for them, a gcc_assert would be appropriate.)
>
> What does this function do for zero? It should, of course, return that it
> is even.
>
> > +/* Return true if R is halfway between two integers, else return false. */
>
> Again, define what this does for infinity / NaN and make sure it behaves
> accordingly.
>
> > +bool
> > +is_halfway_below (const REAL_VALUE_TYPE *r)
> > +{
> > + if (REAL_EXP (r) < 0)
> > + return false;
> > +
> > + if (REAL_EXP (r) == 0)
> > + {
> > + unsigned long temp = ((unsigned long)1 << 63);
>
> unsigned long might be 32-bit; you can't assume it's 64-bit. You may mean
> (HOST_BITS_PER_LONG - 1) instead of 63.
>
> > + if (((r->sig[SIGSZ-1] & temp) != 0) && ((r->sig[SIGSZ-1] & (temp-1)) == 0))
> > + return true;
> > + else
> > + return false;
>
> This appears only to be checking the high word, not lower bits.
>
> > + else if (REAL_EXP (r) < SIGNIFICAND_BITS)
> > + {
> > + unsigned int n = SIGNIFICAND_BITS - REAL_EXP (r);
> > + int i, w = n / HOST_BITS_PER_LONG;
>
> So n is the bit position, and w is the word position, of the bit with
> value 1; n-1 is the position of the bit with value 0.5.
>
> > + for (i = 0; i < w; ++i)
> > + {
> > + if (r->sig[i] != 0)
> > + return false;
> > + }
>
> If n is a multiple of HOST_BITS_PER_LONG (that is, the bits with values
> 0.5 and 1 are in different words), this will incorrectly return false when
> the 0.5 bit is set.
>
> > + unsigned long num = ((unsigned long)1 << ((n - 1) % HOST_BITS_PER_LONG));
> > +
> > + if (((r->sig[w] & num) != 0) && ((r->sig[w] & (num-1)) == 0))
> > + return true;
>
> And this also needs updating to handle the case where 0.5 and 1 are in
> different words correctly; currently it's checking bits that are all one
> word too high. It's possible that for both issues, you want w to be the
> word with the 0.5 bit, not the word with the 1 bit.
>
> For all the above, please add appropriate tests in the testsuite (for
> example, where 0.5 and 1 are in different words and the above would have
> produced incorrect results).
>
> --
> Joseph S. Myers
> joseph@codesourcery.com
next prev parent reply other threads:[~2019-06-04 7:03 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
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 [this message]
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=CACMrGjAe0V2ei4A0QJvkEQ+OfT3SrVSdCs-mj_9WWxLButUXWg@mail.gmail.com \
--to=tejasjoshi9673@gmail.com \
--cc=gcc@gcc.gnu.org \
--cc=hubicka@ucw.cz \
--cc=joseph@codesourcery.com \
--cc=mjambor@suse.cz \
/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).