From: Tejas Joshi <tejasjoshi9673@gmail.com>
To: gcc@gcc.gnu.org
Subject: Re: About GSOC.
Date: Mon, 04 Feb 2019 14:39:00 -0000 [thread overview]
Message-ID: <CACMrGjARaj3Dy-PzSvTehLzchbDEdE8mbD0rH9Ko6Eu3mFERGg@mail.gmail.com> (raw)
In-Reply-To: <CACMrGjDxpwLcVGgAwTDN=LojT01dUTK03dCH54CR1wYFPjGjAg@mail.gmail.com>
Hello.
I have implemented roundeven function in real.c as follows: (and
respective changes in real.h)
/* Round X to nearest even integer towards zero. */
void
real_roundeven (REAL_VALUE_TYPE *r, format_helper fmt,
const REAL_VALUE_TYPE *x)
{
REAL_VALUE_TYPE t;
do_fix_trunc (&t, x);
HOST_WIDE_INT i = real_to_integer (&t);
if(i % 2)
do_add (r, &t, &dconstm1, 0);
else
*r = t;
}
Although I cant get it to test like
int foo()
{
double x = __builtin_roundeven (3.5);
printf("%f",x);
return (int) x;
}
Because I do not know its dependencies through other files. I tried to
track them down by inspecting real_ceil function, but it also includes
other optimization procedures like folding. How do I know enough
declarations to be made in respective files?
Thanks.
-Tejas
On Mon, 28 Jan 2019 at 22:33, Tejas Joshi <tejasjoshi9673@gmail.com> wrote:
>
> Hello.
> Representations of real numbers in real.c are a little complex to
> understand right now for me. I am still trying to understand them and
> figure them out using gdb and cscope. Though conventions are given in
> comments in real.c, I will still be trying to figure it out. The
> equation and its bitwise representation is not pretty elaborated in
> any documentation I could find.
>
> x = s * b^e * \sum_{k=1}^p f_k * b^{-k}
>
> where
> s = sign (+- 1)
> b = base or radix, here always 2
> e = exponent
> p = precision (the number of base-b digits in the significand)
> f_k = the digits of the significand.
>
> In mean time, I've tried real_round function to work like roundeven. I
> will try to submit a clean patch along with roundeven implemented
> separately with changes like in builtins.def, adding cases, etc.
>
> void
> real_round (REAL_VALUE_TYPE *r, format_helper fmt,
> const REAL_VALUE_TYPE *x)
> {
> #if 0
> do_add (r, x, &dconsthalf, x->sign);
> do_fix_trunc (r, r);
> if (fmt)
> real_convert (r, fmt, r);
> #endif
> fprintf (stderr, "\nhere\n");
> real_value z;
> do_fix_trunc (&z, x);
> HOST_WIDE_INT i = real_to_integer (&z);
> fprintf (stderr, "\n i = %ld\n", i);
> if (i % 2)
> do_add (r, &z, &dconstm1, 0);
> else
> *r = z;
> }
>
> Thanks.
> -Tejas
>
> On Sat, 26 Jan 2019 at 03:02, Joseph Myers <joseph@codesourcery.com> wrote:
> >
> > On Sat, 26 Jan 2019, Tejas Joshi wrote:
> >
> > > function with byte-byte comparison which also include mpfr. (Correct
> > > me if I am wrong.) What is the significance of mpfr related to these
> > > internal representations?
> >
> > real.c provides a fixed-size representation of floating-point numbers that
> > allows for various non-IEEE formats supported by GCC, and also allows
> > functions from dfp.c to be used for decimal floating-point formats.
> >
> > MPFR is used in GCC to provide operations that are nontrivial to
> > implement, especially those that are nontrivial to implement in such a
> > fixed-size context. real.c operations wrap around MPFR ones where
> > appropriate, doing whatever's needed in cases where there are non-IEEE
> > semantics or sets of values.
> >
> > --
> > Joseph S. Myers
> > joseph@codesourcery.com
next prev parent reply other threads:[~2019-02-04 14:39 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 [this message]
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
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=CACMrGjARaj3Dy-PzSvTehLzchbDEdE8mbD0rH9Ko6Eu3mFERGg@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).