About GSOC.

About GSOC.

[Tejas Joshi]

Hello.
I reached asking about GCC GSoC project about adding and
folding functions
like roundeven. I could not apply for the idea this year but
interested in the peoject and
really hoping it would be carry forwarded. Since I've been studying
source code and about the project, I think working on this from now
would give me some heads up and hands on with the source code.

I did study <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1778.pdf>.
It does tell that roundeven rounds its argument to nearest integral
ties to even (least significant bit 0) returning integral value
provided that the resulting value is exact.
So, for the start, I'd be implementing this functionality for roundeven.
As ita said in earlier mails that, similar functions like
real_ceil are implemented
in real.c and are used in fold-const-call.c.
Roundeven might be implemented in similar way. Is it built-in
(internal) function means not to be exposed to end-user?
Studying some functions like real_ceil, there are call checks
(flag_errno_math) so I believe similar would be needed for roundeven.

In real.c where real_ceil is implemented, there are function calls
(and implementations) like do_fix_trunc which also then call functions
like decimal_do_dix_trunc (maybe the main functionality of
do_fix_trunc?, other are just checks, like NaN or qNaN). I did not
understand these functions really and what do they do. Also I did not
understand the structure of REAL_VALUE_TYPE (r->cl and etc?)

Also when does the real.c and fold-const-call.c comes in picture in
the flow of GCC (Is it for GIMPLE level instruction selection (gimple
stmnt to corresponding rtl instruction))?
Thanks.

Regards,
-Tejas

Re: About GSOC.

[Martin Jambor]

Hi Joseph,

this seems related to your proposal GSoC proposal in the beginning
of this year.  Do you have any comments about Tejas's idea?  Do you
think this would be a good (part of) a GSoC project next year?

Thanks a lot,

Martin


On Sat, Oct 13 2018, Tejas Joshi wrote:
> Hello.
> I reached asking about GCC GSoC project about adding and
> folding functions
> like roundeven. I could not apply for the idea this year but
> interested in the peoject and
> really hoping it would be carry forwarded. Since I've been studying
> source code and about the project, I think working on this from now
> would give me some heads up and hands on with the source code.
>
> I did study <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1778.pdf>.
> It does tell that roundeven rounds its argument to nearest integral
> ties to even (least significant bit 0) returning integral value
> provided that the resulting value is exact.
> So, for the start, I'd be implementing this functionality for roundeven.
> As ita said in earlier mails that, similar functions like
> real_ceil are implemented
> in real.c and are used in fold-const-call.c.
> Roundeven might be implemented in similar way. Is it built-in
> (internal) function means not to be exposed to end-user?
> Studying some functions like real_ceil, there are call checks
> (flag_errno_math) so I believe similar would be needed for roundeven.
>
> In real.c where real_ceil is implemented, there are function calls
> (and implementations) like do_fix_trunc which also then call functions
> like decimal_do_dix_trunc (maybe the main functionality of
> do_fix_trunc?, other are just checks, like NaN or qNaN). I did not
> understand these functions really and what do they do. Also I did not
> understand the structure of REAL_VALUE_TYPE (r->cl and etc?)
>
> Also when does the real.c and fold-const-call.c comes in picture in
> the flow of GCC (Is it for GIMPLE level instruction selection (gimple
> stmnt to corresponding rtl instruction))?
> Thanks.
>
> Regards,
> -Tejas

Re: About GSOC.

[Joseph Myers]

On Tue, 23 Oct 2018, Martin Jambor wrote:

> Hi Joseph,
> 
> this seems related to your proposal GSoC proposal in the beginning
> of this year.  Do you have any comments about Tejas's idea?  Do you

My proposal was designed so that it would be possible to do some small 
piece, that is useful by itself, and so learn about some parts of the 
compiler, and then go onto another piece, and so learn about other parts 
of the compiler - as there are lots of separate pieces that are related, 
but each useful by itself as a contribution to GCC.  The parts Tejas 
refers to are good pieces to be looking at for one such piece (roundeven 
folding for constant arguments) (along with e.g. builtins.def to define 
the built-in functions).

> think this would be a good (part of) a GSoC project next year?

If a suitable mentor is available for it next year.

> > It does tell that roundeven rounds its argument to nearest integral
> > ties to even (least significant bit 0) returning integral value
> > provided that the resulting value is exact.
> > So, for the start, I'd be implementing this functionality for roundeven.
> > As ita said in earlier mails that, similar functions like
> > real_ceil are implemented
> > in real.c and are used in fold-const-call.c.
> > Roundeven might be implemented in similar way. Is it built-in
> > (internal) function means not to be exposed to end-user?
> > Studying some functions like real_ceil, there are call checks
> > (flag_errno_math) so I believe similar would be needed for roundeven.

The expectation for this part of the project would be that calls to both 
__builtin_roundeven and roundeven (and similar functions with f, l, f128 
etc. suffixes) would be folded when the arguments are constants (both 
direct calls with constants such as roundeven (2.5), and cases where 
GIMPLE optimization passes propagate a constant into the call, such as 
"double d = 2.5; return roundeven (d);").  This of course involves various 
internal functions in the compiler to implement that.

If you compile code such as

double
f (void)
{
  double d = 2.5;
  return ceil (d);
}

with -O2 -S -fdump-tree-all, you can look at the generated dump files to 
see which optimization pass the folding into constant 3.0 occurs in.  
Looking at such dumps is an important way of finding your way around the 
optimization passes in the compiler.

> > In real.c where real_ceil is implemented, there are function calls
> > (and implementations) like do_fix_trunc which also then call functions
> > like decimal_do_dix_trunc (maybe the main functionality of
> > do_fix_trunc?, other are just checks, like NaN or qNaN). I did not

You can ignore any cases for decimal floating-point values (do gcc_assert 
(!r->decimal)), given that the project does not involve adding any decimal 
floating-point built-in functions.  That means you should instead 
understand REAL_EXP and the significands of floating-point values, and 
what functions such as clear_significand_below and test_significand_bit 
do, because you'll need to write your own logic like that in do_fix_trunc, 
with appropriate cases for whether the bits with values 0.5 and below form 
part of the significand.

> > understand these functions really and what do they do. Also I did not
> > understand the structure of REAL_VALUE_TYPE (r->cl and etc?)

I suggest looking more closely at the definition of cl in real.h.  It's 
true that it doesn't have a comment specifying its semantics directly, but 
the /* ENUM_BITFIELD (real_value_class) */ should give a strong hint, 
along with the values that are stored in that field.  By looking at how 
all the fields in real_value are used, you should be able to deduce their 
semantics, and then send a GCC patch that adds a comment to each field 
with a more detailed description of its semantics, which would be a useful 
contribution by itself to help people reading real.c code in future.

(struct real_format has more detailed comments on some of the fields.  I 
suggest using those as a model for the comments that ought to be written 
for the fields of struct real_value.)

> > Also when does the real.c and fold-const-call.c comes in picture in
> > the flow of GCC (Is it for GIMPLE level instruction selection (gimple
> > stmnt to corresponding rtl instruction))?

The code you're looking at is used in GIMPLE optimizations, and possibly 
folding before GIMPLE.

Converting roundeven calls with non-constant arguments to appropriate 
instructions (for processors that have them, e.g. x86 with SSE 4.1 and 
later) is also useful, and will involve changes to optabs.def, 
internal-fn.def and target .md files.  But I'd advise doing one 
self-contained piece first (such as the folding for constant arguments) 
before moving on to others (such as generating appropriate instructions 
for the case of non-constant arguments).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: About GSOC.

[Tejas Joshi]

About roundeven, there might be need to add case to
expand_builtin_int_roundingfn similar to
ceil, for expansion.
But how is round() expanded since there's no
entry for it in expand_builtin_int_roundingfn ?

Also, is it right to have an added case for roundeven in convert.c
along CASE_FLT_FN (BUILT_IN_ROUND)
in convert_to_integer_1?

Thanks.
On Tue, 23 Oct 2018 at 22:21, Joseph Myers <joseph@codesourcery.com> wrote:
>
> On Tue, 23 Oct 2018, Martin Jambor wrote:
>
> > Hi Joseph,
> >
> > this seems related to your proposal GSoC proposal in the beginning
> > of this year.  Do you have any comments about Tejas's idea?  Do you
>
> My proposal was designed so that it would be possible to do some small
> piece, that is useful by itself, and so learn about some parts of the
> compiler, and then go onto another piece, and so learn about other parts
> of the compiler - as there are lots of separate pieces that are related,
> but each useful by itself as a contribution to GCC.  The parts Tejas
> refers to are good pieces to be looking at for one such piece (roundeven
> folding for constant arguments) (along with e.g. builtins.def to define
> the built-in functions).
>
> > think this would be a good (part of) a GSoC project next year?
>
> If a suitable mentor is available for it next year.
>
> > > It does tell that roundeven rounds its argument to nearest integral
> > > ties to even (least significant bit 0) returning integral value
> > > provided that the resulting value is exact.
> > > So, for the start, I'd be implementing this functionality for roundeven.
> > > As ita said in earlier mails that, similar functions like
> > > real_ceil are implemented
> > > in real.c and are used in fold-const-call.c.
> > > Roundeven might be implemented in similar way. Is it built-in
> > > (internal) function means not to be exposed to end-user?
> > > Studying some functions like real_ceil, there are call checks
> > > (flag_errno_math) so I believe similar would be needed for roundeven.
>
> The expectation for this part of the project would be that calls to both
> __builtin_roundeven and roundeven (and similar functions with f, l, f128
> etc. suffixes) would be folded when the arguments are constants (both
> direct calls with constants such as roundeven (2.5), and cases where
> GIMPLE optimization passes propagate a constant into the call, such as
> "double d = 2.5; return roundeven (d);").  This of course involves various
> internal functions in the compiler to implement that.
>
> If you compile code such as
>
> double
> f (void)
> {
>   double d = 2.5;
>   return ceil (d);
> }
>
> with -O2 -S -fdump-tree-all, you can look at the generated dump files to
> see which optimization pass the folding into constant 3.0 occurs in.
> Looking at such dumps is an important way of finding your way around the
> optimization passes in the compiler.
>
> > > In real.c where real_ceil is implemented, there are function calls
> > > (and implementations) like do_fix_trunc which also then call functions
> > > like decimal_do_dix_trunc (maybe the main functionality of
> > > do_fix_trunc?, other are just checks, like NaN or qNaN). I did not
>
> You can ignore any cases for decimal floating-point values (do gcc_assert
> (!r->decimal)), given that the project does not involve adding any decimal
> floating-point built-in functions.  That means you should instead
> understand REAL_EXP and the significands of floating-point values, and
> what functions such as clear_significand_below and test_significand_bit
> do, because you'll need to write your own logic like that in do_fix_trunc,
> with appropriate cases for whether the bits with values 0.5 and below form
> part of the significand.
>
> > > understand these functions really and what do they do. Also I did not
> > > understand the structure of REAL_VALUE_TYPE (r->cl and etc?)
>
> I suggest looking more closely at the definition of cl in real.h.  It's
> true that it doesn't have a comment specifying its semantics directly, but
> the /* ENUM_BITFIELD (real_value_class) */ should give a strong hint,
> along with the values that are stored in that field.  By looking at how
> all the fields in real_value are used, you should be able to deduce their
> semantics, and then send a GCC patch that adds a comment to each field
> with a more detailed description of its semantics, which would be a useful
> contribution by itself to help people reading real.c code in future.
>
> (struct real_format has more detailed comments on some of the fields.  I
> suggest using those as a model for the comments that ought to be written
> for the fields of struct real_value.)
>
> > > Also when does the real.c and fold-const-call.c comes in picture in
> > > the flow of GCC (Is it for GIMPLE level instruction selection (gimple
> > > stmnt to corresponding rtl instruction))?
>
> The code you're looking at is used in GIMPLE optimizations, and possibly
> folding before GIMPLE.
>
> Converting roundeven calls with non-constant arguments to appropriate
> instructions (for processors that have them, e.g. x86 with SSE 4.1 and
> later) is also useful, and will involve changes to optabs.def,
> internal-fn.def and target .md files.  But I'd advise doing one
> self-contained piece first (such as the folding for constant arguments)
> before moving on to others (such as generating appropriate instructions
> for the case of non-constant arguments).
>
> --
> Joseph S. Myers
> joseph@codesourcery.com

Re: About GSOC.

[Joseph Myers]

On Fri, 16 Nov 2018, Tejas Joshi wrote:

> About roundeven, there might be need to add case to
> expand_builtin_int_roundingfn similar to
> ceil, for expansion.
> But how is round() expanded since there's no
> entry for it in expand_builtin_int_roundingfn ?

Please see the comment above expand_builtin_int_roundingfn, and that above 
expand_builtin_int_roundingfn_2, which handle different sets of functions.  
Those functions are of no relevance to adding support for built-in 
roundeven.  (They might be of relevance to support for built-in fromfp 
functions, depending on whether the detailed semantics allows 
casts-to-integer of calls to other functions to be converted into calls to 
the fromfp functions.  But I don't think inventing __builtin_lroundeven 
would be appropriate.)

> Also, is it right to have an added case for roundeven in convert.c
> along CASE_FLT_FN (BUILT_IN_ROUND)
> in convert_to_integer_1?

Not until doing things with fromfp functions.  There is no lroundeven (for 
example) in TS 18661-1.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: About GSOC.

[Tejas Joshi]

Hello.
I've been inactive for some time due to exams but I have been studying
the real.h and IEEE 754 floating point format as far as I could.

> floating-point built-in functions.  That means you should instead
> understand REAL_EXP and the significands of floating-point values, and

In GCC's representation of REAL or may I say floating point numbers
(including decimal floating point values), values are defined in
macros in real.h like

#define SIGNIFICAND_BITS    (128 + HOST_BITS_PER_LONG)           (why
128+host-bits_per_long?, even quad precision has total 128 bits.)
#define EXP_BITS        (32 - 6)

This include EXP_BITS resolving to I believe, exponent bits and macro
REAL_EXP to exponent value which determines the value of the exponent
of REAL r, which is passed in real.c with mathematical calculations
like XOR and shifting (multiplication by 2) though the operation is
unclear. (Adding comment to these will also be helpful in a patch for
me!)

> true that it doesn't have a comment specifying its semantics directly, but
> the /* ENUM_BITFIELD (real_value_class) */ should give a strong hint,
> along with the values that are stored in that field.  By looking at how

As far as the struct real_value is concerned, I believe the values
associated with decimal, sign, etc are used for handling switch
conditions in functions of real.c and then carrying out specific
functions like clear_signifcand_below.
Relating to enumeration real_value_class, it determines the type of
the number like nan or normal in the functions. Though, attributes of
struct real_value are pretty unclear to me regarding to the number it
represents. (Am I right within this grasp?).
Thank you.

Regards,
-Tejas
<div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr"
class="gmail-m_1121032510469528392gmail_attr">On Fri, 16 Nov 2018 at
22:20, Joseph Myers &lt;<a href="mailto:joseph@codesourcery.com"
target="_blank">joseph@codesourcery.com</a>&gt;
wrote:<br></div><blockquote class="gmail_quote" style="margin: 0px 0px
0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left:
1ex;">On Fri, 16 Nov 2018, Tejas Joshi wrote:<br>
<br>
&gt; About roundeven, there might be need to add case to<br>
&gt; expand_builtin_int_roundingfn similar to<br>
&gt; ceil, for expansion.<br>
&gt; But how is round() expanded since there's no<br>
&gt; entry for it in expand_builtin_int_roundingfn ?<br>
<br>
Please see the comment above expand_builtin_int_roundingfn, and that above <br>
expand_builtin_int_roundingfn_<wbr>2, which handle different sets of
functions.&nbsp; <br>
Those functions are of no relevance to adding support for built-in <br>
roundeven.&nbsp; (They might be of relevance to support for built-in fromfp <br>
functions, depending on whether the detailed semantics allows <br>
casts-to-integer of calls to other functions to be converted into calls to <br>
the fromfp functions.&nbsp; But I don't think inventing
__builtin_lroundeven <br>
would be appropriate.)<br>
<br>
&gt; Also, is it right to have an added case for roundeven in convert.c<br>
&gt; along CASE_FLT_FN (BUILT_IN_ROUND)<br>
&gt; in convert_to_integer_1?<br>
<br>
Not until doing things with fromfp functions.&nbsp; There is no
lroundeven (for <br>
example) in TS 18661-1.<br>
<br>
-- <br>
Joseph S. Myers<br>
<a href="mailto:joseph@codesourcery.com"
target="_blank">joseph@codesourcery.com</a><br>
</blockquote></div>

Re: About GSOC.

[Joseph Myers]

On Tue, 22 Jan 2019, Tejas Joshi wrote:

> the number like nan or normal in the functions. Though, attributes of
> struct real_value are pretty unclear to me regarding to the number it
> represents. (Am I right within this grasp?).

It may be helpful to run the compiler under a debugger to examine how 
particular real numbers are represented in real_value - that should help 
answer questions such as what endianness is used for the significand, or 
whether floating point values with a given exponent are in the range 
[2^EXP, 2^(EXP+1)) or [2^(EXP-1), 2^EXP), where conventions commonly 
differ.  (It's the unoptimized, stage1 cc1 that should be run under a 
debugger.  See <https://gcc.gnu.org/wiki/DebuggingGCC> for more details.)

And of course contribute comments in real.h once you've determined the 
answers - because there are such areas where conventions about 
representation of floating-point numbers commonly differ, it's 
particularly valuable to have such comments because even someone familiar 
with floating-point won't know which convention has been chosen by this 
code in GCC.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: About GSOC.

[Tejas Joshi]

> differ.  (It's the unoptimized, stage1 cc1 that should be run under a
> debugger.  See <https://gcc.gnu.org/wiki/DebuggingGCC> for more details.)

Hello.
I normally configure GCC by (as you told)

/configure --enable-languages=c,c++ --disable-bootstrap --disable-multilib

And further as told in <https://gcc.gnu.org/wiki/DebuggingGCC>

make STAGE1_CXXFLAGS="-g -O0" all-stage1

but instead of -g to use -g3 is suggested for making macros debuggable
and then use GDB.
May I proceed the same?

On Tue, 22 Jan 2019 at 04:33, Joseph Myers <joseph@codesourcery.com> wrote:
>
> On Tue, 22 Jan 2019, Tejas Joshi wrote:
>
> > the number like nan or normal in the functions. Though, attributes of
> > struct real_value are pretty unclear to me regarding to the number it
> > represents. (Am I right within this grasp?).
>
> It may be helpful to run the compiler under a debugger to examine how
> particular real numbers are represented in real_value - that should help
> answer questions such as what endianness is used for the significand, or
> whether floating point values with a given exponent are in the range
> [2^EXP, 2^(EXP+1)) or [2^(EXP-1), 2^EXP), where conventions commonly
> differ.  (It's the unoptimized, stage1 cc1 that should be run under a
> debugger.  See <https://gcc.gnu.org/wiki/DebuggingGCC> for more details.)
>
> And of course contribute comments in real.h once you've determined the
> answers - because there are such areas where conventions about
> representation of floating-point numbers commonly differ, it's
> particularly valuable to have such comments because even someone familiar
> with floating-point won't know which convention has been chosen by this
> code in GCC.
>
> --
> Joseph S. Myers
> joseph@codesourcery.com

Re: About GSOC.

[Tejas Joshi]

I built gcc as a debuggable compiler as given using -g3. I am using
gdb and loaded the cc1 using:

gdb --args cc1

with output as:

Successfully loaded GDB hooks for GCC

But I really dont know how to inspect a file like real.h (real_value)/real.c?

Thanks.
-Tejas

On Wed, 23 Jan 2019 at 08:28, Tejas Joshi <tejasjoshi9673@gmail.com> wrote:
>
> > differ.  (It's the unoptimized, stage1 cc1 that should be run under a
> > debugger.  See <https://gcc.gnu.org/wiki/DebuggingGCC> for more details.)
>
> Hello.
> I normally configure GCC by (as you told)
>
> /configure --enable-languages=c,c++ --disable-bootstrap --disable-multilib
>
> And further as told in <https://gcc.gnu.org/wiki/DebuggingGCC>
>
> make STAGE1_CXXFLAGS="-g -O0" all-stage1
>
> but instead of -g to use -g3 is suggested for making macros debuggable
> and then use GDB.
> May I proceed the same?
>
> On Tue, 22 Jan 2019 at 04:33, Joseph Myers <joseph@codesourcery.com> wrote:
> >
> > On Tue, 22 Jan 2019, Tejas Joshi wrote:
> >
> > > the number like nan or normal in the functions. Though, attributes of
> > > struct real_value are pretty unclear to me regarding to the number it
> > > represents. (Am I right within this grasp?).
> >
> > It may be helpful to run the compiler under a debugger to examine how
> > particular real numbers are represented in real_value - that should help
> > answer questions such as what endianness is used for the significand, or
> > whether floating point values with a given exponent are in the range
> > [2^EXP, 2^(EXP+1)) or [2^(EXP-1), 2^EXP), where conventions commonly
> > differ.  (It's the unoptimized, stage1 cc1 that should be run under a
> > debugger.  See <https://gcc.gnu.org/wiki/DebuggingGCC> for more details.)
> >
> > And of course contribute comments in real.h once you've determined the
> > answers - because there are such areas where conventions about
> > representation of floating-point numbers commonly differ, it's
> > particularly valuable to have such comments because even someone familiar
> > with floating-point won't know which convention has been chosen by this
> > code in GCC.
> >
> > --
> > Joseph S. Myers
> > joseph@codesourcery.com

Re: About GSOC.

[Joseph Myers]

On Wed, 23 Jan 2019, Tejas Joshi wrote:

> But I really dont know how to inspect a file like real.h (real_value)/real.c?

Use cc1 to build a test program with selected floating-point constants in 
it.  Set breakpoints on appropriate functions in real.c (e.g. related to 
converting strings for real constants into the internal representation).  
Look at the representation produced for those constants to determine the 
particular conventions being used.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: About GSOC.

[Tejas Joshi]

It took some time to get know using GDB, but upto some end I got it to
work. The enum real_value_class is used to classify the number into
zero, normal, infinity and NaN.
This class is represented by r->cl in real_value and values in struct
real_value are used as flags or representations while string to real
conversion (real_from_string) in real.c and other functions. The
decimal/hex string value is converted into real in real_from_string
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?
Thanks.

-Tejas

On Wed, 23 Jan 2019 at 23:06, Joseph Myers <joseph@codesourcery.com> wrote:
>
> On Wed, 23 Jan 2019, Tejas Joshi wrote:
>
> > But I really dont know how to inspect a file like real.h (real_value)/real.c?
>
> Use cc1 to build a test program with selected floating-point constants in
> it.  Set breakpoints on appropriate functions in real.c (e.g. related to
> converting strings for real constants into the internal representation).
> Look at the representation produced for those constants to determine the
> particular conventions being used.
>
> --
> Joseph S. Myers
> joseph@codesourcery.com

Re: About GSOC.

[Joseph Myers]

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

Re: About GSOC.

[Tejas Joshi]

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

Re: About GSOC.

[Tejas Joshi]

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

Re: About GSOC.

[Prathamesh Kulkarni]

On Mon, 4 Feb 2019 at 20:10, Tejas Joshi <tejasjoshi9673@gmail.com> wrote:
>
> Hello.
> I have implemented roundeven function in real.c as follows: (and
> respective changes in real.h)
It's a better idea to include all changes in patch instead of copy-pasting.
Use the command:
git diff > patch.diff
which will create a file called "patch.diff" containing the changes
and send it as an attachment.
>
> /* 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?
Did you add an entry for roundeven in builtins.def ?

Thanks,
Prathamesh
>
> 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

Re: About GSOC.

[Tejas Joshi]

[-- Attachment #1: Type: text/plain, Size: 4338 bytes --]

Thanks.
> Did you add an entry for roundeven in builtins.def ?
Yes, I did.

Find here the attached patch.diff for which I did the changes to
implement roundeven. There might be some unnecessary changes and some
necessary changes which have not been made.

Regards,
-Tejas

On Mon, 4 Feb 2019 at 20:36, Prathamesh Kulkarni
<prathamesh.kulkarni@linaro.org> wrote:
>
> On Mon, 4 Feb 2019 at 20:10, Tejas Joshi <tejasjoshi9673@gmail.com> wrote:
> >
> > Hello.
> > I have implemented roundeven function in real.c as follows: (and
> > respective changes in real.h)
> It's a better idea to include all changes in patch instead of copy-pasting.
> Use the command:
> git diff > patch.diff
> which will create a file called "patch.diff" containing the changes
> and send it as an attachment.
> >
> > /* 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?
> Did you add an entry for roundeven in builtins.def ?
>
> Thanks,
> Prathamesh
> >
> > 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

[-- Attachment #2: patch.diff --]
[-- Type: text/x-patch, Size: 3352 bytes --]

diff --git a/gcc/builtins.c b/gcc/builtins.c
index 25e01e4092b..25282d2122d 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -2067,6 +2067,7 @@ mathfn_built_in_2 (tree type, combined_fn fn)
     CASE_MATHFN (REMQUO)
     CASE_MATHFN_FLOATN (RINT)
     CASE_MATHFN_FLOATN (ROUND)
+    CASE_MATHFN_FLOATN (ROUNDEVEN)
     CASE_MATHFN (SCALB)
     CASE_MATHFN (SCALBLN)
     CASE_MATHFN (SCALBN)
diff --git a/gcc/builtins.def b/gcc/builtins.def
index ef89729fd0c..f1b6830a49c 100644
--- a/gcc/builtins.def
+++ b/gcc/builtins.def
@@ -308,6 +308,7 @@ DEF_C99_BUILTIN        (BUILT_IN_CBRT, "cbrt", BT_FN_DOUBLE_DOUBLE, ATTR_MATHFN_
 DEF_C99_BUILTIN        (BUILT_IN_CBRTF, "cbrtf", BT_FN_FLOAT_FLOAT, ATTR_MATHFN_FPROUNDING)
 DEF_C99_BUILTIN        (BUILT_IN_CBRTL, "cbrtl", BT_FN_LONGDOUBLE_LONGDOUBLE, ATTR_MATHFN_FPROUNDING)
 DEF_LIB_BUILTIN        (BUILT_IN_CEIL, "ceil", BT_FN_DOUBLE_DOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
+DEF_EXT_LIB_BUILTIN    (BUILT_IN_ROUNDEVEN, "roundeven", BT_FN_DOUBLE_DOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_C99_C90RES_BUILTIN (BUILT_IN_CEILF, "ceilf", BT_FN_FLOAT_FLOAT, ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_C99_C90RES_BUILTIN (BUILT_IN_CEILL, "ceill", BT_FN_LONGDOUBLE_LONGDOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
 #define CEIL_TYPE(F) BT_FN_##F##_##F
diff --git a/gcc/internal-fn.def b/gcc/internal-fn.def
index cda314e1121..b89918815f9 100644
--- a/gcc/internal-fn.def
+++ b/gcc/internal-fn.def
@@ -224,6 +224,7 @@ DEF_INTERNAL_FLT_FLOATN_FN (FLOOR, ECF_CONST, floor, unary)
 DEF_INTERNAL_FLT_FLOATN_FN (NEARBYINT, ECF_CONST, nearbyint, unary)
 DEF_INTERNAL_FLT_FLOATN_FN (RINT, ECF_CONST, rint, unary)
 DEF_INTERNAL_FLT_FLOATN_FN (ROUND, ECF_CONST, round, unary)
+DEF_INTERNAL_FLT_FLOATN_FN (ROUNDEVEN, ECF_CONST, roundeven, unary)
 DEF_INTERNAL_FLT_FLOATN_FN (TRUNC, ECF_CONST, btrunc, unary)
 
 /* Binary math functions.  */
diff --git a/gcc/optabs.def b/gcc/optabs.def
index 5a67f5eed5e..eb9e22acd8f 100644
--- a/gcc/optabs.def
+++ b/gcc/optabs.def
@@ -267,6 +267,7 @@ OPTAB_D (fnms_optab, "fnms$a4")
 
 OPTAB_D (rint_optab, "rint$a2")
 OPTAB_D (round_optab, "round$a2")
+OPTAB_D (roundeven_optab, "roundeven$a2")
 OPTAB_D (floor_optab, "floor$a2")
 OPTAB_D (ceil_optab, "ceil$a2")
 OPTAB_D (btrunc_optab, "btrunc$a2")
diff --git a/gcc/real.c b/gcc/real.c
index f822ae82d61..9c57f50e8fc 100644
--- a/gcc/real.c
+++ b/gcc/real.c
@@ -5004,10 +5006,39 @@ void
+/* 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);
+  fprintf (stderr, "\nhere\n");
+  fprintf (stderr, "\n i = %ld\n", i);
+  if(i % 2)
+    do_add (r, &t, &dconstm1, 0);
+  else
+    *r = t;
 }
 
 /* Set the sign of R to the sign of X.  */
diff --git a/gcc/real.h b/gcc/real.h
index 0ce42565708..10898eae79e 100644
--- a/gcc/real.h
+++ b/gcc/real.h
@@ -499,6 +499,8 @@ extern void real_ceil (REAL_VALUE_TYPE *, format_helper,
 		       const REAL_VALUE_TYPE *);
 extern void real_round (REAL_VALUE_TYPE *, format_helper,
 			const REAL_VALUE_TYPE *);
+extern void real_roundeven (REAL_VALUE_TYPE *, format_helper,
+      const REAL_VALUE_TYPE *);
 
 /* Set the sign of R to the sign of X.  */
 extern void real_copysign (REAL_VALUE_TYPE *, const REAL_VALUE_TYPE *);

 

Re: About GSOC.

[Prathamesh Kulkarni]

On Mon, 4 Feb 2019 at 21:27, Tejas Joshi <tejasjoshi9673@gmail.com> wrote:
>
> Thanks.
> > Did you add an entry for roundeven in builtins.def ?
> Yes, I did.
>
> Find here the attached patch.diff for which I did the changes to
> implement roundeven. There might be some unnecessary changes and some
> necessary changes which have not been made.
You haven't called roundeven() in the patch. You'll need to add an
entry in fold_const_call_ss()
similar to real_ceil, and probably in other places too.

Thanks,
Prathamesh
>
> Regards,
> -Tejas
>
> On Mon, 4 Feb 2019 at 20:36, Prathamesh Kulkarni
> <prathamesh.kulkarni@linaro.org> wrote:
> >
> > On Mon, 4 Feb 2019 at 20:10, Tejas Joshi <tejasjoshi9673@gmail.com> wrote:
> > >
> > > Hello.
> > > I have implemented roundeven function in real.c as follows: (and
> > > respective changes in real.h)
> > It's a better idea to include all changes in patch instead of copy-pasting.
> > Use the command:
> > git diff > patch.diff
> > which will create a file called "patch.diff" containing the changes
> > and send it as an attachment.
> > >
> > > /* 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?
> > Did you add an entry for roundeven in builtins.def ?
> >
> > Thanks,
> > Prathamesh
> > >
> > > 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

Re: About GSOC.

[Tejas Joshi]

[-- Attachment #1: Type: text/plain, Size: 5492 bytes --]

Hi.
Although now, I am unable to build the compiler.
The build exited returning status as:

DEF_INTERNAL_FLT_FN (ROUNDEVEN) has no associated built-in functions

I have added the entry in fold_const_call_ss() and do not find any
other place to add the case.
Here is the latest patch.

On Mon, 4 Feb 2019 at 22:14, Prathamesh Kulkarni
<prathamesh.kulkarni@linaro.org> wrote:
>
> On Mon, 4 Feb 2019 at 21:27, Tejas Joshi <tejasjoshi9673@gmail.com> wrote:
> >
> > Thanks.
> > > Did you add an entry for roundeven in builtins.def ?
> > Yes, I did.
> >
> > Find here the attached patch.diff for which I did the changes to
> > implement roundeven. There might be some unnecessary changes and some
> > necessary changes which have not been made.
> You haven't called roundeven() in the patch. You'll need to add an
> entry in fold_const_call_ss()
> similar to real_ceil, and probably in other places too.
>
> Thanks,
> Prathamesh
> >
> > Regards,
> > -Tejas
> >
> > On Mon, 4 Feb 2019 at 20:36, Prathamesh Kulkarni
> > <prathamesh.kulkarni@linaro.org> wrote:
> > >
> > > On Mon, 4 Feb 2019 at 20:10, Tejas Joshi <tejasjoshi9673@gmail.com> wrote:
> > > >
> > > > Hello.
> > > > I have implemented roundeven function in real.c as follows: (and
> > > > respective changes in real.h)
> > > It's a better idea to include all changes in patch instead of copy-pasting.
> > > Use the command:
> > > git diff > patch.diff
> > > which will create a file called "patch.diff" containing the changes
> > > and send it as an attachment.
> > > >
> > > > /* 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?
> > > Did you add an entry for roundeven in builtins.def ?
> > >
> > > Thanks,
> > > Prathamesh
> > > >
> > > > 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

[-- Attachment #2: patch.diff --]
[-- Type: text/x-patch, Size: 5556 bytes --]

diff --git a/gcc/builtins.c b/gcc/builtins.c
index 25e01e4092b..25282d2122d 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -2067,6 +2067,7 @@ mathfn_built_in_2 (tree type, combined_fn fn)
     CASE_MATHFN (REMQUO)
     CASE_MATHFN_FLOATN (RINT)
     CASE_MATHFN_FLOATN (ROUND)
+    CASE_MATHFN_FLOATN (ROUNDEVEN)
     CASE_MATHFN (SCALB)
     CASE_MATHFN (SCALBLN)
     CASE_MATHFN (SCALBN)
diff --git a/gcc/builtins.def b/gcc/builtins.def
index ef89729fd0c..f1b6830a49c 100644
--- a/gcc/builtins.def
+++ b/gcc/builtins.def
@@ -308,6 +308,7 @@ DEF_C99_BUILTIN        (BUILT_IN_CBRT, "cbrt", BT_FN_DOUBLE_DOUBLE, ATTR_MATHFN_
 DEF_C99_BUILTIN        (BUILT_IN_CBRTF, "cbrtf", BT_FN_FLOAT_FLOAT, ATTR_MATHFN_FPROUNDING)
 DEF_C99_BUILTIN        (BUILT_IN_CBRTL, "cbrtl", BT_FN_LONGDOUBLE_LONGDOUBLE, ATTR_MATHFN_FPROUNDING)
 DEF_LIB_BUILTIN        (BUILT_IN_CEIL, "ceil", BT_FN_DOUBLE_DOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
+DEF_EXT_LIB_BUILTIN    (BUILT_IN_ROUNDEVEN, "roundeven", BT_FN_DOUBLE_DOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_C99_C90RES_BUILTIN (BUILT_IN_CEILF, "ceilf", BT_FN_FLOAT_FLOAT, ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_C99_C90RES_BUILTIN (BUILT_IN_CEILL, "ceill", BT_FN_LONGDOUBLE_LONGDOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
 #define CEIL_TYPE(F) BT_FN_##F##_##F
diff --git a/gcc/fold-const-call.c b/gcc/fold-const-call.c
index 06a420601c0..6f4fea63b0c 100644
--- a/gcc/fold-const-call.c
+++ b/gcc/fold-const-call.c
@@ -773,6 +773,16 @@ fold_const_call_ss (real_value *result, combined_fn fn,
     CASE_CFN_CEIL_FN:
       if (!REAL_VALUE_ISNAN (*arg) || !flag_errno_math)
 	{
+	  fprintf (stderr, "\n");
+	  fprintf (stderr, "cl: %u\n", arg->cl);
+	  fprintf (stderr, "sign: %u\n", arg->sign);
+	  fprintf (stderr, "signalling: %u\n", arg->signalling);
+	  fprintf (stderr, "canonical: %u\n", arg->canonical);
+	  fprintf (stderr, "uexp: %u\n", arg->uexp);
+	  
+	  fprintf (stderr, "sig: ");
+	  for (int i = 0; i < SIGSZ; i++)
+	    fprintf (stderr, "%lx ", arg->sig[i]);
 	  real_ceil (result, format, arg);
 	  return true;
 	}
@@ -792,6 +802,15 @@ fold_const_call_ss (real_value *result, combined_fn fn,
 	}
       return false;
 
+    CASE_CFN_ROUNDEVEN:
+    CASE_CFN_ROUNDEVEN_FN:
+      if (!REAL_VALUE_ISNAN (*arg) || !flag_errno_math)
+  {
+    real_roundeven (result, format, arg);
+    return true;
+  }
+      return false;
+
     CASE_CFN_LOGB:
       return fold_const_logb (result, arg, format);
 
diff --git a/gcc/internal-fn.def b/gcc/internal-fn.def
index cda314e1121..b89918815f9 100644
--- a/gcc/internal-fn.def
+++ b/gcc/internal-fn.def
@@ -224,6 +224,7 @@ DEF_INTERNAL_FLT_FLOATN_FN (FLOOR, ECF_CONST, floor, unary)
 DEF_INTERNAL_FLT_FLOATN_FN (NEARBYINT, ECF_CONST, nearbyint, unary)
 DEF_INTERNAL_FLT_FLOATN_FN (RINT, ECF_CONST, rint, unary)
 DEF_INTERNAL_FLT_FLOATN_FN (ROUND, ECF_CONST, round, unary)
+DEF_INTERNAL_FLT_FLOATN_FN (ROUNDEVEN, ECF_CONST, roundeven, unary)
 DEF_INTERNAL_FLT_FLOATN_FN (TRUNC, ECF_CONST, btrunc, unary)
 
 /* Binary math functions.  */
diff --git a/gcc/optabs.def b/gcc/optabs.def
index 5a67f5eed5e..eb9e22acd8f 100644
--- a/gcc/optabs.def
+++ b/gcc/optabs.def
@@ -267,6 +267,7 @@ OPTAB_D (fnms_optab, "fnms$a4")
 
 OPTAB_D (rint_optab, "rint$a2")
 OPTAB_D (round_optab, "round$a2")
+OPTAB_D (roundeven_optab, "roundeven$a2")
 OPTAB_D (floor_optab, "floor$a2")
 OPTAB_D (ceil_optab, "ceil$a2")
 OPTAB_D (btrunc_optab, "btrunc$a2")
diff --git a/gcc/real.c b/gcc/real.c
index f822ae82d61..9c57f50e8fc 100644
--- a/gcc/real.c
+++ b/gcc/real.c
@@ -1956,6 +1956,8 @@ real_to_hexadecimal (char *str, const REAL_VALUE_TYPE *r, size_t buf_size,
 int
 real_from_string (REAL_VALUE_TYPE *r, const char *str)
 {
+  fprintf (stderr, "\nreal_from_string: str = %s\n", str);
+      
   int exp = 0;
   bool sign = false;
 
@@ -5004,10 +5006,39 @@ 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;
+}
+
+/* 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);
+  fprintf (stderr, "\nhere\n");
+  fprintf (stderr, "\n i = %ld\n", i);
+  if(i % 2)
+    do_add (r, &t, &dconstm1, 0);
+  else
+    *r = t;
 }
 
 /* Set the sign of R to the sign of X.  */
diff --git a/gcc/real.h b/gcc/real.h
index 0ce42565708..10898eae79e 100644
--- a/gcc/real.h
+++ b/gcc/real.h
@@ -499,6 +499,8 @@ extern void real_ceil (REAL_VALUE_TYPE *, format_helper,
 		       const REAL_VALUE_TYPE *);
 extern void real_round (REAL_VALUE_TYPE *, format_helper,
 			const REAL_VALUE_TYPE *);
+extern void real_roundeven (REAL_VALUE_TYPE *, format_helper,
+      const REAL_VALUE_TYPE *);
 
 /* Set the sign of R to the sign of X.  */
 extern void real_copysign (REAL_VALUE_TYPE *, const REAL_VALUE_TYPE *);
diff --git a/gcc/realmpfr.c b/gcc/realmpfr.c
index 10f05caaba3..4834fd017b1 100644
--- a/gcc/realmpfr.c
+++ b/gcc/realmpfr.c
@@ -98,6 +98,7 @@ real_from_mpfr (REAL_VALUE_TYPE *r, mpfr_srcptr m, const real_format *format,
 
   mpfr_free_str (rstr);
 
+  fprintf (stderr, "\nreal_from_mpfr: buf = %s\n", buf);
   real_from_string (r, buf);
 }
 

Re: About GSOC.

[Tejas Joshi]

[-- Attachment #1: Type: text/plain, Size: 6245 bytes --]

Hello.
I had a little pause on roundeven due to seminars in my college. I've
tried to implement roundeven but can not figure out what are just
minimal needs to roundeven be called for a test program like
__builtin_roundeven();
Also, build exited returning status as:

DEF_INTERNAL_FLT_FN (ROUNDEVEN) has no associated built-in functions

Here is the .diff flie.

Thanks,
-Tejas

On Mon, 4 Feb 2019 at 22:55, Tejas Joshi <tejasjoshi9673@gmail.com> wrote:
>
> Hi.
> Although now, I am unable to build the compiler.
> The build exited returning status as:
>
> DEF_INTERNAL_FLT_FN (ROUNDEVEN) has no associated built-in functions
>
> I have added the entry in fold_const_call_ss() and do not find any
> other place to add the case.
> Here is the latest patch.
>
> On Mon, 4 Feb 2019 at 22:14, Prathamesh Kulkarni
> <prathamesh.kulkarni@linaro.org> wrote:
> >
> > On Mon, 4 Feb 2019 at 21:27, Tejas Joshi <tejasjoshi9673@gmail.com> wrote:
> > >
> > > Thanks.
> > > > Did you add an entry for roundeven in builtins.def ?
> > > Yes, I did.
> > >
> > > Find here the attached patch.diff for which I did the changes to
> > > implement roundeven. There might be some unnecessary changes and some
> > > necessary changes which have not been made.
> > You haven't called roundeven() in the patch. You'll need to add an
> > entry in fold_const_call_ss()
> > similar to real_ceil, and probably in other places too.
> >
> > Thanks,
> > Prathamesh
> > >
> > > Regards,
> > > -Tejas
> > >
> > > On Mon, 4 Feb 2019 at 20:36, Prathamesh Kulkarni
> > > <prathamesh.kulkarni@linaro.org> wrote:
> > > >
> > > > On Mon, 4 Feb 2019 at 20:10, Tejas Joshi <tejasjoshi9673@gmail.com> wrote:
> > > > >
> > > > > Hello.
> > > > > I have implemented roundeven function in real.c as follows: (and
> > > > > respective changes in real.h)
> > > > It's a better idea to include all changes in patch instead of copy-pasting.
> > > > Use the command:
> > > > git diff > patch.diff
> > > > which will create a file called "patch.diff" containing the changes
> > > > and send it as an attachment.
> > > > >
> > > > > /* 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?
> > > > Did you add an entry for roundeven in builtins.def ?
> > > >
> > > > Thanks,
> > > > Prathamesh
> > > > >
> > > > > 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

[-- Attachment #2: patch.diff --]
[-- Type: text/x-patch, Size: 6731 bytes --]

diff --git a/gcc/builtins.c b/gcc/builtins.c
index 25e01e4092b..25282d2122d 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -2067,6 +2067,7 @@ mathfn_built_in_2 (tree type, combined_fn fn)
     CASE_MATHFN (REMQUO)
     CASE_MATHFN_FLOATN (RINT)
     CASE_MATHFN_FLOATN (ROUND)
+    CASE_MATHFN_FLOATN (ROUNDEVEN)
     CASE_MATHFN (SCALB)
     CASE_MATHFN (SCALBLN)
     CASE_MATHFN (SCALBN)
diff --git a/gcc/builtins.def b/gcc/builtins.def
index ef89729fd0c..9b554333f57 100644
--- a/gcc/builtins.def
+++ b/gcc/builtins.def
@@ -542,9 +542,13 @@ DEF_C99_BUILTIN        (BUILT_IN_RINTL, "rintl", BT_FN_LONGDOUBLE_LONGDOUBLE, AT
 #define RINT_TYPE(F) BT_FN_##F##_##F
 DEF_EXT_LIB_FLOATN_NX_BUILTINS (BUILT_IN_RINT, "rint", RINT_TYPE, ATTR_CONST_NOTHROW_LEAF_LIST)
 #undef RINT_TYPE
+DEF_EXT_LIB_BUILTIN    (BUILT_IN_ROUNDEVEN, "roundeven", BT_FN_DOUBLE_DOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_C99_BUILTIN        (BUILT_IN_ROUND, "round", BT_FN_DOUBLE_DOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_C99_BUILTIN        (BUILT_IN_ROUNDF, "roundf", BT_FN_FLOAT_FLOAT, ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_C99_BUILTIN        (BUILT_IN_ROUNDL, "roundl", BT_FN_LONGDOUBLE_LONGDOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
+#define ROUNDEVEN_TYPE(F) BT_FN_##F##_##F
+DEF_EXT_LIB_FLOATN_NX_BUILTINS (BUILT_IN_ROUNDEVEN, "roundeven", ROUNDEVEN_TYPE, ATTR_CONST_NOTHROW_LEAF_LIST)
+#undef ROUNDEVEN_TYPE
 #define ROUND_TYPE(F) BT_FN_##F##_##F
 DEF_EXT_LIB_FLOATN_NX_BUILTINS (BUILT_IN_ROUND, "round", ROUND_TYPE, ATTR_CONST_NOTHROW_LEAF_LIST)
 #undef ROUND_TYPE
diff --git a/gcc/fold-const-call.c b/gcc/fold-const-call.c
index 06a420601c0..6f4fea63b0c 100644
--- a/gcc/fold-const-call.c
+++ b/gcc/fold-const-call.c
@@ -773,6 +773,16 @@ fold_const_call_ss (real_value *result, combined_fn fn,
     CASE_CFN_CEIL_FN:
       if (!REAL_VALUE_ISNAN (*arg) || !flag_errno_math)
 	{
+	  fprintf (stderr, "\n");
+	  fprintf (stderr, "cl: %u\n", arg->cl);
+	  fprintf (stderr, "sign: %u\n", arg->sign);
+	  fprintf (stderr, "signalling: %u\n", arg->signalling);
+	  fprintf (stderr, "canonical: %u\n", arg->canonical);
+	  fprintf (stderr, "uexp: %u\n", arg->uexp);
+	  
+	  fprintf (stderr, "sig: ");
+	  for (int i = 0; i < SIGSZ; i++)
+	    fprintf (stderr, "%lx ", arg->sig[i]);
 	  real_ceil (result, format, arg);
 	  return true;
 	}
@@ -792,6 +802,15 @@ fold_const_call_ss (real_value *result, combined_fn fn,
 	}
       return false;
 
+    CASE_CFN_ROUNDEVEN:
+    CASE_CFN_ROUNDEVEN_FN:
+      if (!REAL_VALUE_ISNAN (*arg) || !flag_errno_math)
+  {
+    real_roundeven (result, format, arg);
+    return true;
+  }
+      return false;
+
     CASE_CFN_LOGB:
       return fold_const_logb (result, arg, format);
 
diff --git a/gcc/fold-const.c b/gcc/fold-const.c
index 59cedeafd71..30c409e95bf 100644
--- a/gcc/fold-const.c
+++ b/gcc/fold-const.c
@@ -329,6 +329,7 @@ negate_mathfn_p (combined_fn fn)
     CASE_CFN_LLROUND:
     CASE_CFN_LROUND:
     CASE_CFN_ROUND:
+    CASE_CFN_ROUNDEVEN:
     CASE_CFN_SIN:
     CASE_CFN_SINH:
     CASE_CFN_TAN:
@@ -13060,6 +13061,8 @@ tree_call_nonnegative_warnv_p (tree type, combined_fn fn, tree arg0, tree arg1,
     CASE_CFN_RINT_FN:
     CASE_CFN_ROUND:
     CASE_CFN_ROUND_FN:
+    CASE_CFN_ROUNDEVEN:
+    CASE_CFN_ROUNDEVEN_FN:
     CASE_CFN_SCALB:
     CASE_CFN_SCALBLN:
     CASE_CFN_SCALBN:
@@ -13583,6 +13586,8 @@ integer_valued_real_call_p (combined_fn fn, tree arg0, tree arg1, int depth)
     CASE_CFN_RINT_FN:
     CASE_CFN_ROUND:
     CASE_CFN_ROUND_FN:
+    CASE_CFN_ROUNDEVEN:
+    CASE_CFN_ROUNDEVEN_FN:
     CASE_CFN_TRUNC:
     CASE_CFN_TRUNC_FN:
       return true;
diff --git a/gcc/internal-fn.def b/gcc/internal-fn.def
index cda314e1121..b89918815f9 100644
--- a/gcc/internal-fn.def
+++ b/gcc/internal-fn.def
@@ -224,6 +224,7 @@ DEF_INTERNAL_FLT_FLOATN_FN (FLOOR, ECF_CONST, floor, unary)
 DEF_INTERNAL_FLT_FLOATN_FN (NEARBYINT, ECF_CONST, nearbyint, unary)
 DEF_INTERNAL_FLT_FLOATN_FN (RINT, ECF_CONST, rint, unary)
 DEF_INTERNAL_FLT_FLOATN_FN (ROUND, ECF_CONST, round, unary)
+DEF_INTERNAL_FLT_FLOATN_FN (ROUNDEVEN, ECF_CONST, roundeven, unary)
 DEF_INTERNAL_FLT_FLOATN_FN (TRUNC, ECF_CONST, btrunc, unary)
 
 /* Binary math functions.  */
diff --git a/gcc/optabs.def b/gcc/optabs.def
index 5a67f5eed5e..eb9e22acd8f 100644
--- a/gcc/optabs.def
+++ b/gcc/optabs.def
@@ -267,6 +267,7 @@ OPTAB_D (fnms_optab, "fnms$a4")
 
 OPTAB_D (rint_optab, "rint$a2")
 OPTAB_D (round_optab, "round$a2")
+OPTAB_D (roundeven_optab, "roundeven$a2")
 OPTAB_D (floor_optab, "floor$a2")
 OPTAB_D (ceil_optab, "ceil$a2")
 OPTAB_D (btrunc_optab, "btrunc$a2")
diff --git a/gcc/real.c b/gcc/real.c
index f822ae82d61..9c57f50e8fc 100644
--- a/gcc/real.c
+++ b/gcc/real.c
@@ -1956,6 +1956,8 @@ real_to_hexadecimal (char *str, const REAL_VALUE_TYPE *r, size_t buf_size,
 int
 real_from_string (REAL_VALUE_TYPE *r, const char *str)
 {
+  fprintf (stderr, "\nreal_from_string: str = %s\n", str);
+      
   int exp = 0;
   bool sign = false;
 
@@ -5004,10 +5006,39 @@ 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;
+}
+
+/* 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);
+  fprintf (stderr, "\nhere\n");
+  fprintf (stderr, "\n i = %ld\n", i);
+  if(i % 2)
+    do_add (r, &t, &dconstm1, 0);
+  else
+    *r = t;
 }
 
 /* Set the sign of R to the sign of X.  */
diff --git a/gcc/real.h b/gcc/real.h
index 0ce42565708..10898eae79e 100644
--- a/gcc/real.h
+++ b/gcc/real.h
@@ -499,6 +499,8 @@ extern void real_ceil (REAL_VALUE_TYPE *, format_helper,
 		       const REAL_VALUE_TYPE *);
 extern void real_round (REAL_VALUE_TYPE *, format_helper,
 			const REAL_VALUE_TYPE *);
+extern void real_roundeven (REAL_VALUE_TYPE *, format_helper,
+      const REAL_VALUE_TYPE *);
 
 /* Set the sign of R to the sign of X.  */
 extern void real_copysign (REAL_VALUE_TYPE *, const REAL_VALUE_TYPE *);
diff --git a/gcc/realmpfr.c b/gcc/realmpfr.c
index 10f05caaba3..4834fd017b1 100644
--- a/gcc/realmpfr.c
+++ b/gcc/realmpfr.c
@@ -98,6 +98,7 @@ real_from_mpfr (REAL_VALUE_TYPE *r, mpfr_srcptr m, const real_format *format,
 
   mpfr_free_str (rstr);
 
+  fprintf (stderr, "\nreal_from_mpfr: buf = %s\n", buf);
   real_from_string (r, buf);
 }
 

Re: About GSOC.

[Tejas Joshi]

[-- Attachment #1: Type: text/plain, Size: 7124 bytes --]

Hello.
I have developed a fairly working patch for roundeven, attaching herewith.
The testcase function as follows :

double f()
{
  double x = 4.5;
  double ret = __builtin_roundeven (x);
  return ret;
}

We can inspect the file foo.c.028t.ccp1, where we can see f() returns
value 4.0e+0.
I am also writing the proposal and make draft ready in couple of days
for community review.
Do roundeven have to be added in internals-fn.def to be called internal?

Thanks,
-Tejas


On Sun, 24 Feb 2019 at 17:39, Tejas Joshi <tejasjoshi9673@gmail.com> wrote:
>
> Hello.
> I had a little pause on roundeven due to seminars in my college. I've
> tried to implement roundeven but can not figure out what are just
> minimal needs to roundeven be called for a test program like
> __builtin_roundeven();
> Also, build exited returning status as:
>
> DEF_INTERNAL_FLT_FN (ROUNDEVEN) has no associated built-in functions
>
> Here is the .diff flie.
>
> Thanks,
> -Tejas
>
> On Mon, 4 Feb 2019 at 22:55, Tejas Joshi <tejasjoshi9673@gmail.com> wrote:
> >
> > Hi.
> > Although now, I am unable to build the compiler.
> > The build exited returning status as:
> >
> > DEF_INTERNAL_FLT_FN (ROUNDEVEN) has no associated built-in functions
> >
> > I have added the entry in fold_const_call_ss() and do not find any
> > other place to add the case.
> > Here is the latest patch.
> >
> > On Mon, 4 Feb 2019 at 22:14, Prathamesh Kulkarni
> > <prathamesh.kulkarni@linaro.org> wrote:
> > >
> > > On Mon, 4 Feb 2019 at 21:27, Tejas Joshi <tejasjoshi9673@gmail.com> wrote:
> > > >
> > > > Thanks.
> > > > > Did you add an entry for roundeven in builtins.def ?
> > > > Yes, I did.
> > > >
> > > > Find here the attached patch.diff for which I did the changes to
> > > > implement roundeven. There might be some unnecessary changes and some
> > > > necessary changes which have not been made.
> > > You haven't called roundeven() in the patch. You'll need to add an
> > > entry in fold_const_call_ss()
> > > similar to real_ceil, and probably in other places too.
> > >
> > > Thanks,
> > > Prathamesh
> > > >
> > > > Regards,
> > > > -Tejas
> > > >
> > > > On Mon, 4 Feb 2019 at 20:36, Prathamesh Kulkarni
> > > > <prathamesh.kulkarni@linaro.org> wrote:
> > > > >
> > > > > On Mon, 4 Feb 2019 at 20:10, Tejas Joshi <tejasjoshi9673@gmail.com> wrote:
> > > > > >
> > > > > > Hello.
> > > > > > I have implemented roundeven function in real.c as follows: (and
> > > > > > respective changes in real.h)
> > > > > It's a better idea to include all changes in patch instead of copy-pasting.
> > > > > Use the command:
> > > > > git diff > patch.diff
> > > > > which will create a file called "patch.diff" containing the changes
> > > > > and send it as an attachment.
> > > > > >
> > > > > > /* 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?
> > > > > Did you add an entry for roundeven in builtins.def ?
> > > > >
> > > > > Thanks,
> > > > > Prathamesh
> > > > > >
> > > > > > 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

[-- Attachment #2: roundeven.patch --]
[-- Type: text/x-patch, Size: 4321 bytes --]

diff --git a/gcc/builtins.c b/gcc/builtins.c
index 25e01e4092b..0b2d6bf82f9 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -2067,6 +2067,7 @@ mathfn_built_in_2 (tree type, combined_fn fn)
     CASE_MATHFN (REMQUO)
     CASE_MATHFN_FLOATN (RINT)
     CASE_MATHFN_FLOATN (ROUND)
+    CASE_MATHFN (ROUNDEVEN)
     CASE_MATHFN (SCALB)
     CASE_MATHFN (SCALBLN)
     CASE_MATHFN (SCALBN)
diff --git a/gcc/builtins.def b/gcc/builtins.def
index ef89729fd0c..e1d593a8765 100644
--- a/gcc/builtins.def
+++ b/gcc/builtins.def
@@ -542,6 +542,9 @@ DEF_C99_BUILTIN        (BUILT_IN_RINTL, "rintl", BT_FN_LONGDOUBLE_LONGDOUBLE, AT
 #define RINT_TYPE(F) BT_FN_##F##_##F
 DEF_EXT_LIB_FLOATN_NX_BUILTINS (BUILT_IN_RINT, "rint", RINT_TYPE, ATTR_CONST_NOTHROW_LEAF_LIST)
 #undef RINT_TYPE
+DEF_EXT_LIB_BUILTIN    (BUILT_IN_ROUNDEVEN, "roundeven", BT_FN_DOUBLE_DOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
+DEF_EXT_LIB_BUILTIN    (BUILT_IN_ROUNDEVENF, "roundevenf", BT_FN_FLOAT_FLOAT, ATTR_CONST_NOTHROW_LEAF_LIST)
+DEF_EXT_LIB_BUILTIN    (BUILT_IN_ROUNDEVENL, "roundevenl", BT_FN_LONGDOUBLE_LONGDOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_C99_BUILTIN        (BUILT_IN_ROUND, "round", BT_FN_DOUBLE_DOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_C99_BUILTIN        (BUILT_IN_ROUNDF, "roundf", BT_FN_FLOAT_FLOAT, ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_C99_BUILTIN        (BUILT_IN_ROUNDL, "roundl", BT_FN_LONGDOUBLE_LONGDOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
diff --git a/gcc/fold-const-call.c b/gcc/fold-const-call.c
index 06a420601c0..7eafd91e9a2 100644
--- a/gcc/fold-const-call.c
+++ b/gcc/fold-const-call.c
@@ -792,6 +792,14 @@ fold_const_call_ss (real_value *result, combined_fn fn,
 	}
       return false;
 
+    case CFN_BUILT_IN_ROUNDEVEN:
+      if (!REAL_VALUE_ISNAN (*arg) || !flag_errno_math)
+  {
+    real_roundeven (result, format, arg);
+    return true;
+  }
+      return false;
+
     CASE_CFN_LOGB:
       return fold_const_logb (result, arg, format);
 
@@ -854,6 +862,9 @@ fold_const_call_ss (wide_int *result, combined_fn fn,
       return fold_const_conversion (result, real_round, arg,
 				    precision, format);
 
+    case CFN_BUILT_IN_ROUNDEVEN:
+      return fold_const_conversion (result, real_roundeven, arg, precision, format);
+
     CASE_CFN_IRINT:
     CASE_CFN_LRINT:
     CASE_CFN_LLRINT:
diff --git a/gcc/fold-const.c b/gcc/fold-const.c
index 59cedeafd71..30c409e95bf 100644
--- a/gcc/fold-const.c
+++ b/gcc/fold-const.c
@@ -329,6 +329,7 @@ negate_mathfn_p (combined_fn fn)
     CASE_CFN_LLROUND:
     CASE_CFN_LROUND:
     CASE_CFN_ROUND:
+    CASE_CFN_ROUNDEVEN:
     CASE_CFN_SIN:
     CASE_CFN_SINH:
     CASE_CFN_TAN:
@@ -13060,6 +13061,8 @@ tree_call_nonnegative_warnv_p (tree type, combined_fn fn, tree arg0, tree arg1,
     CASE_CFN_RINT_FN:
     CASE_CFN_ROUND:
     CASE_CFN_ROUND_FN:
+    CASE_CFN_ROUNDEVEN:
+    CASE_CFN_ROUNDEVEN_FN:
     CASE_CFN_SCALB:
     CASE_CFN_SCALBLN:
     CASE_CFN_SCALBN:
@@ -13583,6 +13586,8 @@ integer_valued_real_call_p (combined_fn fn, tree arg0, tree arg1, int depth)
     CASE_CFN_RINT_FN:
     CASE_CFN_ROUND:
     CASE_CFN_ROUND_FN:
+    CASE_CFN_ROUNDEVEN:
+    CASE_CFN_ROUNDEVEN_FN:
     CASE_CFN_TRUNC:
     CASE_CFN_TRUNC_FN:
       return true;
diff --git a/gcc/real.c b/gcc/real.c
index f822ae82d61..087478841e5 100644
--- a/gcc/real.c
+++ b/gcc/real.c
@@ -5010,6 +5010,22 @@ real_round (REAL_VALUE_TYPE *r, format_helper fmt,
     real_convert (r, fmt, r);
 }
 
+/* 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;
+}
+
 /* Set the sign of R to the sign of X.  */
 
 void
diff --git a/gcc/real.h b/gcc/real.h
index 0ce42565708..10898eae79e 100644
--- a/gcc/real.h
+++ b/gcc/real.h
@@ -499,6 +499,8 @@ extern void real_ceil (REAL_VALUE_TYPE *, format_helper,
 		       const REAL_VALUE_TYPE *);
 extern void real_round (REAL_VALUE_TYPE *, format_helper,
 			const REAL_VALUE_TYPE *);
+extern void real_roundeven (REAL_VALUE_TYPE *, format_helper,
+      const REAL_VALUE_TYPE *);
 
 /* Set the sign of R to the sign of X.  */
 extern void real_copysign (REAL_VALUE_TYPE *, const REAL_VALUE_TYPE *);

[-- Attachment #3: foo.c.028t.ccp1 --]
[-- Type: application/octet-stream, Size: 1149 bytes --]


;; Function f (f, funcdef_no=0, decl_uid=1907, cgraph_uid=1, symbol_order=0)

Adding destination of edge (0 -> 2) to worklist

Simulating block 2

Visiting statement:
x_1 = 4.5e+0;
which is likely CONSTANT
Lattice value changed to CONSTANT 4.5e+0.  Adding SSA edges to worklist.
marking stmt to be not simulated again

Visiting statement:
ret_2 = __builtin_roundeven (x_1);
which is likely CONSTANT
Match-and-simplified __builtin_roundeven (x_1) to 4.0e+0
Lattice value changed to CONSTANT 4.0e+0.  Adding SSA edges to worklist.
marking stmt to be not simulated again

Visiting statement:
_3 = ret_2;
which is likely CONSTANT
Match-and-simplified ret_2 to 4.0e+0
Lattice value changed to CONSTANT 4.0e+0.  Adding SSA edges to worklist.
marking stmt to be not simulated again

Visiting statement:
return _3;
No interesting values produced.  Marked VARYING.

Substituting values and folding statements

Folding statement: return _3;
Folded into: return 4.0e+0;

Removing dead stmt _3 = ret_2;

Removing dead stmt ret_2 = __builtin_roundeven (x_1);

Removing dead stmt x_1 = 4.5e+0;

f ()
{
  double ret;
  double x;

  <bb 2> :
  return 4.0e+0;

}

Re: About GSOC.

[Joseph Myers]

On Sat, 30 Mar 2019, Tejas Joshi wrote:

> Hello.
> I have developed a fairly working patch for roundeven, attaching herewith.
> The testcase function as follows :
> 
> double f()
> {
>   double x = 4.5;
>   double ret = __builtin_roundeven (x);
>   return ret;
> }

Tests need to be added to the testsuite, covering a range of inputs and 
automatically verifying that the test is optimized correctly.

"Round X to nearest even integer towards zero." is not correct.  The 
roundeven function does not round to an even integer.  It rounds to the 
nearest integer, whether even or odd - but, if two integers are equally 
close, the result is even (and for any input that is not halfway between 
two integers, it produces the same result as round (which rounds halfway 
cases away from zero) - so 2.501, 3 and 3.499 round to 3, but 2.5 rounds 
to 2 not 3, unlike round, and 3.5 rounds to 4, as with round).

The function can't rely on arguments being in the range of HOST_WIDE_INT, 
so it needs to examine the REAL_VALUE_TYPE representation directly to 
determine whether it's half way between two integers and which way to 
round in that case.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: About GSOC.

[Tejas Joshi]

Hello.
Here is the proposal draft for the idea. Please review and suggest
changes or modifications.

https://docs.google.com/document/d/15DEXa5NZL6Q_X_zlME3NNJw2zVimFWzi16x7cgIDqL0/edit?usp=sharing

Thanks,
-Tejas

On Tue, 2 Apr 2019 at 01:23, Joseph Myers <joseph@codesourcery.com> wrote:
>
> On Sat, 30 Mar 2019, Tejas Joshi wrote:
>
> > Hello.
> > I have developed a fairly working patch for roundeven, attaching herewith.
> > The testcase function as follows :
> >
> > double f()
> > {
> >   double x = 4.5;
> >   double ret = __builtin_roundeven (x);
> >   return ret;
> > }
>
> Tests need to be added to the testsuite, covering a range of inputs and
> automatically verifying that the test is optimized correctly.
>
> "Round X to nearest even integer towards zero." is not correct.  The
> roundeven function does not round to an even integer.  It rounds to the
> nearest integer, whether even or odd - but, if two integers are equally
> close, the result is even (and for any input that is not halfway between
> two integers, it produces the same result as round (which rounds halfway
> cases away from zero) - so 2.501, 3 and 3.499 round to 3, but 2.5 rounds
> to 2 not 3, unlike round, and 3.5 rounds to 4, as with round).
>
> The function can't rely on arguments being in the range of HOST_WIDE_INT,
> so it needs to examine the REAL_VALUE_TYPE representation directly to
> determine whether it's half way between two integers and which way to
> round in that case.
>
> --
> Joseph S. Myers
> joseph@codesourcery.com

Re: About GSOC.

[Tejas Joshi]

[-- Attachment #1: Type: text/plain, Size: 483 bytes --]

Hello.
Taking the notes from Joseph under consideration, I have developed a
fairly working patch for roundeven, attached herewith.
I have done bit-wise calculations to check for halfway cases, though
HOST_WIDE_INT is only used to check for even and odd numbers (or is it
necessary to do bit-wise for this too?). Also, why unsigned long
sig[SIGSZ] in real_value has to be an array? (for 64 bit system, its
an array of size 3, mostly first 2 values being 0?).
Thanks.

Regards,
-Tejas

[-- Attachment #2: roundeven.patch --]
[-- Type: text/x-patch, Size: 4836 bytes --]

diff --git a/gcc/builtins.c b/gcc/builtins.c
index 25e01e4092b..0b2d6bf82f9 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -2067,6 +2067,7 @@ mathfn_built_in_2 (tree type, combined_fn fn)
     CASE_MATHFN (REMQUO)
     CASE_MATHFN_FLOATN (RINT)
     CASE_MATHFN_FLOATN (ROUND)
+    CASE_MATHFN (ROUNDEVEN)
     CASE_MATHFN (SCALB)
     CASE_MATHFN (SCALBLN)
     CASE_MATHFN (SCALBN)
diff --git a/gcc/builtins.def b/gcc/builtins.def
index ef89729fd0c..e1d593a8765 100644
--- a/gcc/builtins.def
+++ b/gcc/builtins.def
@@ -542,6 +542,9 @@ DEF_C99_BUILTIN        (BUILT_IN_RINTL, "rintl", BT_FN_LONGDOUBLE_LONGDOUBLE, AT
 #define RINT_TYPE(F) BT_FN_##F##_##F
 DEF_EXT_LIB_FLOATN_NX_BUILTINS (BUILT_IN_RINT, "rint", RINT_TYPE, ATTR_CONST_NOTHROW_LEAF_LIST)
 #undef RINT_TYPE
+DEF_EXT_LIB_BUILTIN    (BUILT_IN_ROUNDEVEN, "roundeven", BT_FN_DOUBLE_DOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
+DEF_EXT_LIB_BUILTIN    (BUILT_IN_ROUNDEVENF, "roundevenf", BT_FN_FLOAT_FLOAT, ATTR_CONST_NOTHROW_LEAF_LIST)
+DEF_EXT_LIB_BUILTIN    (BUILT_IN_ROUNDEVENL, "roundevenl", BT_FN_LONGDOUBLE_LONGDOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_C99_BUILTIN        (BUILT_IN_ROUND, "round", BT_FN_DOUBLE_DOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_C99_BUILTIN        (BUILT_IN_ROUNDF, "roundf", BT_FN_FLOAT_FLOAT, ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_C99_BUILTIN        (BUILT_IN_ROUNDL, "roundl", BT_FN_LONGDOUBLE_LONGDOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
diff --git a/gcc/fold-const-call.c b/gcc/fold-const-call.c
index 06a420601c0..7eafd91e9a2 100644
--- a/gcc/fold-const-call.c
+++ b/gcc/fold-const-call.c
@@ -792,6 +792,14 @@ fold_const_call_ss (real_value *result, combined_fn fn,
 	}
       return false;
 
+    case CFN_BUILT_IN_ROUNDEVEN:
+      if (!REAL_VALUE_ISNAN (*arg) || !flag_errno_math)
+  {
+    real_roundeven (result, format, arg);
+    return true;
+  }
+      return false;
+
     CASE_CFN_LOGB:
       return fold_const_logb (result, arg, format);
 
@@ -854,6 +862,9 @@ fold_const_call_ss (wide_int *result, combined_fn fn,
       return fold_const_conversion (result, real_round, arg,
 				    precision, format);
 
+    case CFN_BUILT_IN_ROUNDEVEN:
+      return fold_const_conversion (result, real_roundeven, arg, precision, format);
+
     CASE_CFN_IRINT:
     CASE_CFN_LRINT:
     CASE_CFN_LLRINT:
diff --git a/gcc/fold-const.c b/gcc/fold-const.c
index 59cedeafd71..30c409e95bf 100644
--- a/gcc/fold-const.c
+++ b/gcc/fold-const.c
@@ -329,6 +329,7 @@ negate_mathfn_p (combined_fn fn)
     CASE_CFN_LLROUND:
     CASE_CFN_LROUND:
     CASE_CFN_ROUND:
+    CASE_CFN_ROUNDEVEN:
     CASE_CFN_SIN:
     CASE_CFN_SINH:
     CASE_CFN_TAN:
@@ -13060,6 +13061,8 @@ tree_call_nonnegative_warnv_p (tree type, combined_fn fn, tree arg0, tree arg1,
     CASE_CFN_RINT_FN:
     CASE_CFN_ROUND:
     CASE_CFN_ROUND_FN:
+    CASE_CFN_ROUNDEVEN:
+    CASE_CFN_ROUNDEVEN_FN:
     CASE_CFN_SCALB:
     CASE_CFN_SCALBLN:
     CASE_CFN_SCALBN:
@@ -13583,6 +13586,8 @@ integer_valued_real_call_p (combined_fn fn, tree arg0, tree arg1, int depth)
     CASE_CFN_RINT_FN:
     CASE_CFN_ROUND:
     CASE_CFN_ROUND_FN:
+    CASE_CFN_ROUNDEVEN:
+    CASE_CFN_ROUNDEVEN_FN:
     CASE_CFN_TRUNC:
     CASE_CFN_TRUNC_FN:
       return true;
diff --git a/gcc/real.c b/gcc/real.c
index f822ae82d61..533d471a89b 100644
--- a/gcc/real.c
+++ b/gcc/real.c
@@ -5010,6 +5010,43 @@ real_round (REAL_VALUE_TYPE *r, format_helper fmt,
     real_convert (r, fmt, r);
 }
 
+bool
+is_halfway_below (const REAL_VALUE_TYPE *r)
+{
+  unsigned long tempsig[SIGSZ];
+  unsigned int n = SIGNIFICAND_BITS - REAL_EXP (r);
+  int i, w = n / HOST_BITS_PER_LONG;
+
+  for (i = 0; i < SIGSZ; ++i)
+    tempsig[i] = r->sig[i];
+
+  for (i = 0; i < w; ++i)
+    tempsig[i] = 0;
+
+  tempsig[w] &= (((unsigned long)1 << ((n % HOST_BITS_PER_LONG) - 1)) - 1);
+  
+  if (tempsig[w] == 0)
+    return true;
+  return false;
+}
+
+/* Round X to nearest integer, rounding halfway cases towards even. */
+
+void
+real_roundeven (REAL_VALUE_TYPE *r, format_helper fmt,
+		const REAL_VALUE_TYPE *x)
+{
+  if (is_halfway_below (x))
+  {
+    do_add (r, x, &dconsthalf, x->sign);
+    HOST_WIDE_INT i = real_to_integer (r);
+    if (i % 2)
+      do_add (r, r, &dconstm1, x->sign);
+  }
+  else
+    real_round (r, fmt, x);
+}
+
 /* Set the sign of R to the sign of X.  */
 
 void
diff --git a/gcc/real.h b/gcc/real.h
index 0ce42565708..10898eae79e 100644
--- a/gcc/real.h
+++ b/gcc/real.h
@@ -499,6 +499,8 @@ extern void real_ceil (REAL_VALUE_TYPE *, format_helper,
 		       const REAL_VALUE_TYPE *);
 extern void real_round (REAL_VALUE_TYPE *, format_helper,
 			const REAL_VALUE_TYPE *);
+extern void real_roundeven (REAL_VALUE_TYPE *, format_helper,
+      const REAL_VALUE_TYPE *);
 
 /* Set the sign of R to the sign of X.  */
 extern void real_copysign (REAL_VALUE_TYPE *, const REAL_VALUE_TYPE *);

Re: About GSOC.

[Joseph Myers]

On Sat, 4 May 2019, Tejas Joshi wrote:

> Hello.
> Taking the notes from Joseph under consideration, I have developed a
> fairly working patch for roundeven, attached herewith.

There are several issues here.  One key one is that you haven't added any 
testcases to the GCC testsuite.  I'd expect tests added that test lots of 
different inputs, for all the float, double and long double types, to 
verify the results are as expected.  That would include various exactly 
halfway cases - but also cases that are halfway plus or minus 1ulp.  Tests 
would be appropriately conditional on the floating-point formats as needed 
- testing for IEEE binary128 long double, on configurations that have that 
type, would help cover certain cases, such as where the integer part 
exceeds 2^64 but there is still a fractional part.

Given tests and confirmation that they have passed in various 
configurations, it's a lot easier to have confidence in the code - and if 
possible issues are spotted in the code, they may point the way to missing 
tests.  That is, tests are a key piece of a patch that makes it much 
easier to review the patch.

> I have done bit-wise calculations to check for halfway cases, though
> HOST_WIDE_INT is only used to check for even and odd numbers (or is it
> necessary to do bit-wise for this too?). Also, why unsigned long

Yes, you need to use bit-wise checks for odd and even numbers, because you 
can have a nonzero fractional part with an integer part that is too big to 
be represented in HOST_WIDE_INT.  With IEEE binary128, you can have 112 
bits in the integer part and still have 0.5 as the fractional part.

> diff --git a/gcc/real.c b/gcc/real.c
> index f822ae82d61..533d471a89b 100644
> --- a/gcc/real.c
> +++ b/gcc/real.c
> @@ -5010,6 +5010,43 @@ real_round (REAL_VALUE_TYPE *r, format_helper fmt,
>      real_convert (r, fmt, r);
>  }
>  
> +bool
> +is_halfway_below (const REAL_VALUE_TYPE *r)
> +{
> +  unsigned long tempsig[SIGSZ];
> +  unsigned int n = SIGNIFICAND_BITS - REAL_EXP (r);
> +  int i, w = n / HOST_BITS_PER_LONG;
> +
> +  for (i = 0; i < SIGSZ; ++i)
> +    tempsig[i] = r->sig[i];
> +
> +  for (i = 0; i < w; ++i)
> +    tempsig[i] = 0;
> +
> +  tempsig[w] &= (((unsigned long)1 << ((n % HOST_BITS_PER_LONG) - 1)) - 1);
> +  
> +  if (tempsig[w] == 0)
> +    return true;

> +  return false;

The logic in this function does not make sense to me.

First, it needs a comment above the function defining its exact semantics.  
Since it lacks a comment, I have to guess based on the name.

If it is meant to be testing whether a value is halfway between two 
integers, there are two things you need to test.  You need to test whether 
the bit with value 0.5 is 0 or 1 (which this function doesn't seem to 
test) - and you also need to test whether *all* bits below it are zero or 
not (this function only appears to check bits in a single word, 
disregarding all the lower words, which is not correct).

If n % HOST_BITS_PER_LONG is 0, this code would shift by -1, which isn't 
valid.  You need to allow for cases where either the division between 0.5 
and 0.25, or the division between 0.5 and 1, falls exactly at a word 
boundary in the representation of the significand.  It would be a good 
idea to include various such cases in the tests you add to the testsuite.

In any case, there is no need to copy the significand into a temporary 
array in order to test whether low bits are 0.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: About GSOC.

[Tejas Joshi]

Hello.
Thanks for your inputs.

If it is meant to be testing whether a value is halfway between two
integers, there are two things you need to test.  You need to test whether
the bit with value 0.5 is 0 or 1 (which this function doesn't seem to
test) - and you also need to test whether *all* bits below it are zero or
not (this function only appears to check bits in a single word,
disregarding all the lower words, which is not correct).

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
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?

If n % HOST_BITS_PER_LONG is 0, this code would shift by -1, which isn't
>

Yes, the condition checking is necessary here. I will incorporate the
changes and find a way to check if the number is even or odd bit-wise and
add test cases in the test suite as soon as possible.
Thanks.

Regards,
-Tejas

On Tue, 7 May 2019 at 22:47, Joseph Myers <joseph@codesourcery.com> wrote:

> On Sat, 4 May 2019, Tejas Joshi wrote:
>
> > Hello.
> > Taking the notes from Joseph under consideration, I have developed a
> > fairly working patch for roundeven, attached herewith.
>
> There are several issues here.  One key one is that you haven't added any
> testcases to the GCC testsuite.  I'd expect tests added that test lots of
> different inputs, for all the float, double and long double types, to
> verify the results are as expected.  That would include various exactly
> halfway cases - but also cases that are halfway plus or minus 1ulp.  Tests
> would be appropriately conditional on the floating-point formats as needed
> - testing for IEEE binary128 long double, on configurations that have that
> type, would help cover certain cases, such as where the integer part
> exceeds 2^64 but there is still a fractional part.
>
> Given tests and confirmation that they have passed in various
> configurations, it's a lot easier to have confidence in the code - and if
> possible issues are spotted in the code, they may point the way to missing
> tests.  That is, tests are a key piece of a patch that makes it much
> easier to review the patch.
>
> > I have done bit-wise calculations to check for halfway cases, though
> > HOST_WIDE_INT is only used to check for even and odd numbers (or is it
> > necessary to do bit-wise for this too?). Also, why unsigned long
>
> Yes, you need to use bit-wise checks for odd and even numbers, because you
> can have a nonzero fractional part with an integer part that is too big to
> be represented in HOST_WIDE_INT.  With IEEE binary128, you can have 112
> bits in the integer part and still have 0.5 as the fractional part.
>
> > diff --git a/gcc/real.c b/gcc/real.c
> > index f822ae82d61..533d471a89b 100644
> > --- a/gcc/real.c
> > +++ b/gcc/real.c
> > @@ -5010,6 +5010,43 @@ real_round (REAL_VALUE_TYPE *r, format_helper fmt,
> >      real_convert (r, fmt, r);
> >  }
> >
> > +bool
> > +is_halfway_below (const REAL_VALUE_TYPE *r)
> > +{
> > +  unsigned long tempsig[SIGSZ];
> > +  unsigned int n = SIGNIFICAND_BITS - REAL_EXP (r);
> > +  int i, w = n / HOST_BITS_PER_LONG;
> > +
> > +  for (i = 0; i < SIGSZ; ++i)
> > +    tempsig[i] = r->sig[i];
> > +
> > +  for (i = 0; i < w; ++i)
> > +    tempsig[i] = 0;
> > +
> > +  tempsig[w] &= (((unsigned long)1 << ((n % HOST_BITS_PER_LONG) - 1)) -
> 1);
> > +
> > +  if (tempsig[w] == 0)
> > +    return true;
>
> > +  return false;
>
> The logic in this function does not make sense to me.
>
> First, it needs a comment above the function defining its exact
> semantics.
> Since it lacks a comment, I have to guess based on the name.
>
> If it is meant to be testing whether a value is halfway between two
> integers, there are two things you need to test.  You need to test whether
> the bit with value 0.5 is 0 or 1 (which this function doesn't seem to
> test) - and you also need to test whether *all* bits below it are zero or
> not (this function only appears to check bits in a single word,
> disregarding all the lower words, which is not correct).
>
> If n % HOST_BITS_PER_LONG is 0, this code would shift by -1, which isn't
> valid.  You need to allow for cases where either the division between 0.5
> and 0.25, or the division between 0.5 and 1, falls exactly at a word
> boundary in the representation of the significand.  It would be a good
> idea to include various such cases in the tests you add to the testsuite.
>
> In any case, there is no need to copy the significand into a temporary
> array in order to test whether low bits are 0.
>
> --
> Joseph S. Myers
> joseph@codesourcery.com
>

Re: About GSOC.

[Joseph Myers]

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

Re: About GSOC.

[Tejas Joshi]

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
>

Re: About GSOC.

[Tejas Joshi]

[-- Attachment #1: Type: text/plain, Size: 3175 bytes --]

Hello.
I can't figure out from the documentation how to add test cases in the
testsuite and inspect the results. How can I do that? Although, Taking
the mentioned conditions under consideration, I have made another
patch, attached.

Thanks,
-Tejas


On Wed, 8 May 2019 at 09:01, Tejas Joshi <tejasjoshi9673@gmail.com> wrote:
>
> 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

[-- Attachment #2: roundeven.patch --]
[-- Type: text/x-patch, Size: 5121 bytes --]

diff --git a/gcc/builtins.c b/gcc/builtins.c
index 25e01e4092b..0b2d6bf82f9 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -2067,6 +2067,7 @@ mathfn_built_in_2 (tree type, combined_fn fn)
     CASE_MATHFN (REMQUO)
     CASE_MATHFN_FLOATN (RINT)
     CASE_MATHFN_FLOATN (ROUND)
+    CASE_MATHFN (ROUNDEVEN)
     CASE_MATHFN (SCALB)
     CASE_MATHFN (SCALBLN)
     CASE_MATHFN (SCALBN)
diff --git a/gcc/builtins.def b/gcc/builtins.def
index ef89729fd0c..e1d593a8765 100644
--- a/gcc/builtins.def
+++ b/gcc/builtins.def
@@ -542,6 +542,9 @@ DEF_C99_BUILTIN        (BUILT_IN_RINTL, "rintl", BT_FN_LONGDOUBLE_LONGDOUBLE, AT
 #define RINT_TYPE(F) BT_FN_##F##_##F
 DEF_EXT_LIB_FLOATN_NX_BUILTINS (BUILT_IN_RINT, "rint", RINT_TYPE, ATTR_CONST_NOTHROW_LEAF_LIST)
 #undef RINT_TYPE
+DEF_EXT_LIB_BUILTIN    (BUILT_IN_ROUNDEVEN, "roundeven", BT_FN_DOUBLE_DOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
+DEF_EXT_LIB_BUILTIN    (BUILT_IN_ROUNDEVENF, "roundevenf", BT_FN_FLOAT_FLOAT, ATTR_CONST_NOTHROW_LEAF_LIST)
+DEF_EXT_LIB_BUILTIN    (BUILT_IN_ROUNDEVENL, "roundevenl", BT_FN_LONGDOUBLE_LONGDOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_C99_BUILTIN        (BUILT_IN_ROUND, "round", BT_FN_DOUBLE_DOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_C99_BUILTIN        (BUILT_IN_ROUNDF, "roundf", BT_FN_FLOAT_FLOAT, ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_C99_BUILTIN        (BUILT_IN_ROUNDL, "roundl", BT_FN_LONGDOUBLE_LONGDOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
diff --git a/gcc/fold-const-call.c b/gcc/fold-const-call.c
index 06a420601c0..7eafd91e9a2 100644
--- a/gcc/fold-const-call.c
+++ b/gcc/fold-const-call.c
@@ -792,6 +792,14 @@ fold_const_call_ss (real_value *result, combined_fn fn,
 	}
       return false;
 
+    case CFN_BUILT_IN_ROUNDEVEN:
+      if (!REAL_VALUE_ISNAN (*arg) || !flag_errno_math)
+  {
+    real_roundeven (result, format, arg);
+    return true;
+  }
+      return false;
+
     CASE_CFN_LOGB:
       return fold_const_logb (result, arg, format);
 
@@ -854,6 +862,9 @@ fold_const_call_ss (wide_int *result, combined_fn fn,
       return fold_const_conversion (result, real_round, arg,
 				    precision, format);
 
+    case CFN_BUILT_IN_ROUNDEVEN:
+      return fold_const_conversion (result, real_roundeven, arg, precision, format);
+
     CASE_CFN_IRINT:
     CASE_CFN_LRINT:
     CASE_CFN_LLRINT:
diff --git a/gcc/fold-const.c b/gcc/fold-const.c
index 59cedeafd71..30c409e95bf 100644
--- a/gcc/fold-const.c
+++ b/gcc/fold-const.c
@@ -329,6 +329,7 @@ negate_mathfn_p (combined_fn fn)
     CASE_CFN_LLROUND:
     CASE_CFN_LROUND:
     CASE_CFN_ROUND:
+    CASE_CFN_ROUNDEVEN:
     CASE_CFN_SIN:
     CASE_CFN_SINH:
     CASE_CFN_TAN:
@@ -13060,6 +13061,8 @@ tree_call_nonnegative_warnv_p (tree type, combined_fn fn, tree arg0, tree arg1,
     CASE_CFN_RINT_FN:
     CASE_CFN_ROUND:
     CASE_CFN_ROUND_FN:
+    CASE_CFN_ROUNDEVEN:
+    CASE_CFN_ROUNDEVEN_FN:
     CASE_CFN_SCALB:
     CASE_CFN_SCALBLN:
     CASE_CFN_SCALBN:
@@ -13583,6 +13586,8 @@ integer_valued_real_call_p (combined_fn fn, tree arg0, tree arg1, int depth)
     CASE_CFN_RINT_FN:
     CASE_CFN_ROUND:
     CASE_CFN_ROUND_FN:
+    CASE_CFN_ROUNDEVEN:
+    CASE_CFN_ROUNDEVEN_FN:
     CASE_CFN_TRUNC:
     CASE_CFN_TRUNC_FN:
       return true;
diff --git a/gcc/real.c b/gcc/real.c
index f822ae82d61..045dc758048 100644
--- a/gcc/real.c
+++ b/gcc/real.c
@@ -5010,6 +5010,53 @@ real_round (REAL_VALUE_TYPE *r, format_helper fmt,
     real_convert (r, fmt, r);
 }
 
+/* Return true if integer part of R is even, else return false. */
+
+bool
+is_even (REAL_VALUE_TYPE *r)
+{
+  unsigned int n = SIGNIFICAND_BITS - REAL_EXP (r);
+
+  unsigned long num = ((unsigned long)1 << (n % HOST_BITS_PER_LONG));
+
+  if ((r->sig[SIGSZ-1] & num) == 0)
+    return true;
+  return false;
+}
+
+/* Return true if R is halfway between two integers, else return false. */
+
+bool
+is_halfway_below (const REAL_VALUE_TYPE *r)
+{
+  if (r->sig[0] != 0 && r->sig[1] != 0)
+    return false;
+
+  unsigned int n = SIGNIFICAND_BITS - REAL_EXP (r);
+
+  unsigned long num = ((unsigned long)1 << ((n - 1) % HOST_BITS_PER_LONG));
+
+  if (((r->sig[SIGSZ-1] & num) != 0) && ((r->sig[SIGSZ-1] & (num-1)) == 0))
+    return true;
+  return false;
+}
+
+/* Round X to nearest integer, rounding halfway cases towards even. */
+
+void
+real_roundeven (REAL_VALUE_TYPE *r, format_helper fmt,
+		const REAL_VALUE_TYPE *x)
+{
+  if (is_halfway_below (x))
+  {
+    do_add (r, x, &dconsthalf, x->sign);
+    if (!is_even (r))
+      do_add (r, r, &dconstm1, x->sign);
+  }
+  else
+    real_round (r, fmt, x);
+}
+
 /* Set the sign of R to the sign of X.  */
 
 void
diff --git a/gcc/real.h b/gcc/real.h
index 0ce42565708..10898eae79e 100644
--- a/gcc/real.h
+++ b/gcc/real.h
@@ -499,6 +499,8 @@ extern void real_ceil (REAL_VALUE_TYPE *, format_helper,
 		       const REAL_VALUE_TYPE *);
 extern void real_round (REAL_VALUE_TYPE *, format_helper,
 			const REAL_VALUE_TYPE *);
+extern void real_roundeven (REAL_VALUE_TYPE *, format_helper,
+      const REAL_VALUE_TYPE *);
 
 /* Set the sign of R to the sign of X.  */
 extern void real_copysign (REAL_VALUE_TYPE *, const REAL_VALUE_TYPE *);

Re: About GSOC.

[Tejas Joshi]

Hello.
I have added a test case in the testsuite referring to an existing one
as "builtin-rounding-1.c" in the /testsuite/gcc.dg/torture directory.
As follows :

/* { dg-do link } */

extern int link_error (int);

#define TEST(FN, VALUE, RESULT) \
  if (__builtin_##FN (VALUE) != RESULT) link_error (__LINE__);

int
main (void)
{
  TEST(roundeven,  0, 0);
  TEST(roundeven,  0.5, 0);
  TEST(roundeven,  -0.5, 0);
  TEST(roundeven,  6, 6);
  TEST(roundeven,  -8, -8);
  TEST(roundeven,  2.5, 2);
  TEST(roundeven,  3.5, 4);
  TEST(roundeven,  -1.5, -2);
  TEST(roundeven,  3.499, 3);
  TEST(roundeven,  3.501, 4);

  return 0;
}

After checking for test case in the build directory using :
$ make check-gcc RUNTESTFLAGS="dg-torture.exp=builtin-round-roundeven.c"
test does not FAIL. Though, it FAILs for intentionally giving wrong RESULT.

Ex : TEST(roundeven,  3.501, 3);
Should fail I believe and thus giving output as:
FAIL: gcc.dg/torture/builtin-round-roundeven.c   -O0  (test for excess errors)
FAIL: gcc.dg/torture/builtin-round-roundeven.c   -O1  (test for excess errors)
FAIL: gcc.dg/torture/builtin-round-roundeven.c   -O2  (test for excess errors)
FAIL: gcc.dg/torture/builtin-round-roundeven.c   -O3 -g  (test for
excess errors)
FAIL: gcc.dg/torture/builtin-round-roundeven.c   -Os  (test for excess errors)
FAIL: gcc.dg/torture/builtin-round-roundeven.c   -O2 -flto
-fno-use-linker-plugin -flto-partition=none  (test for excess errors)
FAIL: gcc.dg/torture/builtin-round-roundeven.c   -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects  (test for excess errors)

Is this the way test cases should be added and checked?

Thanks.

On Wed, 8 May 2019 at 13:05, Tejas Joshi <tejasjoshi9673@gmail.com> wrote:
>
> Hello.
> I can't figure out from the documentation how to add test cases in the
> testsuite and inspect the results. How can I do that? Although, Taking
> the mentioned conditions under consideration, I have made another
> patch, attached.
>
> Thanks,
> -Tejas
>
>
> On Wed, 8 May 2019 at 09:01, Tejas Joshi <tejasjoshi9673@gmail.com> wrote:
> >
> > 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

Re: About GSOC.

[Joseph Myers]

On Wed, 8 May 2019, Tejas Joshi wrote:

> Is this the way test cases should be added and checked?

Yes, that's appropriate for tests of roundeven optimization for constant 
arguments.

When you get onto testing roundevenf128 (to cover various cases with 
113-bit precision), you'll need to make those tests appropriately 
conditional on _Float128 support being available - either use "#ifdef 
__FLT128_MAX__" within the test, or have a separate test for those cases 
and use

/* { dg-add-options float128 } */
/* { dg-require-effective-target float128 } */

in that test.  ({ dg-add-options float128 } allows _Float128 tests to be 
run in configurations that only support _Float128 with some command-line 
options.)

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: About GSOC.

[Joseph Myers]

On Wed, 8 May 2019, Tejas Joshi wrote:

> Hello.
> I can't figure out from the documentation how to add test cases in the
> testsuite and inspect the results. How can I do that? Although, Taking
> the mentioned conditions under consideration, I have made another
> patch, attached.

This patch still has problems.  You can't assume that all of sig[0] and 
sig[1] are below the 0.5 bit.  You have to allow for the 0.5 bit possibly 
being in any word of the significand, not necessarily the SIGSZ - 1 word, 
meaning you have to loop over all words of the significand.  A word 
completely below the 0.5 bit can just be checked for being 0.  A word 
containing the 0.5 bit needs checking both the bits in that word below the 
0.5 bit, and checking that the 0.5 bit is 1.

REAL_EXP (r) could be bigger than SIGNIFICAND_BITS, so you need to handle 
that case (automatically an integer) rather than computing a spurious very 
large n.

This should illustrate testcases that need adding, to cover the various 
cases of where the 0.5 bit is and where any nonzero bit below it might be 
- my suggestion is to add such tests, make sure they fail with your 
existing patch, and only then fix the implementation to make them pass.  
For some of those tests, you'll need to test long double or _Float128.  
(Use DEF_EXT_LIB_FLOATN_NX_BUILTINS in builtins.def to add the built-in 
function variants such as roundevenf128; existing round-to-integer 
functions already have such variants.)

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: About GSOC.

[Martin Jambor]

Hello Tejas,

On Wed, May 08 2019, Tejas Joshi wrote:
> Hello.
> I can't figure out from the documentation how to add test cases in the
> testsuite and inspect the results. How can I do that? Although, Taking
> the mentioned conditions under consideration, I have made another
> patch, attached.

in addition to the things already pointed out by Joseph, I have the
following comments.  But as Joseph has already pointed out, you should
also test your patch on __float128 types, so please make sure your code
gets invoked and works for something like:

    if (__builtin_roundevenf128 (0x1p64q+0.5) != (0x1p64q))
      link_error (__LINE__);


> diff --git a/gcc/builtins.def b/gcc/builtins.def
> index ef89729fd0c..e1d593a8765 100644
> --- a/gcc/builtins.def
> +++ b/gcc/builtins.def
> @@ -542,6 +542,9 @@ DEF_C99_BUILTIN        (BUILT_IN_RINTL, "rintl", BT_FN_LONGDOUBLE_LONGDOUBLE, AT
>  #define RINT_TYPE(F) BT_FN_##F##_##F
>  DEF_EXT_LIB_FLOATN_NX_BUILTINS (BUILT_IN_RINT, "rint", RINT_TYPE, ATTR_CONST_NOTHROW_LEAF_LIST)
>  #undef RINT_TYPE
> +DEF_EXT_LIB_BUILTIN    (BUILT_IN_ROUNDEVEN, "roundeven", BT_FN_DOUBLE_DOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
> +DEF_EXT_LIB_BUILTIN    (BUILT_IN_ROUNDEVENF, "roundevenf", BT_FN_FLOAT_FLOAT, ATTR_CONST_NOTHROW_LEAF_LIST)
> +DEF_EXT_LIB_BUILTIN    (BUILT_IN_ROUNDEVENL, "roundevenl", BT_FN_LONGDOUBLE_LONGDOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)

...and for the code to trigger for __builtin_roundevenf128 you have to
define this builtin function too.  The easiest way is to do it in the
same way it is done for BUILTIN_ROUND and many other functions, i.e. use
DEF_EXT_LIB_FLOATN_NX_BUILTINS.


> diff --git a/gcc/fold-const-call.c b/gcc/fold-const-call.c
> index 06a420601c0..7eafd91e9a2 100644
> --- a/gcc/fold-const-call.c
> +++ b/gcc/fold-const-call.c
> @@ -792,6 +792,14 @@ fold_const_call_ss (real_value *result, combined_fn fn,
>  	}
>        return false;
>  
> +    case CFN_BUILT_IN_ROUNDEVEN:

If you look at other cases in this switch statement, they all use
CASE_CFN_* macros.  These the get expanded to all the type variants of
the builting function, so please do the same thing and replace the case
with

    CASE_CFN_ROUNDEVEN:
    CASE_CFN_ROUNDEVEN_FN:


> +      if (!REAL_VALUE_ISNAN (*arg) || !flag_errno_math)
> +  {

Make sure you set your editor to follow the GNU coding style.  The
horizontal position of the curly braces here is incorrect.  Insisting on
coding style details may sound like excessive nit-picking but in the
long run it makes the sources much more readable.

> +    real_roundeven (result, format, arg);
> +    return true;
> +  }
> +      return false;
> +
>      CASE_CFN_LOGB:
>        return fold_const_logb (result, arg, format);
>  
> @@ -854,6 +862,9 @@ fold_const_call_ss (wide_int *result, combined_fn fn,
>        return fold_const_conversion (result, real_round, arg,
>  				    precision, format);
>  
> +    case CFN_BUILT_IN_ROUNDEVEN:

the comment about CASE_CFN_* macros applies here as well.

> +      return fold_const_conversion (result, real_roundeven, arg, precision, format);
> +
>      CASE_CFN_IRINT:
>      CASE_CFN_LRINT:
>      CASE_CFN_LLRINT:
> diff --git a/gcc/fold-const.c b/gcc/fold-const.c
> index 59cedeafd71..30c409e95bf 100644
> --- a/gcc/fold-const.c
> +++ b/gcc/fold-const.c
> @@ -329,6 +329,7 @@ negate_mathfn_p (combined_fn fn)
>      CASE_CFN_LLROUND:
>      CASE_CFN_LROUND:
>      CASE_CFN_ROUND:
> +    CASE_CFN_ROUNDEVEN:

and CASE_CFN_ROUNDEVEN_FN:

>      CASE_CFN_SIN:
>      CASE_CFN_SINH:
>      CASE_CFN_TAN:
> @@ -13060,6 +13061,8 @@ tree_call_nonnegative_warnv_p (tree type, combined_fn fn, tree arg0, tree arg1,
>      CASE_CFN_RINT_FN:
>      CASE_CFN_ROUND:
>      CASE_CFN_ROUND_FN:
> +    CASE_CFN_ROUNDEVEN:
> +    CASE_CFN_ROUNDEVEN_FN:
>      CASE_CFN_SCALB:
>      CASE_CFN_SCALBLN:
>      CASE_CFN_SCALBN:
> @@ -13583,6 +13586,8 @@ integer_valued_real_call_p (combined_fn fn, tree arg0, tree arg1, int depth)
>      CASE_CFN_RINT_FN:
>      CASE_CFN_ROUND:
>      CASE_CFN_ROUND_FN:
> +    CASE_CFN_ROUNDEVEN:
> +    CASE_CFN_ROUNDEVEN_FN:
>      CASE_CFN_TRUNC:
>      CASE_CFN_TRUNC_FN:
>        return true;
> diff --git a/gcc/real.c b/gcc/real.c
> index f822ae82d61..045dc758048 100644
> --- a/gcc/real.c
> +++ b/gcc/real.c
> @@ -5010,6 +5010,53 @@ real_round (REAL_VALUE_TYPE *r, format_helper fmt,
>      real_convert (r, fmt, r);
>  }
>  
> +/* Return true if integer part of R is even, else return false. */

If the function is supposed to work only on integer values (encoded as
REAL_VALUE_TYPE) then please write that into the function comment.

> +
> +bool
> +is_even (REAL_VALUE_TYPE *r)
> +{
> +  unsigned int n = SIGNIFICAND_BITS - REAL_EXP (r);

Otherwise, if you really wanted to make it work on integer parts of any
real number, this is clearly wrong for any value smaller than 0.5
(i.e. when REAL_EXP (r) is negative).

> +
> +  unsigned long num = ((unsigned long)1 << (n % HOST_BITS_PER_LONG));
> +
> +  if ((r->sig[SIGSZ-1] & num) == 0)
> +    return true;

I don't think you can expect that the digit you are looking for is in
the last element of sig.

> +  return false;
> +}
> +
> +/* Return true if R is halfway between two integers, else return false. */
> +
> +bool
> +is_halfway_below (const REAL_VALUE_TYPE *r)
> +{
> +  if (r->sig[0] != 0 && r->sig[1] != 0)
> +    return false;

If you try this code on the example I gave at the beginning of my email,
you will see that this condition is not met.


> +
> +  unsigned int n = SIGNIFICAND_BITS - REAL_EXP (r);

Joseph has already pointed out that you can and should bail out if
REAL_EXP (r) is negative, because then the number is in the internal
[-0.25, 0.25] or when it is too big because then it is already an
integer.

> +
> +  unsigned long num = ((unsigned long)1 << ((n - 1) % HOST_BITS_PER_LONG));
> +
> +  if (((r->sig[SIGSZ-1] & num) != 0) && ((r->sig[SIGSZ-1] & (num-1)) == 0))
> +    return true;

And he also pointed out this is wrong too, just think how 0x1p64q+0.5,
i.e. 2^64+ 2^(-1) is represented.  It just cannot fit into one 64-bit long.

Nevertheless, you are definitely on the right track and these things can
be confusing at first, so I'm looking forward to the next iteration of
the patch.

Martin

Re: About GSOC.

[Joseph Myers]

On Mon, 20 May 2019, Martin Jambor wrote:

> in addition to the things already pointed out by Joseph, I have the
> following comments.  But as Joseph has already pointed out, you should
> also test your patch on __float128 types, so please make sure your code
> gets invoked and works for something like:
> 
>     if (__builtin_roundevenf128 (0x1p64q+0.5) != (0x1p64q))
>       link_error (__LINE__);

 ... but with the f128 constant suffix not q, so it works on more 
architectures (all those with _Float128 support, not just those with older 
__float128 support).

> > +DEF_EXT_LIB_BUILTIN    (BUILT_IN_ROUNDEVEN, "roundeven", BT_FN_DOUBLE_DOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
> > +DEF_EXT_LIB_BUILTIN    (BUILT_IN_ROUNDEVENF, "roundevenf", BT_FN_FLOAT_FLOAT, ATTR_CONST_NOTHROW_LEAF_LIST)
> > +DEF_EXT_LIB_BUILTIN    (BUILT_IN_ROUNDEVENL, "roundevenl", BT_FN_LONGDOUBLE_LONGDOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
> 
> ...and for the code to trigger for __builtin_roundevenf128 you have to
> define this builtin function too.  The easiest way is to do it in the
> same way it is done for BUILTIN_ROUND and many other functions, i.e. use
> DEF_EXT_LIB_FLOATN_NX_BUILTINS.

Also note that TS 18661-1 has been merged into C2X.  I haven't yet updated 
glibc headers to reflect this, but this means a new DEF_C2X_BUILTIN should 
be added similar to DEF_C11_BUILTIN, and used for those three new 
functions, instead of DEF_EXT_LIB_BUILTIN.  (And for the strdup and 
strndup built-in functions, also added to C2X, but that's independent of 
the present project.)

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: About GSOC.

[Tejas Joshi]

Hello.
My exams are finally over and I have started to address these points now. I
intend to give my most of the time cause of holidays and will try to
consider most of the cases for the patch this time .

Thanks,
-Tejas

On Tue, 21 May 2019 at 03:18, Joseph Myers <joseph@codesourcery.com> wrote:

> On Mon, 20 May 2019, Martin Jambor wrote:
>
> > in addition to the things already pointed out by Joseph, I have the
> > following comments.  But as Joseph has already pointed out, you should
> > also test your patch on __float128 types, so please make sure your code
> > gets invoked and works for something like:
> >
> >     if (__builtin_roundevenf128 (0x1p64q+0.5) != (0x1p64q))
> >       link_error (__LINE__);
>
>  ... but with the f128 constant suffix not q, so it works on more
> architectures (all those with _Float128 support, not just those with older
> __float128 support).
>
> > > +DEF_EXT_LIB_BUILTIN    (BUILT_IN_ROUNDEVEN, "roundeven",
> BT_FN_DOUBLE_DOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
> > > +DEF_EXT_LIB_BUILTIN    (BUILT_IN_ROUNDEVENF, "roundevenf",
> BT_FN_FLOAT_FLOAT, ATTR_CONST_NOTHROW_LEAF_LIST)
> > > +DEF_EXT_LIB_BUILTIN    (BUILT_IN_ROUNDEVENL, "roundevenl",
> BT_FN_LONGDOUBLE_LONGDOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
> >
> > ...and for the code to trigger for __builtin_roundevenf128 you have to
> > define this builtin function too.  The easiest way is to do it in the
> > same way it is done for BUILTIN_ROUND and many other functions, i.e. use
> > DEF_EXT_LIB_FLOATN_NX_BUILTINS.
>
> Also note that TS 18661-1 has been merged into C2X.  I haven't yet updated
> glibc headers to reflect this, but this means a new DEF_C2X_BUILTIN should
> be added similar to DEF_C11_BUILTIN, and used for those three new
> functions, instead of DEF_EXT_LIB_BUILTIN.  (And for the strdup and
> strndup built-in functions, also added to C2X, but that's independent of
> the present project.)
>
> --
> Joseph S. Myers
> joseph@codesourcery.com
>

Re: About GSOC.

[Tejas Joshi]

Hello.
I tried to check the values for significand words using _Float128
using a test program with value larger than 64 bit.
Test program :

int main ()
{
    _Float128 x = 18446744073709551617.5;   (i.e. 2^64 + 1.5 which is
certainly longer than 64-bit)
    _Float128 y = __builtin_roundf128 (x);
}

The lower words of significand (sig[1] and sig[0] for 64-bit system)
are still being zero. I haven't included the roundevenf128 yet but
inspecting this on real_round function.
Am I missing something here?

Thanks.


On Wed, 29 May 2019 at 16:56, Tejas Joshi <tejasjoshi9673@gmail.com> wrote:
>
> Hello.
> My exams are finally over and I have started to address these points now. I intend to give my most of the time cause of holidays and will try to consider most of the cases for the patch this time .
>
> Thanks,
> -Tejas
>
> On Tue, 21 May 2019 at 03:18, Joseph Myers <joseph@codesourcery.com> wrote:
>>
>> On Mon, 20 May 2019, Martin Jambor wrote:
>>
>> > in addition to the things already pointed out by Joseph, I have the
>> > following comments.  But as Joseph has already pointed out, you should
>> > also test your patch on __float128 types, so please make sure your code
>> > gets invoked and works for something like:
>> >
>> >     if (__builtin_roundevenf128 (0x1p64q+0.5) != (0x1p64q))
>> >       link_error (__LINE__);
>>
>>  ... but with the f128 constant suffix not q, so it works on more
>> architectures (all those with _Float128 support, not just those with older
>> __float128 support).
>>
>> > > +DEF_EXT_LIB_BUILTIN    (BUILT_IN_ROUNDEVEN, "roundeven", BT_FN_DOUBLE_DOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
>> > > +DEF_EXT_LIB_BUILTIN    (BUILT_IN_ROUNDEVENF, "roundevenf", BT_FN_FLOAT_FLOAT, ATTR_CONST_NOTHROW_LEAF_LIST)
>> > > +DEF_EXT_LIB_BUILTIN    (BUILT_IN_ROUNDEVENL, "roundevenl", BT_FN_LONGDOUBLE_LONGDOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
>> >
>> > ...and for the code to trigger for __builtin_roundevenf128 you have to
>> > define this builtin function too.  The easiest way is to do it in the
>> > same way it is done for BUILTIN_ROUND and many other functions, i.e. use
>> > DEF_EXT_LIB_FLOATN_NX_BUILTINS.
>>
>> Also note that TS 18661-1 has been merged into C2X.  I haven't yet updated
>> glibc headers to reflect this, but this means a new DEF_C2X_BUILTIN should
>> be added similar to DEF_C11_BUILTIN, and used for those three new
>> functions, instead of DEF_EXT_LIB_BUILTIN.  (And for the strdup and
>> strndup built-in functions, also added to C2X, but that's independent of
>> the present project.)
>>
>> --
>> Joseph S. Myers
>> joseph@codesourcery.com

Re: About GSOC.

[Martin Jambor]

Hi,

On Thu, May 30 2019, Tejas Joshi wrote:
> Hello.
> I tried to check the values for significand words using _Float128
> using a test program with value larger than 64 bit.
> Test program :
>
> int main ()
> {
>     _Float128 x = 18446744073709551617.5;   (i.e. 2^64 + 1.5 which is
> certainly longer than 64-bit)
>     _Float128 y = __builtin_roundf128 (x);
> }

Interesting, I was also puzzled for a moment.  But notice that:

int main ()
{
    _Float128 x = 18446744073709551617.5f128;
    _Float128 y = __builtin_roundf128 (x);
}

behaves as expected... the difference is of course the suffix pegged to
the literal constant (see
https://gcc.gnu.org/onlinedocs/gcc-9.1.0/gcc/Floating-Types.html).

I would also expect GCC to use a larger type if a constant does not fit
into a double, but apparently that does not happen.  I would have to
check but it is probably the right behavior according to the standard.

>
> The lower words of significand (sig[1] and sig[0] for 64-bit system)
> are still being zero. I haven't included the roundevenf128 yet but
> inspecting this on real_round function.

I figured out what was going on when I realized that in your testcase,
sig[0] was equal to 0x8000000000000000 and so some precision has been
lost.  Then it was easy to guess that it was because it was represented
in a narrower type.

Hope this helps,

Martin

Re: About GSOC.

[Segher Boessenkool]

On Thu, May 30, 2019 at 07:08:45PM +0200, Martin Jambor wrote:
> Interesting, I was also puzzled for a moment.  But notice that:
> 
> int main ()
> {
>     _Float128 x = 18446744073709551617.5f128;
>     _Float128 y = __builtin_roundf128 (x);
> }
> 
> behaves as expected... the difference is of course the suffix pegged to
> the literal constant (see
> https://gcc.gnu.org/onlinedocs/gcc-9.1.0/gcc/Floating-Types.html).
> 
> I would also expect GCC to use a larger type if a constant does not fit
> into a double, but apparently that does not happen.  I would have to
> check but it is probably the right behavior according to the standard.

6.4.4.2/4: "An unsuffixed floating constant has type double."  I don't
think your suggestion would be okay?


Segher

Re: About GSOC.

[Martin Jambor]

On Thu, May 30 2019, Segher Boessenkool wrote:
> On Thu, May 30, 2019 at 07:08:45PM +0200, Martin Jambor wrote:
>> Interesting, I was also puzzled for a moment.  But notice that:
>> 
>> int main ()
>> {
>>     _Float128 x = 18446744073709551617.5f128;
>>     _Float128 y = __builtin_roundf128 (x);
>> }
>> 
>> behaves as expected... the difference is of course the suffix pegged to
>> the literal constant (see
>> https://gcc.gnu.org/onlinedocs/gcc-9.1.0/gcc/Floating-Types.html).
>> 
>> I would also expect GCC to use a larger type if a constant does not fit
>> into a double, but apparently that does not happen.  I would have to
>> check but it is probably the right behavior according to the standard.
>
> 6.4.4.2/4: "An unsuffixed floating constant has type double."  I don't
> think your suggestion would be okay?

Sorry if I was not clear but I was definitely not suggesting that we
change this (or anything).  I wrote that I was also surprised but
believed that GCC was doing the correct thing.

Thanks for pointing out where exactly the standard says what has to be
done though.

Martin

Re: About GSOC.

[Tejas Joshi]

[-- Attachment #1: Type: text/plain, Size: 2379 bytes --]

Hello.
The f128 suffix worked. Based on all the corrections you all pointed
out, I have created another patch. I think I took most of the things
under consideration but please mention if I missed anything. The
following test cases were inspected with this patch. I am not sure if
the second test case is supposed to be carried out like I did.

Thanks,
-Tejas

/* { dg-do link } */

extern int link_error (int);

#define TEST(FN, VALUE, RESULT) \
  if (__builtin_##FN (VALUE) != RESULT) link_error (__LINE__);

int
main (void)
{
  TEST(roundeven,  0, 0);
  TEST(roundeven,  0.5, 0);
  TEST(roundeven,  -0.5, 0);
  TEST(roundeven,  6, 6);
  TEST(roundeven,  -8, -8);
  TEST(roundeven,  2.5, 2);
  TEST(roundeven,  3.5, 4);
  TEST(roundeven,  -1.5, -2);
  TEST(roundeven,  3.499, 3);
  TEST(roundeven,  3.501, 4);

  return 0;
}

second test case :

/* { dg-do link } */
/* { dg-add-options float128 } */
/* { dg-require-effective-target float128 } */

extern int link_error (int);

#define TEST(FN, VALUE, RESULT) \
  if (__builtin_##FN (VALUE) != RESULT) link_error (__LINE__);

int
main (void)
{
  TEST(roundevenf128,  (0x1p64+0.5), (0x1p64));

  return 0;
}

On Fri, 31 May 2019 at 15:41, Martin Jambor <mjambor@suse.cz> wrote:
>
> On Thu, May 30 2019, Segher Boessenkool wrote:
> > On Thu, May 30, 2019 at 07:08:45PM +0200, Martin Jambor wrote:
> >> Interesting, I was also puzzled for a moment.  But notice that:
> >>
> >> int main ()
> >> {
> >>     _Float128 x = 18446744073709551617.5f128;
> >>     _Float128 y = __builtin_roundf128 (x);
> >> }
> >>
> >> behaves as expected... the difference is of course the suffix pegged to
> >> the literal constant (see
> >> https://gcc.gnu.org/onlinedocs/gcc-9.1.0/gcc/Floating-Types.html).
> >>
> >> I would also expect GCC to use a larger type if a constant does not fit
> >> into a double, but apparently that does not happen.  I would have to
> >> check but it is probably the right behavior according to the standard.
> >
> > 6.4.4.2/4: "An unsuffixed floating constant has type double."  I don't
> > think your suggestion would be okay?
>
> Sorry if I was not clear but I was definitely not suggesting that we
> change this (or anything).  I wrote that I was also surprised but
> believed that GCC was doing the correct thing.
>
> Thanks for pointing out where exactly the standard says what has to be
> done though.
>
> Martin

[-- Attachment #2: roundeven.patch --]
[-- Type: text/x-patch, Size: 7073 bytes --]

diff --git a/gcc/builtins.c b/gcc/builtins.c
index 25e01e4092b..0b2d6bf82f9 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -2067,6 +2067,7 @@ mathfn_built_in_2 (tree type, combined_fn fn)
     CASE_MATHFN (REMQUO)
     CASE_MATHFN_FLOATN (RINT)
     CASE_MATHFN_FLOATN (ROUND)
+    CASE_MATHFN (ROUNDEVEN)
     CASE_MATHFN (SCALB)
     CASE_MATHFN (SCALBLN)
     CASE_MATHFN (SCALBN)
diff --git a/gcc/builtins.def b/gcc/builtins.def
index ef89729fd0c..f284a3eae3b 100644
--- a/gcc/builtins.def
+++ b/gcc/builtins.def
@@ -542,12 +542,18 @@ DEF_C99_BUILTIN        (BUILT_IN_RINTL, "rintl", BT_FN_LONGDOUBLE_LONGDOUBLE, AT
 #define RINT_TYPE(F) BT_FN_##F##_##F
 DEF_EXT_LIB_FLOATN_NX_BUILTINS (BUILT_IN_RINT, "rint", RINT_TYPE, ATTR_CONST_NOTHROW_LEAF_LIST)
 #undef RINT_TYPE
+DEF_EXT_LIB_BUILTIN    (BUILT_IN_ROUNDEVEN, "roundeven", BT_FN_DOUBLE_DOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
+DEF_EXT_LIB_BUILTIN    (BUILT_IN_ROUNDEVENF, "roundevenf", BT_FN_FLOAT_FLOAT, ATTR_CONST_NOTHROW_LEAF_LIST)
+DEF_EXT_LIB_BUILTIN    (BUILT_IN_ROUNDEVENL, "roundevenl", BT_FN_LONGDOUBLE_LONGDOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_C99_BUILTIN        (BUILT_IN_ROUND, "round", BT_FN_DOUBLE_DOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_C99_BUILTIN        (BUILT_IN_ROUNDF, "roundf", BT_FN_FLOAT_FLOAT, ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_C99_BUILTIN        (BUILT_IN_ROUNDL, "roundl", BT_FN_LONGDOUBLE_LONGDOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
 #define ROUND_TYPE(F) BT_FN_##F##_##F
 DEF_EXT_LIB_FLOATN_NX_BUILTINS (BUILT_IN_ROUND, "round", ROUND_TYPE, ATTR_CONST_NOTHROW_LEAF_LIST)
 #undef ROUND_TYPE
+#define ROUNDEVEN_TYPE(F) BT_FN_##F##_##F
+DEF_EXT_LIB_FLOATN_NX_BUILTINS (BUILT_IN_ROUNDEVEN, "roundeven", ROUNDEVEN_TYPE, ATTR_CONST_NOTHROW_LEAF_LIST)
+#undef ROUNDEVEN_TYPE
 DEF_EXT_LIB_BUILTIN    (BUILT_IN_SCALB, "scalb", BT_FN_DOUBLE_DOUBLE_DOUBLE, ATTR_MATHFN_FPROUNDING_ERRNO)
 DEF_EXT_LIB_BUILTIN    (BUILT_IN_SCALBF, "scalbf", BT_FN_FLOAT_FLOAT_FLOAT, ATTR_MATHFN_FPROUNDING_ERRNO)
 DEF_EXT_LIB_BUILTIN    (BUILT_IN_SCALBL, "scalbl", BT_FN_LONGDOUBLE_LONGDOUBLE_LONGDOUBLE, ATTR_MATHFN_FPROUNDING_ERRNO)
diff --git a/gcc/fold-const-call.c b/gcc/fold-const-call.c
index 06a420601c0..54315d057a2 100644
--- a/gcc/fold-const-call.c
+++ b/gcc/fold-const-call.c
@@ -792,6 +792,15 @@ fold_const_call_ss (real_value *result, combined_fn fn,
 	}
       return false;
 
+    CASE_CFN_ROUNDEVEN:
+    CASE_CFN_ROUNDEVEN_FN:
+      if (!REAL_VALUE_ISNAN (*arg) || !flag_errno_math)
+  {
+    real_roundeven (result, format, arg);
+    return true;
+  }
+      return false;
+
     CASE_CFN_LOGB:
       return fold_const_logb (result, arg, format);
 
@@ -854,6 +863,10 @@ fold_const_call_ss (wide_int *result, combined_fn fn,
       return fold_const_conversion (result, real_round, arg,
 				    precision, format);
 
+    CASE_CFN_ROUNDEVEN:
+    CASE_CFN_ROUNDEVEN_FN:
+      return fold_const_conversion (result, real_roundeven, arg, precision, format);
+
     CASE_CFN_IRINT:
     CASE_CFN_LRINT:
     CASE_CFN_LLRINT:
diff --git a/gcc/fold-const.c b/gcc/fold-const.c
index 59cedeafd71..ab96f197d5f 100644
--- a/gcc/fold-const.c
+++ b/gcc/fold-const.c
@@ -329,6 +329,8 @@ negate_mathfn_p (combined_fn fn)
     CASE_CFN_LLROUND:
     CASE_CFN_LROUND:
     CASE_CFN_ROUND:
+    CASE_CFN_ROUNDEVEN:
+    CASE_CFN_ROUNDEVEN_FN:
     CASE_CFN_SIN:
     CASE_CFN_SINH:
     CASE_CFN_TAN:
@@ -13060,6 +13062,8 @@ tree_call_nonnegative_warnv_p (tree type, combined_fn fn, tree arg0, tree arg1,
     CASE_CFN_RINT_FN:
     CASE_CFN_ROUND:
     CASE_CFN_ROUND_FN:
+    CASE_CFN_ROUNDEVEN:
+    CASE_CFN_ROUNDEVEN_FN:
     CASE_CFN_SCALB:
     CASE_CFN_SCALBLN:
     CASE_CFN_SCALBN:
@@ -13583,6 +13587,8 @@ integer_valued_real_call_p (combined_fn fn, tree arg0, tree arg1, int depth)
     CASE_CFN_RINT_FN:
     CASE_CFN_ROUND:
     CASE_CFN_ROUND_FN:
+    CASE_CFN_ROUNDEVEN:
+    CASE_CFN_ROUNDEVEN_FN:
     CASE_CFN_TRUNC:
     CASE_CFN_TRUNC_FN:
       return true;
diff --git a/gcc/real.c b/gcc/real.c
index f822ae82d61..541fa6b6e43 100644
--- a/gcc/real.c
+++ b/gcc/real.c
@@ -5010,6 +5010,80 @@ real_round (REAL_VALUE_TYPE *r, format_helper fmt,
     real_convert (r, fmt, r);
 }
 
+/* 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;
+
+  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;
+}
+
+/* Return true if R is halfway between two integers, else return false. */
+
+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);
+
+    if (((r->sig[SIGSZ-1] & temp) != 0) && ((r->sig[SIGSZ-1] & (temp-1)) == 0))
+      return true;
+    else
+      return false;
+  }
+
+  else if (REAL_EXP (r) < SIGNIFICAND_BITS)
+  {
+    unsigned int n = SIGNIFICAND_BITS - REAL_EXP (r);
+    int i, w = n / HOST_BITS_PER_LONG;
+
+    for (i = 0; i < w; ++i)
+    {
+      if (r->sig[i] != 0)
+        return false;
+    }
+
+    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;
+  }
+  return false;
+}
+
+/* Round X to nearest integer, rounding halfway cases towards even. */
+
+void
+real_roundeven (REAL_VALUE_TYPE *r, format_helper fmt,
+		const REAL_VALUE_TYPE *x)
+{
+  if (is_halfway_below (x))
+  {
+    do_add (r, x, &dconsthalf, x->sign);
+    if (!is_even (r))
+      do_add (r, r, &dconstm1, x->sign);
+  }
+  else
+    real_round (r, fmt, x);
+}
+
 /* Set the sign of R to the sign of X.  */
 
 void
diff --git a/gcc/real.h b/gcc/real.h
index 0ce42565708..ebe66d234af 100644
--- a/gcc/real.h
+++ b/gcc/real.h
@@ -41,11 +41,18 @@ struct GTY(()) real_value {
      sure they're packed together, otherwise REAL_VALUE_TYPE_SIZE will
      be miscomputed.  */
   unsigned int /* ENUM_BITFIELD (real_value_class) */ cl : 2;
+  /* 1 if number is decimal floating point */
   unsigned int decimal : 1;
+  /* 1 if number is negative */
   unsigned int sign : 1;
+  /* 1 if number is signalling */
   unsigned int signalling : 1;
+  /* 1 if number is canonical
+  All are generally used for handling cases in real.c */
   unsigned int canonical : 1;
+  /* unbiased exponent of the number */
   unsigned int uexp : EXP_BITS;
+  /* significand of the number */
   unsigned long sig[SIGSZ];
 };
 
@@ -499,6 +506,8 @@ extern void real_ceil (REAL_VALUE_TYPE *, format_helper,
 		       const REAL_VALUE_TYPE *);
 extern void real_round (REAL_VALUE_TYPE *, format_helper,
 			const REAL_VALUE_TYPE *);
+extern void real_roundeven (REAL_VALUE_TYPE *, format_helper,
+      const REAL_VALUE_TYPE *);
 
 /* Set the sign of R to the sign of X.  */
 extern void real_copysign (REAL_VALUE_TYPE *, const REAL_VALUE_TYPE *);

Re: About GSOC.

[Joseph Myers]

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

Re: About GSOC.

[Tejas Joshi]

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

Re: About GSOC.

[Tejas Joshi]

[-- Attachment #1: Type: text/plain, Size: 6814 bytes --]

Hello.
Following patch is tested on following test cases in the testsuite and
tests did not fail. I have considered most of the test cases this time
hopefully.

/* { dg-do link } */

extern int link_error (int);

#define TEST(FN, VALUE, RESULT) \
  if (__builtin_##FN (VALUE) != RESULT) link_error (__LINE__);

int
main (void)
{
  TEST(roundeven,  0, 0);
  TEST(roundeven,  0.5, 0);
  TEST(roundeven,  -0.5, 0);
  TEST(roundeven,  6, 6);
  TEST(roundeven,  -8, -8);
  TEST(roundeven,  2.5, 2);
  TEST(roundeven,  3.5, 4);
  TEST(roundeven,  -1.5, -2);
  TEST(roundeven,  3.499, 3);
  TEST(roundeven,  3.501, 4);

  return 0;
}
_Float128 test cases :

/* { dg-do link } */
/* { dg-add-options float128 } */
/* { dg-require-effective-target float128 } */

extern int link_error (int);

#define TEST(FN, VALUE, RESULT) \
  if (__builtin_##FN##f128 (VALUE) != RESULT) link_error (__LINE__);

int
main (void)
{
  TEST(roundeven,  (0x1p64+0.5f128), (0x1p64f128));
  TEST(roundeven,  (0x1p63+0.5f128), (0x1p63f128));
  TEST(roundeven,  (0x1p63-0.5f128), (0x1p63f128));
  TEST(roundeven,  (0x1p64-0.5f128), (0x1p64f128));
  TEST(roundeven,  (0x1p64+0.501f128), (0x1p64+1.0f128));
  TEST(roundeven,  (0x1.C00000000000039A5653p1f128), (0x1p2f128))
// the hex number is 3.50000000...01 which would fail for roundeven
but not for f128
  return 0;
}

Thanks,
-Tejas

On Tue, 4 Jun 2019 at 12:38, Tejas Joshi <tejasjoshi9673@gmail.com> wrote:
>
> 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

[-- Attachment #2: roundeven.patch --]
[-- Type: text/x-patch, Size: 8927 bytes --]

diff --git a/gcc/builtins.c b/gcc/builtins.c
index 25e01e4092b..0b2d6bf82f9 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -2067,6 +2067,7 @@ mathfn_built_in_2 (tree type, combined_fn fn)
     CASE_MATHFN (REMQUO)
     CASE_MATHFN_FLOATN (RINT)
     CASE_MATHFN_FLOATN (ROUND)
+    CASE_MATHFN (ROUNDEVEN)
     CASE_MATHFN (SCALB)
     CASE_MATHFN (SCALBLN)
     CASE_MATHFN (SCALBN)
diff --git a/gcc/builtins.def b/gcc/builtins.def
index ef89729fd0c..f284a3eae3b 100644
--- a/gcc/builtins.def
+++ b/gcc/builtins.def
@@ -542,12 +542,18 @@ DEF_C99_BUILTIN        (BUILT_IN_RINTL, "rintl", BT_FN_LONGDOUBLE_LONGDOUBLE, AT
 #define RINT_TYPE(F) BT_FN_##F##_##F
 DEF_EXT_LIB_FLOATN_NX_BUILTINS (BUILT_IN_RINT, "rint", RINT_TYPE, ATTR_CONST_NOTHROW_LEAF_LIST)
 #undef RINT_TYPE
+DEF_EXT_LIB_BUILTIN    (BUILT_IN_ROUNDEVEN, "roundeven", BT_FN_DOUBLE_DOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
+DEF_EXT_LIB_BUILTIN    (BUILT_IN_ROUNDEVENF, "roundevenf", BT_FN_FLOAT_FLOAT, ATTR_CONST_NOTHROW_LEAF_LIST)
+DEF_EXT_LIB_BUILTIN    (BUILT_IN_ROUNDEVENL, "roundevenl", BT_FN_LONGDOUBLE_LONGDOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_C99_BUILTIN        (BUILT_IN_ROUND, "round", BT_FN_DOUBLE_DOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_C99_BUILTIN        (BUILT_IN_ROUNDF, "roundf", BT_FN_FLOAT_FLOAT, ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_C99_BUILTIN        (BUILT_IN_ROUNDL, "roundl", BT_FN_LONGDOUBLE_LONGDOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
 #define ROUND_TYPE(F) BT_FN_##F##_##F
 DEF_EXT_LIB_FLOATN_NX_BUILTINS (BUILT_IN_ROUND, "round", ROUND_TYPE, ATTR_CONST_NOTHROW_LEAF_LIST)
 #undef ROUND_TYPE
+#define ROUNDEVEN_TYPE(F) BT_FN_##F##_##F
+DEF_EXT_LIB_FLOATN_NX_BUILTINS (BUILT_IN_ROUNDEVEN, "roundeven", ROUNDEVEN_TYPE, ATTR_CONST_NOTHROW_LEAF_LIST)
+#undef ROUNDEVEN_TYPE
 DEF_EXT_LIB_BUILTIN    (BUILT_IN_SCALB, "scalb", BT_FN_DOUBLE_DOUBLE_DOUBLE, ATTR_MATHFN_FPROUNDING_ERRNO)
 DEF_EXT_LIB_BUILTIN    (BUILT_IN_SCALBF, "scalbf", BT_FN_FLOAT_FLOAT_FLOAT, ATTR_MATHFN_FPROUNDING_ERRNO)
 DEF_EXT_LIB_BUILTIN    (BUILT_IN_SCALBL, "scalbl", BT_FN_LONGDOUBLE_LONGDOUBLE_LONGDOUBLE, ATTR_MATHFN_FPROUNDING_ERRNO)
diff --git a/gcc/fold-const-call.c b/gcc/fold-const-call.c
index 06a420601c0..54315d057a2 100644
--- a/gcc/fold-const-call.c
+++ b/gcc/fold-const-call.c
@@ -792,6 +792,15 @@ fold_const_call_ss (real_value *result, combined_fn fn,
 	}
       return false;
 
+    CASE_CFN_ROUNDEVEN:
+    CASE_CFN_ROUNDEVEN_FN:
+      if (!REAL_VALUE_ISNAN (*arg) || !flag_errno_math)
+  {
+    real_roundeven (result, format, arg);
+    return true;
+  }
+      return false;
+
     CASE_CFN_LOGB:
       return fold_const_logb (result, arg, format);
 
@@ -854,6 +863,10 @@ fold_const_call_ss (wide_int *result, combined_fn fn,
       return fold_const_conversion (result, real_round, arg,
 				    precision, format);
 
+    CASE_CFN_ROUNDEVEN:
+    CASE_CFN_ROUNDEVEN_FN:
+      return fold_const_conversion (result, real_roundeven, arg, precision, format);
+
     CASE_CFN_IRINT:
     CASE_CFN_LRINT:
     CASE_CFN_LLRINT:
diff --git a/gcc/fold-const.c b/gcc/fold-const.c
index 59cedeafd71..ab96f197d5f 100644
--- a/gcc/fold-const.c
+++ b/gcc/fold-const.c
@@ -329,6 +329,8 @@ negate_mathfn_p (combined_fn fn)
     CASE_CFN_LLROUND:
     CASE_CFN_LROUND:
     CASE_CFN_ROUND:
+    CASE_CFN_ROUNDEVEN:
+    CASE_CFN_ROUNDEVEN_FN:
     CASE_CFN_SIN:
     CASE_CFN_SINH:
     CASE_CFN_TAN:
@@ -13060,6 +13062,8 @@ tree_call_nonnegative_warnv_p (tree type, combined_fn fn, tree arg0, tree arg1,
     CASE_CFN_RINT_FN:
     CASE_CFN_ROUND:
     CASE_CFN_ROUND_FN:
+    CASE_CFN_ROUNDEVEN:
+    CASE_CFN_ROUNDEVEN_FN:
     CASE_CFN_SCALB:
     CASE_CFN_SCALBLN:
     CASE_CFN_SCALBN:
@@ -13583,6 +13587,8 @@ integer_valued_real_call_p (combined_fn fn, tree arg0, tree arg1, int depth)
     CASE_CFN_RINT_FN:
     CASE_CFN_ROUND:
     CASE_CFN_ROUND_FN:
+    CASE_CFN_ROUNDEVEN:
+    CASE_CFN_ROUNDEVEN_FN:
     CASE_CFN_TRUNC:
     CASE_CFN_TRUNC_FN:
       return true;
diff --git a/gcc/internal-fn.def b/gcc/internal-fn.def
index cda314e1121..b89918815f9 100644
--- a/gcc/internal-fn.def
+++ b/gcc/internal-fn.def
@@ -224,6 +224,7 @@ DEF_INTERNAL_FLT_FLOATN_FN (FLOOR, ECF_CONST, floor, unary)
 DEF_INTERNAL_FLT_FLOATN_FN (NEARBYINT, ECF_CONST, nearbyint, unary)
 DEF_INTERNAL_FLT_FLOATN_FN (RINT, ECF_CONST, rint, unary)
 DEF_INTERNAL_FLT_FLOATN_FN (ROUND, ECF_CONST, round, unary)
+DEF_INTERNAL_FLT_FLOATN_FN (ROUNDEVEN, ECF_CONST, roundeven, unary)
 DEF_INTERNAL_FLT_FLOATN_FN (TRUNC, ECF_CONST, btrunc, unary)
 
 /* Binary math functions.  */
diff --git a/gcc/match.pd b/gcc/match.pd
index 7cc2374ffeb..fa18b499162 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -4229,7 +4229,7 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
  (abs @0))
 
 /* trunc(trunc(x)) -> trunc(x), etc.  */
-(for fns (TRUNC_ALL FLOOR_ALL CEIL_ALL ROUND_ALL NEARBYINT_ALL RINT_ALL)
+(for fns (TRUNC_ALL FLOOR_ALL CEIL_ALL ROUND_ALL BUILT_IN_ROUNDEVEN NEARBYINT_ALL RINT_ALL)
  (simplify
   (fns (fns @0))
   (fns @0)))
diff --git a/gcc/optabs.def b/gcc/optabs.def
index 5a67f5eed5e..eb9e22acd8f 100644
--- a/gcc/optabs.def
+++ b/gcc/optabs.def
@@ -267,6 +267,7 @@ OPTAB_D (fnms_optab, "fnms$a4")
 
 OPTAB_D (rint_optab, "rint$a2")
 OPTAB_D (round_optab, "round$a2")
+OPTAB_D (roundeven_optab, "roundeven$a2")
 OPTAB_D (floor_optab, "floor$a2")
 OPTAB_D (ceil_optab, "ceil$a2")
 OPTAB_D (btrunc_optab, "btrunc$a2")
diff --git a/gcc/real.c b/gcc/real.c
index f822ae82d61..aee11e52dd4 100644
--- a/gcc/real.c
+++ b/gcc/real.c
@@ -5010,6 +5010,96 @@ real_round (REAL_VALUE_TYPE *r, format_helper fmt,
     real_convert (r, fmt, r);
 }
 
+/* Return true including 0 if integer part of R is even, else return false. */
+
+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);
+
+  /* For (-1,1) including 0, number is even. */
+  if (REAL_EXP (r) <= 0)
+    return true;
+
+  /* Check lowest bit, if not set, return true. */
+  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;
+  }
+
+  else if (REAL_EXP (r) > SIGNIFICAND_BITS)
+    return true;
+
+  return false;
+}
+
+/* Return true if R is halfway between two integers, else return false. */
+
+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;
+    }
+
+    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;
+  }
+  return false;
+}
+
+/* Round X to nearest integer, rounding halfway cases towards even. */
+
+void
+real_roundeven (REAL_VALUE_TYPE *r, format_helper fmt,
+		const REAL_VALUE_TYPE *x)
+{
+  if (is_halfway_below (x))
+  {
+    do_add (r, x, &dconsthalf, x->sign);
+    if (!is_even (r))
+      do_add (r, r, &dconstm1, x->sign);
+    if (fmt)
+      real_convert (r, fmt, r);
+  }
+  else
+    real_round (r, fmt, x);
+}
+
 /* Set the sign of R to the sign of X.  */
 
 void
diff --git a/gcc/real.h b/gcc/real.h
index 0ce42565708..ebe66d234af 100644
--- a/gcc/real.h
+++ b/gcc/real.h
@@ -41,11 +41,18 @@ struct GTY(()) real_value {
      sure they're packed together, otherwise REAL_VALUE_TYPE_SIZE will
      be miscomputed.  */
   unsigned int /* ENUM_BITFIELD (real_value_class) */ cl : 2;
+  /* 1 if number is decimal floating point */
   unsigned int decimal : 1;
+  /* 1 if number is negative */
   unsigned int sign : 1;
+  /* 1 if number is signalling */
   unsigned int signalling : 1;
+  /* 1 if number is canonical
+  All are generally used for handling cases in real.c */
   unsigned int canonical : 1;
+  /* unbiased exponent of the number */
   unsigned int uexp : EXP_BITS;
+  /* significand of the number */
   unsigned long sig[SIGSZ];
 };
 
@@ -499,6 +506,8 @@ extern void real_ceil (REAL_VALUE_TYPE *, format_helper,
 		       const REAL_VALUE_TYPE *);
 extern void real_round (REAL_VALUE_TYPE *, format_helper,
 			const REAL_VALUE_TYPE *);
+extern void real_roundeven (REAL_VALUE_TYPE *, format_helper,
+      const REAL_VALUE_TYPE *);
 
 /* Set the sign of R to the sign of X.  */
 extern void real_copysign (REAL_VALUE_TYPE *, const REAL_VALUE_TYPE *);

Re: About GSOC.

[Joseph Myers]

On Tue, 4 Jun 2019, Tejas Joshi wrote:

> 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);

I'd suggest making the comment above the function be clear about what 
classes of arguments are or are not valid, and then you don't need a 
comment on the assertions.

Is REAL_EXP meaningful for rvc_zero?  If not, you should check for 
rvc_zero and handle it appropriately before doing anything checking 
REAL_EXP.

> > 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?

I don't understand your question.  The "sig" array contains 
SIGNIFICAND_BITS bits.  The most significant one has value 2^(REAL_EXP-1) 
and thus the least significant one has value 
2^(REAL_EXP-SIGNIFICAND_BITS).  The ones we care about for the present 
purposes are the bit with value 1 (to tell whether an integer part is even 
or odd), the bit with value 0.5 and all the bits lower than that (to tell 
whether the fractional part is exactly 0.5 or not).

> 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?

That still seems wrong.

For testing for a halfway value you don't care about the bit with value 1.  
You do care about the bit with value 0.5, and you do care about the lower 
bits.

So you should probably set n = SIGNIFICAND_BITS - REAL_EXP (r) - 1 (under 
a conditional with < not <=; if REAL_EXP (r) == SIGNIFICAND_BITS, the 
least significant bit has value 1 and the number must be an integer).  
That way, n is the bit position of the bit with value 0.5.  Then you can 
compute w from n without special casing to get the word position of the 
bit with value 0.5.  For the words below w you check they are entirely 0.  
For word w you need to check both that bit n is 1 and the lower bits are 
0.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: About GSOC.

[Tejas Joshi]

[-- Attachment #1: Type: text/plain, Size: 3387 bytes --]

Hello.
I have created another patch which addresses the above points,
attached herewith.

> a conditional with < not <=; if REAL_EXP (r) == SIGNIFICAND_BITS, the
> least significant bit has value 1 and the number must be an integer).

The number is integer because of the whole word spaces is occupied by
integer part?
Also, why would the least significant bit will have value 1 if
REAL_EXP (r) == SIGNIFICAND_BITS, as it only concerns with 2^0th
position (even or odd)?

Thanks,
-Tejas


On Thu, 6 Jun 2019 at 22:13, Joseph Myers <joseph@codesourcery.com> wrote:
>
> On Tue, 4 Jun 2019, Tejas Joshi wrote:
>
> > 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);
>
> I'd suggest making the comment above the function be clear about what
> classes of arguments are or are not valid, and then you don't need a
> comment on the assertions.
>
> Is REAL_EXP meaningful for rvc_zero?  If not, you should check for
> rvc_zero and handle it appropriately before doing anything checking
> REAL_EXP.
>
> > > 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?
>
> I don't understand your question.  The "sig" array contains
> SIGNIFICAND_BITS bits.  The most significant one has value 2^(REAL_EXP-1)
> and thus the least significant one has value
> 2^(REAL_EXP-SIGNIFICAND_BITS).  The ones we care about for the present
> purposes are the bit with value 1 (to tell whether an integer part is even
> or odd), the bit with value 0.5 and all the bits lower than that (to tell
> whether the fractional part is exactly 0.5 or not).
>
> > 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?
>
> That still seems wrong.
>
> For testing for a halfway value you don't care about the bit with value 1.
> You do care about the bit with value 0.5, and you do care about the lower
> bits.
>
> So you should probably set n = SIGNIFICAND_BITS - REAL_EXP (r) - 1 (under
> a conditional with < not <=; if REAL_EXP (r) == SIGNIFICAND_BITS, the
> least significant bit has value 1 and the number must be an integer).
> That way, n is the bit position of the bit with value 0.5.  Then you can
> compute w from n without special casing to get the word position of the
> bit with value 0.5.  For the words below w you check they are entirely 0.
> For word w you need to check both that bit n is 1 and the lower bits are
> 0.
>
> --
> Joseph S. Myers
> joseph@codesourcery.com

[-- Attachment #2: roundeven1.patch --]
[-- Type: text/x-patch, Size: 10554 bytes --]

diff --git a/gcc/builtins.c b/gcc/builtins.c
index 25e01e4092b..0b2d6bf82f9 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -2067,6 +2067,7 @@ mathfn_built_in_2 (tree type, combined_fn fn)
     CASE_MATHFN (REMQUO)
     CASE_MATHFN_FLOATN (RINT)
     CASE_MATHFN_FLOATN (ROUND)
+    CASE_MATHFN (ROUNDEVEN)
     CASE_MATHFN (SCALB)
     CASE_MATHFN (SCALBLN)
     CASE_MATHFN (SCALBN)
diff --git a/gcc/builtins.def b/gcc/builtins.def
index ef89729fd0c..f284a3eae3b 100644
--- a/gcc/builtins.def
+++ b/gcc/builtins.def
@@ -542,12 +542,18 @@ DEF_C99_BUILTIN        (BUILT_IN_RINTL, "rintl", BT_FN_LONGDOUBLE_LONGDOUBLE, AT
 #define RINT_TYPE(F) BT_FN_##F##_##F
 DEF_EXT_LIB_FLOATN_NX_BUILTINS (BUILT_IN_RINT, "rint", RINT_TYPE, ATTR_CONST_NOTHROW_LEAF_LIST)
 #undef RINT_TYPE
+DEF_EXT_LIB_BUILTIN    (BUILT_IN_ROUNDEVEN, "roundeven", BT_FN_DOUBLE_DOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
+DEF_EXT_LIB_BUILTIN    (BUILT_IN_ROUNDEVENF, "roundevenf", BT_FN_FLOAT_FLOAT, ATTR_CONST_NOTHROW_LEAF_LIST)
+DEF_EXT_LIB_BUILTIN    (BUILT_IN_ROUNDEVENL, "roundevenl", BT_FN_LONGDOUBLE_LONGDOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_C99_BUILTIN        (BUILT_IN_ROUND, "round", BT_FN_DOUBLE_DOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_C99_BUILTIN        (BUILT_IN_ROUNDF, "roundf", BT_FN_FLOAT_FLOAT, ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_C99_BUILTIN        (BUILT_IN_ROUNDL, "roundl", BT_FN_LONGDOUBLE_LONGDOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
 #define ROUND_TYPE(F) BT_FN_##F##_##F
 DEF_EXT_LIB_FLOATN_NX_BUILTINS (BUILT_IN_ROUND, "round", ROUND_TYPE, ATTR_CONST_NOTHROW_LEAF_LIST)
 #undef ROUND_TYPE
+#define ROUNDEVEN_TYPE(F) BT_FN_##F##_##F
+DEF_EXT_LIB_FLOATN_NX_BUILTINS (BUILT_IN_ROUNDEVEN, "roundeven", ROUNDEVEN_TYPE, ATTR_CONST_NOTHROW_LEAF_LIST)
+#undef ROUNDEVEN_TYPE
 DEF_EXT_LIB_BUILTIN    (BUILT_IN_SCALB, "scalb", BT_FN_DOUBLE_DOUBLE_DOUBLE, ATTR_MATHFN_FPROUNDING_ERRNO)
 DEF_EXT_LIB_BUILTIN    (BUILT_IN_SCALBF, "scalbf", BT_FN_FLOAT_FLOAT_FLOAT, ATTR_MATHFN_FPROUNDING_ERRNO)
 DEF_EXT_LIB_BUILTIN    (BUILT_IN_SCALBL, "scalbl", BT_FN_LONGDOUBLE_LONGDOUBLE_LONGDOUBLE, ATTR_MATHFN_FPROUNDING_ERRNO)
diff --git a/gcc/fold-const-call.c b/gcc/fold-const-call.c
index 06a420601c0..54315d057a2 100644
--- a/gcc/fold-const-call.c
+++ b/gcc/fold-const-call.c
@@ -792,6 +792,15 @@ fold_const_call_ss (real_value *result, combined_fn fn,
 	}
       return false;
 
+    CASE_CFN_ROUNDEVEN:
+    CASE_CFN_ROUNDEVEN_FN:
+      if (!REAL_VALUE_ISNAN (*arg) || !flag_errno_math)
+  {
+    real_roundeven (result, format, arg);
+    return true;
+  }
+      return false;
+
     CASE_CFN_LOGB:
       return fold_const_logb (result, arg, format);
 
@@ -854,6 +863,10 @@ fold_const_call_ss (wide_int *result, combined_fn fn,
       return fold_const_conversion (result, real_round, arg,
 				    precision, format);
 
+    CASE_CFN_ROUNDEVEN:
+    CASE_CFN_ROUNDEVEN_FN:
+      return fold_const_conversion (result, real_roundeven, arg, precision, format);
+
     CASE_CFN_IRINT:
     CASE_CFN_LRINT:
     CASE_CFN_LLRINT:
diff --git a/gcc/fold-const.c b/gcc/fold-const.c
index 59cedeafd71..ab96f197d5f 100644
--- a/gcc/fold-const.c
+++ b/gcc/fold-const.c
@@ -329,6 +329,8 @@ negate_mathfn_p (combined_fn fn)
     CASE_CFN_LLROUND:
     CASE_CFN_LROUND:
     CASE_CFN_ROUND:
+    CASE_CFN_ROUNDEVEN:
+    CASE_CFN_ROUNDEVEN_FN:
     CASE_CFN_SIN:
     CASE_CFN_SINH:
     CASE_CFN_TAN:
@@ -13060,6 +13062,8 @@ tree_call_nonnegative_warnv_p (tree type, combined_fn fn, tree arg0, tree arg1,
     CASE_CFN_RINT_FN:
     CASE_CFN_ROUND:
     CASE_CFN_ROUND_FN:
+    CASE_CFN_ROUNDEVEN:
+    CASE_CFN_ROUNDEVEN_FN:
     CASE_CFN_SCALB:
     CASE_CFN_SCALBLN:
     CASE_CFN_SCALBN:
@@ -13583,6 +13587,8 @@ integer_valued_real_call_p (combined_fn fn, tree arg0, tree arg1, int depth)
     CASE_CFN_RINT_FN:
     CASE_CFN_ROUND:
     CASE_CFN_ROUND_FN:
+    CASE_CFN_ROUNDEVEN:
+    CASE_CFN_ROUNDEVEN_FN:
     CASE_CFN_TRUNC:
     CASE_CFN_TRUNC_FN:
       return true;
diff --git a/gcc/internal-fn.def b/gcc/internal-fn.def
index cda314e1121..b89918815f9 100644
--- a/gcc/internal-fn.def
+++ b/gcc/internal-fn.def
@@ -224,6 +224,7 @@ DEF_INTERNAL_FLT_FLOATN_FN (FLOOR, ECF_CONST, floor, unary)
 DEF_INTERNAL_FLT_FLOATN_FN (NEARBYINT, ECF_CONST, nearbyint, unary)
 DEF_INTERNAL_FLT_FLOATN_FN (RINT, ECF_CONST, rint, unary)
 DEF_INTERNAL_FLT_FLOATN_FN (ROUND, ECF_CONST, round, unary)
+DEF_INTERNAL_FLT_FLOATN_FN (ROUNDEVEN, ECF_CONST, roundeven, unary)
 DEF_INTERNAL_FLT_FLOATN_FN (TRUNC, ECF_CONST, btrunc, unary)
 
 /* Binary math functions.  */
diff --git a/gcc/match.pd b/gcc/match.pd
index 7cc2374ffeb..fa18b499162 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -4229,7 +4229,7 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
  (abs @0))
 
 /* trunc(trunc(x)) -> trunc(x), etc.  */
-(for fns (TRUNC_ALL FLOOR_ALL CEIL_ALL ROUND_ALL NEARBYINT_ALL RINT_ALL)
+(for fns (TRUNC_ALL FLOOR_ALL CEIL_ALL ROUND_ALL BUILT_IN_ROUNDEVEN NEARBYINT_ALL RINT_ALL)
  (simplify
   (fns (fns @0))
   (fns @0)))
diff --git a/gcc/optabs.def b/gcc/optabs.def
index 5a67f5eed5e..eb9e22acd8f 100644
--- a/gcc/optabs.def
+++ b/gcc/optabs.def
@@ -267,6 +267,7 @@ OPTAB_D (fnms_optab, "fnms$a4")
 
 OPTAB_D (rint_optab, "rint$a2")
 OPTAB_D (round_optab, "round$a2")
+OPTAB_D (roundeven_optab, "roundeven$a2")
 OPTAB_D (floor_optab, "floor$a2")
 OPTAB_D (ceil_optab, "ceil$a2")
 OPTAB_D (btrunc_optab, "btrunc$a2")
diff --git a/gcc/real.c b/gcc/real.c
index f822ae82d61..e7d9bb367b5 100644
--- a/gcc/real.c
+++ b/gcc/real.c
@@ -5010,6 +5010,89 @@ real_round (REAL_VALUE_TYPE *r, format_helper fmt,
     real_convert (r, fmt, r);
 }
 
+/* Return true including 0 if integer part of R is even, else return
+   false. The function is not valid for rvc_inf and rvc_nan classes. */
+
+bool
+is_even (REAL_VALUE_TYPE *r)
+{
+  gcc_assert (r->cl != rvc_inf);
+  gcc_assert (r->cl != rvc_nan);
+
+  if (r->cl == rvc_zero)
+    return true;
+
+  /* For (-1,1) including 0, number is even. */
+  if (REAL_EXP (r) <= 0)
+    return true;
+
+  /* Check lowest bit, if not set, return true. */
+  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;
+  }
+
+  else if (REAL_EXP (r) > SIGNIFICAND_BITS)
+    return true;
+
+  return false;
+}
+
+/* Return true if R is halfway between two integers, else return
+   false. The function is not valid for rvc_inf and rvc_nan classes. */
+
+bool
+is_halfway_below (const REAL_VALUE_TYPE *r)
+{
+  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) - 1;
+    int w = n / HOST_BITS_PER_LONG;
+
+    for (i = 0; i < w; ++i)
+      if (r->sig[i] != 0)
+        return false;
+
+    unsigned long num = ((unsigned long)1 << (n % HOST_BITS_PER_LONG));
+
+    if (((r->sig[w] & num) != 0) && ((r->sig[w] & (num-1)) == 0))
+      return true;
+  }
+  return false;
+}
+
+/* Round X to nearest integer, rounding halfway cases towards even. */
+
+void
+real_roundeven (REAL_VALUE_TYPE *r, format_helper fmt,
+		const REAL_VALUE_TYPE *x)
+{
+  if (is_halfway_below (x))
+  {
+    do_add (r, x, &dconsthalf, x->sign);
+    if (!is_even (r))
+      do_add (r, r, &dconstm1, x->sign);
+    if (fmt)
+      real_convert (r, fmt, r);
+  }
+  else
+    real_round (r, fmt, x);
+}
+
 /* Set the sign of R to the sign of X.  */
 
 void
diff --git a/gcc/real.h b/gcc/real.h
index 0ce42565708..ebe66d234af 100644
--- a/gcc/real.h
+++ b/gcc/real.h
@@ -41,11 +41,18 @@ struct GTY(()) real_value {
      sure they're packed together, otherwise REAL_VALUE_TYPE_SIZE will
      be miscomputed.  */
   unsigned int /* ENUM_BITFIELD (real_value_class) */ cl : 2;
+  /* 1 if number is decimal floating point */
   unsigned int decimal : 1;
+  /* 1 if number is negative */
   unsigned int sign : 1;
+  /* 1 if number is signalling */
   unsigned int signalling : 1;
+  /* 1 if number is canonical
+  All are generally used for handling cases in real.c */
   unsigned int canonical : 1;
+  /* unbiased exponent of the number */
   unsigned int uexp : EXP_BITS;
+  /* significand of the number */
   unsigned long sig[SIGSZ];
 };
 
@@ -499,6 +506,8 @@ extern void real_ceil (REAL_VALUE_TYPE *, format_helper,
 		       const REAL_VALUE_TYPE *);
 extern void real_round (REAL_VALUE_TYPE *, format_helper,
 			const REAL_VALUE_TYPE *);
+extern void real_roundeven (REAL_VALUE_TYPE *, format_helper,
+      const REAL_VALUE_TYPE *);
 
 /* Set the sign of R to the sign of X.  */
 extern void real_copysign (REAL_VALUE_TYPE *, const REAL_VALUE_TYPE *);
diff --git a/gcc/testsuite/gcc.dg/torture/builtin-round-roundeven.c b/gcc/testsuite/gcc.dg/torture/builtin-round-roundeven.c
new file mode 100644
index 00000000000..f75adf6ec8a
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/torture/builtin-round-roundeven.c
@@ -0,0 +1,23 @@
+/* { dg-do link } */
+
+extern int link_error (int);
+
+#define TEST(FN, VALUE, RESULT) \
+  if (__builtin_##FN (VALUE) != RESULT) link_error (__LINE__);
+
+int
+main (void)
+{
+  TEST(roundeven,  0, 0);
+  TEST(roundeven,  0.5, 0);
+  TEST(roundeven,  -0.5, 0);
+  TEST(roundeven,  6, 6);
+  TEST(roundeven,  -8, -8);
+  TEST(roundeven,  2.5, 2);
+  TEST(roundeven,  3.5, 4);
+  TEST(roundeven,  -1.5, -2);
+  TEST(roundeven,  3.499, 3);
+  TEST(roundeven,  3.501, 4);
+
+  return 0;
+}
\ No newline at end of file
diff --git a/gcc/testsuite/gcc.dg/torture/builtin-round-roundevenf128.c b/gcc/testsuite/gcc.dg/torture/builtin-round-roundevenf128.c
new file mode 100644
index 00000000000..592bad49623
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/torture/builtin-round-roundevenf128.c
@@ -0,0 +1,20 @@
+/* { dg-do link } */
+/* { dg-add-options float128 } */
+/* { dg-require-effective-target float128 } */
+
+extern int link_error (int);
+
+#define TEST(FN, VALUE, RESULT) \
+  if (__builtin_##FN##f128 (VALUE) != RESULT) link_error (__LINE__);
+
+int
+main (void)
+{
+  TEST(roundeven,  (0x1p64+0.5f128), (0x1p64f128));
+  TEST(roundeven,  (0x1p63+0.5f128), (0x1p63f128));
+  TEST(roundeven,  (0x1p63-0.5f128), (0x1p63f128));
+  TEST(roundeven,  (0x1p64-0.5f128), (0x1p64f128));
+  TEST(roundeven,  (0x1p64+0.501f128), (0x1p64+1.0f128));
+  TEST(roundeven,  (0x1.C00000000000039A5653p1f128), (0x1p2f128))
+  return 0;
+}
\ No newline at end of file

Re: About GSOC.

[Joseph Myers]

On Sun, 9 Jun 2019, Tejas Joshi wrote:

> Hello.
> I have created another patch which addresses the above points,
> attached herewith.

I don't think you should have the unreachable "return false;" in is_even.  
The last "else if" can just be "else".

> > a conditional with < not <=; if REAL_EXP (r) == SIGNIFICAND_BITS, the
> > least significant bit has value 1 and the number must be an integer).
> 
> The number is integer because of the whole word spaces is occupied by
> integer part?
> Also, why would the least significant bit will have value 1 if
> REAL_EXP (r) == SIGNIFICAND_BITS, as it only concerns with 2^0th
> position (even or odd)?

My understanding is that the significand is, as per the comments in 
real.c, in the range [0.5, 1.0).  There are SIGNIFICAND_BITS bits.  The 
bit above the most significant one has value 2^REAL_EXP.  The most 
significant one has value 2^(REAL_EXP-1).  The least significant one has 
value 2^(REAL_EXP-SIGNIFICAND_BITS).  If REAL_EXP == SIGNIFICAND_BITS, 
that means the least significant bit has value 2^0 = 1, and there are no 
bits with value 0.5 or below, so the number is an integer.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: About GSOC.

[Tejas Joshi]

[-- Attachment #1: Type: text/plain, Size: 3266 bytes --]

Hello.

> I don't think you should have the unreachable "return false;" in is_even.
> The last "else if" can just be "else".

I don't think return false in is_even is unreachable. As per my
understanding, when one else if is true in the else if ladder, all the
subsequent "else ifs" including "else" are ignored. When REAL_EXP is
less than SIGNIFICAND_BITS, but the number is odd, the inner "if" for
even-odd will not return true in which case should return false. That
case will ignore next "else if" and will reach return false.

> Suppose REAL_EXP (r) > SIGNIFICAND_BITS.  Then the number is definitely
> even, so you should return true, not false.

for this condition, else if can be modified to just else and return true.
PATCH:

gcc/ChangeLog:

2019-06-12  Tejas Joshi  <tejasjoshi9673@gmail.com>

    * builtins.c (mathfn_built_in_2): Added CASE_MATHFN for ROUNDEVEN.
    * builtins.def: Added function definitions for roundeven function
    variants.
    * fold-const-call.c (fold_const_call_ss): Added case for function
    call and fold_const_conversion call for roundeven function.
    * fold-const.c (negate_mathfn_p): Added case for roundeven function.
    (tree_call_nonnegative_warnv_p): Added case for roundeven function.
    (integer_valued_real_call_p): Added case for roundeven function.
    * real.c (is_even): New function. Returns true if real number is
    even, otherwise returns false.
    (is_halfway_below): New function. Returns true if real number is
    halfway between two integers, else return false.
    (real_roundeven): New function. Round real number to nearest
    integer, rounding halfway cases towards even.
    * real.h (real_value): Added descriptive comments.
    Added function declaration for roundeven function.

gcc/testsuite/ChangeLog:

2019-06-12  Tejas Joshi  <tejasjoshi9673@gmail.com>

    * gcc.dg/torture/builtin-round-roundeven.c: New test.
    * gcc.dg/torture/builtin-round-roundevenf128.c: New test.



On Tue, 11 Jun 2019 at 01:56, Joseph Myers <joseph@codesourcery.com> wrote:
>
> On Sun, 9 Jun 2019, Tejas Joshi wrote:
>
> > Hello.
> > I have created another patch which addresses the above points,
> > attached herewith.
>
> I don't think you should have the unreachable "return false;" in is_even.
> The last "else if" can just be "else".
>
> > > a conditional with < not <=; if REAL_EXP (r) == SIGNIFICAND_BITS, the
> > > least significant bit has value 1 and the number must be an integer).
> >
> > The number is integer because of the whole word spaces is occupied by
> > integer part?
> > Also, why would the least significant bit will have value 1 if
> > REAL_EXP (r) == SIGNIFICAND_BITS, as it only concerns with 2^0th
> > position (even or odd)?
>
> My understanding is that the significand is, as per the comments in
> real.c, in the range [0.5, 1.0).  There are SIGNIFICAND_BITS bits.  The
> bit above the most significant one has value 2^REAL_EXP.  The most
> significant one has value 2^(REAL_EXP-1).  The least significant one has
> value 2^(REAL_EXP-SIGNIFICAND_BITS).  If REAL_EXP == SIGNIFICAND_BITS,
> that means the least significant bit has value 2^0 = 1, and there are no
> bits with value 0.5 or below, so the number is an integer.
>
> --
> Joseph S. Myers
> joseph@codesourcery.com

[-- Attachment #2: roundeven2.patch --]
[-- Type: text/x-patch, Size: 9089 bytes --]

diff --git a/gcc/builtins.c b/gcc/builtins.c
index 3463ffb1539..85a945877a4 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -2085,6 +2085,7 @@ mathfn_built_in_2 (tree type, combined_fn fn)
     CASE_MATHFN (REMQUO)
     CASE_MATHFN_FLOATN (RINT)
     CASE_MATHFN_FLOATN (ROUND)
+    CASE_MATHFN (ROUNDEVEN)
     CASE_MATHFN (SCALB)
     CASE_MATHFN (SCALBLN)
     CASE_MATHFN (SCALBN)
diff --git a/gcc/builtins.def b/gcc/builtins.def
index 6d41bdb4f44..8bb7027aac7 100644
--- a/gcc/builtins.def
+++ b/gcc/builtins.def
@@ -542,12 +542,18 @@ DEF_C99_BUILTIN        (BUILT_IN_RINTL, "rintl", BT_FN_LONGDOUBLE_LONGDOUBLE, AT
 #define RINT_TYPE(F) BT_FN_##F##_##F
 DEF_EXT_LIB_FLOATN_NX_BUILTINS (BUILT_IN_RINT, "rint", RINT_TYPE, ATTR_CONST_NOTHROW_LEAF_LIST)
 #undef RINT_TYPE
+DEF_EXT_LIB_BUILTIN    (BUILT_IN_ROUNDEVEN, "roundeven", BT_FN_DOUBLE_DOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
+DEF_EXT_LIB_BUILTIN    (BUILT_IN_ROUNDEVENF, "roundevenf", BT_FN_FLOAT_FLOAT, ATTR_CONST_NOTHROW_LEAF_LIST)
+DEF_EXT_LIB_BUILTIN    (BUILT_IN_ROUNDEVENL, "roundevenl", BT_FN_LONGDOUBLE_LONGDOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_C99_BUILTIN        (BUILT_IN_ROUND, "round", BT_FN_DOUBLE_DOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_C99_BUILTIN        (BUILT_IN_ROUNDF, "roundf", BT_FN_FLOAT_FLOAT, ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_C99_BUILTIN        (BUILT_IN_ROUNDL, "roundl", BT_FN_LONGDOUBLE_LONGDOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
 #define ROUND_TYPE(F) BT_FN_##F##_##F
 DEF_EXT_LIB_FLOATN_NX_BUILTINS (BUILT_IN_ROUND, "round", ROUND_TYPE, ATTR_CONST_NOTHROW_LEAF_LIST)
 #undef ROUND_TYPE
+#define ROUNDEVEN_TYPE(F) BT_FN_##F##_##F
+DEF_EXT_LIB_FLOATN_NX_BUILTINS (BUILT_IN_ROUNDEVEN, "roundeven", ROUNDEVEN_TYPE, ATTR_CONST_NOTHROW_LEAF_LIST)
+#undef ROUNDEVEN_TYPE
 DEF_EXT_LIB_BUILTIN    (BUILT_IN_SCALB, "scalb", BT_FN_DOUBLE_DOUBLE_DOUBLE, ATTR_MATHFN_FPROUNDING_ERRNO)
 DEF_EXT_LIB_BUILTIN    (BUILT_IN_SCALBF, "scalbf", BT_FN_FLOAT_FLOAT_FLOAT, ATTR_MATHFN_FPROUNDING_ERRNO)
 DEF_EXT_LIB_BUILTIN    (BUILT_IN_SCALBL, "scalbl", BT_FN_LONGDOUBLE_LONGDOUBLE_LONGDOUBLE, ATTR_MATHFN_FPROUNDING_ERRNO)
diff --git a/gcc/fold-const-call.c b/gcc/fold-const-call.c
index 702c8b4057a..d9b546e6803 100644
--- a/gcc/fold-const-call.c
+++ b/gcc/fold-const-call.c
@@ -836,6 +836,15 @@ fold_const_call_ss (real_value *result, combined_fn fn,
 	}
       return false;
 
+    CASE_CFN_ROUNDEVEN:
+    CASE_CFN_ROUNDEVEN_FN:
+      if (!REAL_VALUE_ISNAN (*arg) || !flag_errno_math)
+  {
+    real_roundeven (result, format, arg);
+    return true;
+  }
+      return false;
+
     CASE_CFN_LOGB:
       return fold_const_logb (result, arg, format);
 
@@ -898,6 +907,10 @@ fold_const_call_ss (wide_int *result, combined_fn fn,
       return fold_const_conversion (result, real_round, arg,
 				    precision, format);
 
+    CASE_CFN_ROUNDEVEN:
+    CASE_CFN_ROUNDEVEN_FN:
+      return fold_const_conversion (result, real_roundeven, arg, precision, format);
+
     CASE_CFN_IRINT:
     CASE_CFN_LRINT:
     CASE_CFN_LLRINT:
diff --git a/gcc/fold-const.c b/gcc/fold-const.c
index 0ca472d422f..07d82a17e25 100644
--- a/gcc/fold-const.c
+++ b/gcc/fold-const.c
@@ -329,6 +329,8 @@ negate_mathfn_p (combined_fn fn)
     CASE_CFN_LLROUND:
     CASE_CFN_LROUND:
     CASE_CFN_ROUND:
+    CASE_CFN_ROUNDEVEN:
+    CASE_CFN_ROUNDEVEN_FN:
     CASE_CFN_SIN:
     CASE_CFN_SINH:
     CASE_CFN_TAN:
@@ -13063,6 +13065,8 @@ tree_call_nonnegative_warnv_p (tree type, combined_fn fn, tree arg0, tree arg1,
     CASE_CFN_RINT_FN:
     CASE_CFN_ROUND:
     CASE_CFN_ROUND_FN:
+    CASE_CFN_ROUNDEVEN:
+    CASE_CFN_ROUNDEVEN_FN:
     CASE_CFN_SCALB:
     CASE_CFN_SCALBLN:
     CASE_CFN_SCALBN:
@@ -13586,6 +13590,8 @@ integer_valued_real_call_p (combined_fn fn, tree arg0, tree arg1, int depth)
     CASE_CFN_RINT_FN:
     CASE_CFN_ROUND:
     CASE_CFN_ROUND_FN:
+    CASE_CFN_ROUNDEVEN:
+    CASE_CFN_ROUNDEVEN_FN:
     CASE_CFN_TRUNC:
     CASE_CFN_TRUNC_FN:
       return true;
diff --git a/gcc/real.c b/gcc/real.c
index 0164f097a53..ab71430709f 100644
--- a/gcc/real.c
+++ b/gcc/real.c
@@ -5010,6 +5010,89 @@ real_round (REAL_VALUE_TYPE *r, format_helper fmt,
     real_convert (r, fmt, r);
 }
 
+/* Return true including 0 if integer part of R is even, else return
+   false. The function is not valid for rvc_inf and rvc_nan classes. */
+
+bool
+is_even (REAL_VALUE_TYPE *r)
+{
+  gcc_assert (r->cl != rvc_inf);
+  gcc_assert (r->cl != rvc_nan);
+
+  if (r->cl == rvc_zero)
+    return true;
+
+  /* For (-1,1), number is even. */
+  if (REAL_EXP (r) <= 0)
+    return true;
+
+  /* Check lowest bit, if not set, return true. */
+  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;
+  }
+
+  else
+    return true;
+
+  return false;
+}
+
+/* Return true if R is halfway between two integers, else return
+   false. The function is not valid for rvc_inf and rvc_nan classes. */
+
+bool
+is_halfway_below (const REAL_VALUE_TYPE *r)
+{
+  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) - 1;
+    int w = n / HOST_BITS_PER_LONG;
+
+    for (i = 0; i < w; ++i)
+      if (r->sig[i] != 0)
+        return false;
+
+    unsigned long num = ((unsigned long)1 << (n % HOST_BITS_PER_LONG));
+
+    if (((r->sig[w] & num) != 0) && ((r->sig[w] & (num-1)) == 0))
+      return true;
+  }
+  return false;
+}
+
+/* Round X to nearest integer, rounding halfway cases towards even. */
+
+void
+real_roundeven (REAL_VALUE_TYPE *r, format_helper fmt,
+		const REAL_VALUE_TYPE *x)
+{
+  if (is_halfway_below (x))
+  {
+    do_add (r, x, &dconsthalf, x->sign);
+    if (!is_even (r))
+      do_add (r, r, &dconstm1, x->sign);
+    if (fmt)
+      real_convert (r, fmt, r);
+  }
+  else
+    real_round (r, fmt, x);
+}
+
 /* Set the sign of R to the sign of X.  */
 
 void
diff --git a/gcc/real.h b/gcc/real.h
index 95b9db83d24..76889bff0ea 100644
--- a/gcc/real.h
+++ b/gcc/real.h
@@ -41,11 +41,18 @@ struct GTY(()) real_value {
      sure they're packed together, otherwise REAL_VALUE_TYPE_SIZE will
      be miscomputed.  */
   unsigned int /* ENUM_BITFIELD (real_value_class) */ cl : 2;
+  /* 1 if number is decimal floating point */
   unsigned int decimal : 1;
+  /* 1 if number is negative */
   unsigned int sign : 1;
+  /* 1 if number is signalling */
   unsigned int signalling : 1;
+  /* 1 if number is canonical
+  All are generally used for handling cases in real.c */
   unsigned int canonical : 1;
+  /* unbiased exponent of the number */
   unsigned int uexp : EXP_BITS;
+  /* significand of the number */
   unsigned long sig[SIGSZ];
 };
 
@@ -500,6 +507,8 @@ extern void real_ceil (REAL_VALUE_TYPE *, format_helper,
 		       const REAL_VALUE_TYPE *);
 extern void real_round (REAL_VALUE_TYPE *, format_helper,
 			const REAL_VALUE_TYPE *);
+extern void real_roundeven (REAL_VALUE_TYPE *, format_helper,
+      const REAL_VALUE_TYPE *);
 
 /* Set the sign of R to the sign of X.  */
 extern void real_copysign (REAL_VALUE_TYPE *, const REAL_VALUE_TYPE *);
diff --git a/gcc/testsuite/gcc.dg/torture/builtin-round-roundeven.c b/gcc/testsuite/gcc.dg/torture/builtin-round-roundeven.c
new file mode 100644
index 00000000000..f75adf6ec8a
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/torture/builtin-round-roundeven.c
@@ -0,0 +1,23 @@
+/* { dg-do link } */
+
+extern int link_error (int);
+
+#define TEST(FN, VALUE, RESULT) \
+  if (__builtin_##FN (VALUE) != RESULT) link_error (__LINE__);
+
+int
+main (void)
+{
+  TEST(roundeven,  0, 0);
+  TEST(roundeven,  0.5, 0);
+  TEST(roundeven,  -0.5, 0);
+  TEST(roundeven,  6, 6);
+  TEST(roundeven,  -8, -8);
+  TEST(roundeven,  2.5, 2);
+  TEST(roundeven,  3.5, 4);
+  TEST(roundeven,  -1.5, -2);
+  TEST(roundeven,  3.499, 3);
+  TEST(roundeven,  3.501, 4);
+
+  return 0;
+}
\ No newline at end of file
diff --git a/gcc/testsuite/gcc.dg/torture/builtin-round-roundevenf128.c b/gcc/testsuite/gcc.dg/torture/builtin-round-roundevenf128.c
new file mode 100644
index 00000000000..592bad49623
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/torture/builtin-round-roundevenf128.c
@@ -0,0 +1,20 @@
+/* { dg-do link } */
+/* { dg-add-options float128 } */
+/* { dg-require-effective-target float128 } */
+
+extern int link_error (int);
+
+#define TEST(FN, VALUE, RESULT) \
+  if (__builtin_##FN##f128 (VALUE) != RESULT) link_error (__LINE__);
+
+int
+main (void)
+{
+  TEST(roundeven,  (0x1p64+0.5f128), (0x1p64f128));
+  TEST(roundeven,  (0x1p63+0.5f128), (0x1p63f128));
+  TEST(roundeven,  (0x1p63-0.5f128), (0x1p63f128));
+  TEST(roundeven,  (0x1p64-0.5f128), (0x1p64f128));
+  TEST(roundeven,  (0x1p64+0.501f128), (0x1p64+1.0f128));
+  TEST(roundeven,  (0x1.C00000000000039A5653p1f128), (0x1p2f128))
+  return 0;
+}
\ No newline at end of file

Re: About GSOC.

[Tejas Joshi]

Hello.
As further part of implementing roundeven is inlining, I was studying
machine descriptions and I have a few questions.

As suggested, builtin functions provided a strong model for
implementing roundeven. Keeping that in mind, I tried to inspect how
similar functions (round/ceil) would get inlined. As it is dependent
on target machine, (mine is i7, so should be x86_64 ? I wonder why
gcc/config/ does not have x86_64 or amd64 directory. Or is it i386
itself as extended?), should *.s file after compilation contain the
specific instruction if supported? I was unable to see such kind of
instruction on any -O level.

Different pattern names are available for machine descriptions
<https://gcc.gnu.org/onlinedocs/gccint/Standard-Names.html>, also for
round, ceil, etc. Will I have to add such pattern name for roundeven?
(is it the same as optab defined in optabs.def?)

Thanks,
-Tejas


On Thu, 13 Jun 2019 at 00:27, Tejas Joshi <tejasjoshi9673@gmail.com> wrote:
>
> Hello.
>
> > I don't think you should have the unreachable "return false;" in is_even.
> > The last "else if" can just be "else".
>
> I don't think return false in is_even is unreachable. As per my
> understanding, when one else if is true in the else if ladder, all the
> subsequent "else ifs" including "else" are ignored. When REAL_EXP is
> less than SIGNIFICAND_BITS, but the number is odd, the inner "if" for
> even-odd will not return true in which case should return false. That
> case will ignore next "else if" and will reach return false.
>
> > Suppose REAL_EXP (r) > SIGNIFICAND_BITS.  Then the number is definitely
> > even, so you should return true, not false.
>
> for this condition, else if can be modified to just else and return true.
> PATCH:
>
> gcc/ChangeLog:
>
> 2019-06-12  Tejas Joshi  <tejasjoshi9673@gmail.com>
>
>     * builtins.c (mathfn_built_in_2): Added CASE_MATHFN for ROUNDEVEN.
>     * builtins.def: Added function definitions for roundeven function
>     variants.
>     * fold-const-call.c (fold_const_call_ss): Added case for function
>     call and fold_const_conversion call for roundeven function.
>     * fold-const.c (negate_mathfn_p): Added case for roundeven function.
>     (tree_call_nonnegative_warnv_p): Added case for roundeven function.
>     (integer_valued_real_call_p): Added case for roundeven function.
>     * real.c (is_even): New function. Returns true if real number is
>     even, otherwise returns false.
>     (is_halfway_below): New function. Returns true if real number is
>     halfway between two integers, else return false.
>     (real_roundeven): New function. Round real number to nearest
>     integer, rounding halfway cases towards even.
>     * real.h (real_value): Added descriptive comments.
>     Added function declaration for roundeven function.
>
> gcc/testsuite/ChangeLog:
>
> 2019-06-12  Tejas Joshi  <tejasjoshi9673@gmail.com>
>
>     * gcc.dg/torture/builtin-round-roundeven.c: New test.
>     * gcc.dg/torture/builtin-round-roundevenf128.c: New test.
>
>
>
> On Tue, 11 Jun 2019 at 01:56, Joseph Myers <joseph@codesourcery.com> wrote:
> >
> > On Sun, 9 Jun 2019, Tejas Joshi wrote:
> >
> > > Hello.
> > > I have created another patch which addresses the above points,
> > > attached herewith.
> >
> > I don't think you should have the unreachable "return false;" in is_even.
> > The last "else if" can just be "else".
> >
> > > > a conditional with < not <=; if REAL_EXP (r) == SIGNIFICAND_BITS, the
> > > > least significant bit has value 1 and the number must be an integer).
> > >
> > > The number is integer because of the whole word spaces is occupied by
> > > integer part?
> > > Also, why would the least significant bit will have value 1 if
> > > REAL_EXP (r) == SIGNIFICAND_BITS, as it only concerns with 2^0th
> > > position (even or odd)?
> >
> > My understanding is that the significand is, as per the comments in
> > real.c, in the range [0.5, 1.0).  There are SIGNIFICAND_BITS bits.  The
> > bit above the most significant one has value 2^REAL_EXP.  The most
> > significant one has value 2^(REAL_EXP-1).  The least significant one has
> > value 2^(REAL_EXP-SIGNIFICAND_BITS).  If REAL_EXP == SIGNIFICAND_BITS,
> > that means the least significant bit has value 2^0 = 1, and there are no
> > bits with value 0.5 or below, so the number is an integer.
> >
> > --
> > Joseph S. Myers
> > joseph@codesourcery.com

Re: Expanding roundeven (Was: Re: About GSOC.)

[Martin Jambor]

Hi Tejas,

On Thu, Jun 13 2019, Tejas Joshi wrote:
> Hello.
> As further part of implementing roundeven is inlining, I was studying
> machine descriptions and I have a few questions.
>
> As suggested, builtin functions provided a strong model for
> implementing roundeven. Keeping that in mind, I tried to inspect how
> similar functions (round/ceil) would get inlined. As it is dependent
> on target machine, (mine is i7, so should be x86_64 ? I wonder why
> gcc/config/ does not have x86_64 or amd64 directory. Or is it i386
> itself as extended?),

Yes, the directory with x86_64 specific stuff is i386.

> should *.s file after compilation contain the
> specific instruction if supported? I was unable to see such kind of
> instruction on any -O level.
>

I am not sure I understand your question.  Yes, the intent is that when
the compiler cannot determine the argument of roundeven to be constant,
it should emit the instruction instead of a library call, if the target
architecture supports it.  (and if IIUC, the intent is to use the 0 mode
from table 4-8 in
https://software.intel.com/sites/default/files/managed/39/c5/325462-sdm-vol-1-2abcd-3abcd.pdf
in instructions that take a rounding a mode to implement roundeven).

Of course the instruction is not present there, that is the next step in
your project :-)

> Different pattern names are available for machine descriptions
> <https://gcc.gnu.org/onlinedocs/gccint/Standard-Names.html>, also for
> round, ceil, etc. Will I have to add such pattern name for roundeven?
> (is it the same as optab defined in optabs.def?)

Yes.

Martin

Re: Expanding roundeven (Was: Re: About GSOC.)

[Joseph Myers]

On Thu, 13 Jun 2019, Martin Jambor wrote:

> architecture supports it.  (and if IIUC, the intent is to use the 0 mode
> from table 4-8 in
> https://software.intel.com/sites/default/files/managed/39/c5/325462-sdm-vol-1-2abcd-3abcd.pdf
> in instructions that take a rounding a mode to implement roundeven).

Note that the rounding mode argument to roundss / roundsd should end up as 
8, not 0, so that the inexact exception is not raised.  (8 here is the 
existing ROUND_NO_EXC definition in GCC.  A new definition will need 
adding alongside ROUND_FLOOR, ROUND_CEIL and ROUND_TRUNC to correspond to 
rounding to nearest with ties to even, evaluating to 0.)

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Expanding roundeven (Was: Re: About GSOC.)

[Tejas Joshi]

[-- Attachment #1: Type: text/plain, Size: 2642 bytes --]

> Of course the instruction is not present there, that is the next step in
> your project :-)

Yes, of course, but what I meant was that instructions for existing
round/ceil functions and not roundeven. If inlining for these
functions is available, how can I inspect such instructions getting
inlined maybe in a *.s file?

Also, I am trying to find appropriate places to introduce changes for
roundeven to be inlined. Attached patch is what I have tried so far to
find the places.
ix86_expand_roundeven have dummy code for the sake of time.

In i386.md:
1. How should roundeven be defined at certain places where existing
floor is defined as:
(define_int_attr rounding_insn
    [(UNSPEC_FRNDINT_FLOOR "floor")

2. Also, can roundeven be handled like round_floor is handled by:
(define_expand "<rounding_insn><mode>2"
but definitely with certain changes of flags, options and macros.

Thanks,
--Tejas



On Thu, 13 Jun 2019 at 22:49, Martin Jambor <mjambor@suse.cz> wrote:
>
> Hi Tejas,
>
> On Thu, Jun 13 2019, Tejas Joshi wrote:
> > Hello.
> > As further part of implementing roundeven is inlining, I was studying
> > machine descriptions and I have a few questions.
> >
> > As suggested, builtin functions provided a strong model for
> > implementing roundeven. Keeping that in mind, I tried to inspect how
> > similar functions (round/ceil) would get inlined. As it is dependent
> > on target machine, (mine is i7, so should be x86_64 ? I wonder why
> > gcc/config/ does not have x86_64 or amd64 directory. Or is it i386
> > itself as extended?),
>
> Yes, the directory with x86_64 specific stuff is i386.
>
> > should *.s file after compilation contain the
> > specific instruction if supported? I was unable to see such kind of
> > instruction on any -O level.
> >
>
> I am not sure I understand your question.  Yes, the intent is that when
> the compiler cannot determine the argument of roundeven to be constant,
> it should emit the instruction instead of a library call, if the target
> architecture supports it.  (and if IIUC, the intent is to use the 0 mode
> from table 4-8 in
> https://software.intel.com/sites/default/files/managed/39/c5/325462-sdm-vol-1-2abcd-3abcd.pdf
> in instructions that take a rounding a mode to implement roundeven).
>
> Of course the instruction is not present there, that is the next step in
> your project :-)
>
> > Different pattern names are available for machine descriptions
> > <https://gcc.gnu.org/onlinedocs/gccint/Standard-Names.html>, also for
> > round, ceil, etc. Will I have to add such pattern name for roundeven?
> > (is it the same as optab defined in optabs.def?)
>
> Yes.
>
> Martin

[-- Attachment #2: roundeven-md.patch --]
[-- Type: text/x-patch, Size: 5033 bytes --]

diff --git a/gcc/builtins.c b/gcc/builtins.c
index 85a945877a4..291717da7ee 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -2723,6 +2723,9 @@ expand_builtin_int_roundingfn (tree exp, rtx target)
       fallback_fn = BUILT_IN_FLOOR;
       break;
 
+    CASE_FLT_FN (BUILT_IN_ROUNDEVEN):
+      builtin_optab = roundeven_optab;
+
     default:
       gcc_unreachable ();
     }
@@ -7346,6 +7349,7 @@ expand_builtin (tree exp, rtx target, rtx subtarget, machine_mode mode,
 	return target;
       break;
 
+    CASE_FLT_FN (BUILT_IN_ROUNDEVEN):
     CASE_FLT_FN (BUILT_IN_ICEIL):
     CASE_FLT_FN (BUILT_IN_LCEIL):
     CASE_FLT_FN (BUILT_IN_LLCEIL):
diff --git a/gcc/config/i386/i386-builtin.def b/gcc/config/i386/i386-builtin.def
index e547dda80f1..5cd255d24ef 100644
--- a/gcc/config/i386/i386-builtin.def
+++ b/gcc/config/i386/i386-builtin.def
@@ -902,6 +902,7 @@ BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundps, "__builtin_ia32_round
 BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundsd, "__builtin_ia32_roundsd", IX86_BUILTIN_ROUNDSD, UNKNOWN, (int) V2DF_FTYPE_V2DF_V2DF_INT)
 BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundss, "__builtin_ia32_roundss", IX86_BUILTIN_ROUNDSS, UNKNOWN, (int) V4SF_FTYPE_V4SF_V4SF_INT)
 
+BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundevenpd, "__builtin_ia32_roundevenpd", IX86_BUILTIN_ROUNDEVENPD, (enum rtx_code) ROUND_ROUNDEVEN, (int) V2DF_FTYPE_V2DF_ROUND)
 BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundpd, "__builtin_ia32_floorpd", IX86_BUILTIN_FLOORPD, (enum rtx_code) ROUND_FLOOR, (int) V2DF_FTYPE_V2DF_ROUND)
 BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundpd, "__builtin_ia32_ceilpd", IX86_BUILTIN_CEILPD, (enum rtx_code) ROUND_CEIL, (int) V2DF_FTYPE_V2DF_ROUND)
 BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundpd, "__builtin_ia32_truncpd", IX86_BUILTIN_TRUNCPD, (enum rtx_code) ROUND_TRUNC, (int) V2DF_FTYPE_V2DF_ROUND)
@@ -913,6 +914,7 @@ BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundpd_vec_pack_sfix, "__buil
 BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_roundv2df2, "__builtin_ia32_roundpd_az", IX86_BUILTIN_ROUNDPD_AZ, UNKNOWN, (int) V2DF_FTYPE_V2DF)
 BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_roundv2df2_vec_pack_sfix, "__builtin_ia32_roundpd_az_vec_pack_sfix", IX86_BUILTIN_ROUNDPD_AZ_VEC_PACK_SFIX, UNKNOWN, (int) V4SI_FTYPE_V2DF_V2DF)
 
+BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundps, "__builtin_ia32_roundevenps", IX86_BUILTIN_ROUNDEVENPS, (enum rtx_code) ROUND_ROUNDEVEN, (int) V4SF_FTYPE_V4SF_ROUND)
 BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundps, "__builtin_ia32_floorps", IX86_BUILTIN_FLOORPS, (enum rtx_code) ROUND_FLOOR, (int) V4SF_FTYPE_V4SF_ROUND)
 BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundps, "__builtin_ia32_ceilps", IX86_BUILTIN_CEILPS, (enum rtx_code) ROUND_CEIL, (int) V4SF_FTYPE_V4SF_ROUND)
 BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundps, "__builtin_ia32_truncps", IX86_BUILTIN_TRUNCPS, (enum rtx_code) ROUND_TRUNC, (int) V4SF_FTYPE_V4SF_ROUND)
diff --git a/gcc/config/i386/i386-expand.c b/gcc/config/i386/i386-expand.c
index 0585c7d08bd..ad88c1a7e12 100644
--- a/gcc/config/i386/i386-expand.c
+++ b/gcc/config/i386/i386-expand.c
@@ -16094,6 +16094,16 @@ ix86_expand_rounddf_32 (rtx operand0, rtx operand1)
   emit_move_insn (operand0, res);
 }
 
+void
+ix86_expand_roundeven (rtx operand0, rtx operand1)
+{
+  machine_mode mode = GET_MODE (operand0);
+  rtx xa, xi, TWO52, res, mask;
+
+  res = gen_reg_rtx (mode);
+  emit_move_insn (res, operand1);
+}
+
 /* Expand SSE sequence for computing trunc from OPERAND1 storing
    into OPERAND0.  */
 void
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index 01338e294ab..e81ba12161e 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -303,7 +303,8 @@
 
 ;; Constants to represent rounding modes in the ROUND instruction
 (define_constants
-  [(ROUND_FLOOR			0x1)
+  [(ROUND_ROUNDEVEN)    0x0)
+   (ROUND_FLOOR			0x1)
    (ROUND_CEIL			0x2)
    (ROUND_TRUNC			0x3)
    (ROUND_MXCSR			0x4)
diff --git a/gcc/internal-fn.def b/gcc/internal-fn.def
index 016301a58d8..c07d48594e3 100644
--- a/gcc/internal-fn.def
+++ b/gcc/internal-fn.def
@@ -231,6 +231,7 @@ DEF_INTERNAL_FLT_FLOATN_FN (FLOOR, ECF_CONST, floor, unary)
 DEF_INTERNAL_FLT_FLOATN_FN (NEARBYINT, ECF_CONST, nearbyint, unary)
 DEF_INTERNAL_FLT_FLOATN_FN (RINT, ECF_CONST, rint, unary)
 DEF_INTERNAL_FLT_FLOATN_FN (ROUND, ECF_CONST, round, unary)
+DEF_INTERNAL_FLT_FLOATN_FN (ROUNDEVEN, ECF_CONST, roundeven, unary)
 DEF_INTERNAL_FLT_FLOATN_FN (TRUNC, ECF_CONST, btrunc, unary)
 
 /* Binary math functions.  */
diff --git a/gcc/optabs.def b/gcc/optabs.def
index 8af3a2f43fd..839d250b8c6 100644
--- a/gcc/optabs.def
+++ b/gcc/optabs.def
@@ -267,6 +267,7 @@ OPTAB_D (fnms_optab, "fnms$a4")
 
 OPTAB_D (rint_optab, "rint$a2")
 OPTAB_D (round_optab, "round$a2")
+OPTAB_D (roundeven_optab, "roundeven$a2")
 OPTAB_D (floor_optab, "floor$a2")
 OPTAB_D (ceil_optab, "ceil$a2")
 OPTAB_D (btrunc_optab, "btrunc$a2")

Re: Expanding roundeven (Was: Re: About GSOC.)

[Martin Jambor]

Hi,

On Fri, Jun 14 2019, Tejas Joshi wrote:
>> Of course the instruction is not present there, that is the next step in
>> your project :-)
>
> Yes, of course, but what I meant was that instructions for existing
> round/ceil functions and not roundeven. If inlining for these
> functions is available, how can I inspect such instructions getting
> inlined maybe in a *.s file?

Make sure you compile to a target that has the rounding instruction,
i.e. by using an appropriate -march or -mavx) and also specify
-ffast-math on the command line.  I have not double checked, but I
assume the latter is necessary (mainly) because it implies
-fno-math-errno and most of the math builtin expansion into instructions
is guarded by check for !flag_errno_math.

So e.g. my test input:

  double
  callplusone (double d)
  {
    return __builtin_round (d) + 1;
  }

has vroundsd instruction in the output of:

  ~/gcc/trunk/inst/bin/gcc -O2 -S expand_example.c -mavx -ffast-math

>
> Also, I am trying to find appropriate places to introduce changes for
> roundeven to be inlined. Attached patch is what I have tried so far to
> find the places.

So far I only quickly glanced over it but it seems to be going in the
right direction.  I'll try to answer the rest of your questions as soon
as I can but I also have to look a bit into the machine descriptions
myself first.

Martin


> ix86_expand_roundeven have dummy code for the sake of time.
>
> In i386.md:
> 1. How should roundeven be defined at certain places where existing
> floor is defined as:
> (define_int_attr rounding_insn
>     [(UNSPEC_FRNDINT_FLOOR "floor")
>
> 2. Also, can roundeven be handled like round_floor is handled by:
> (define_expand "<rounding_insn><mode>2"
> but definitely with certain changes of flags, options and macros.
>
> Thanks,
> --Tejas

Re: Expanding roundeven (Was: Re: About GSOC.)

[Tejas Joshi]

Hello.
Looking at machine description of functions like ceil/floor and I
think specifically:

(define_expand "<rounding_insn><mode>2"

Roundeven should be described as define_expand (or within this
alongside ceil and floor?) with expand functions to emit instructions
in i386-builtins.c?
Referring to <www.info.univ-angers.fr/pub/richer/ens/l3info/ao/intel_sse4.pdf>,
operands of these instructions work with xmm registers, memory and
imm8 for rounding mode.

> existing ROUND_NO_EXC definition in GCC.  A new definition will need
> adding alongside ROUND_FLOOR, ROUND_CEIL and ROUND_TRUNC to correspond to
> rounding to nearest with ties to even, evaluating to 0.)

So (ROUND_ROUNDEVEN   0x0) be declared for rounding towards nearest
even for rounding mode argument? But reference says that RC field
should end up as 00B for rounding ties to even? I am also much
confused about machine-type flags used as C conditions. How do we
determine which ones to check and does it depends on exceptions and
conditions described in the reference? Also, do ROUNDEVEN needs to be
defined as (how):

(define_int_attr rounding_insn
[(UNSPEC_FRNDINT_FLOOR "floor")

Thanks,
--Tejas


On Fri, 14 Jun 2019 at 23:02, Martin Jambor <mjambor@suse.cz> wrote:
>
> Hi,
>
> On Fri, Jun 14 2019, Tejas Joshi wrote:
> >> Of course the instruction is not present there, that is the next step in
> >> your project :-)
> >
> > Yes, of course, but what I meant was that instructions for existing
> > round/ceil functions and not roundeven. If inlining for these
> > functions is available, how can I inspect such instructions getting
> > inlined maybe in a *.s file?
>
> Make sure you compile to a target that has the rounding instruction,
> i.e. by using an appropriate -march or -mavx) and also specify
> -ffast-math on the command line.  I have not double checked, but I
> assume the latter is necessary (mainly) because it implies
> -fno-math-errno and most of the math builtin expansion into instructions
> is guarded by check for !flag_errno_math.
>
> So e.g. my test input:
>
>   double
>   callplusone (double d)
>   {
>     return __builtin_round (d) + 1;
>   }
>
> has vroundsd instruction in the output of:
>
>   ~/gcc/trunk/inst/bin/gcc -O2 -S expand_example.c -mavx -ffast-math
>
> >
> > Also, I am trying to find appropriate places to introduce changes for
> > roundeven to be inlined. Attached patch is what I have tried so far to
> > find the places.
>
> So far I only quickly glanced over it but it seems to be going in the
> right direction.  I'll try to answer the rest of your questions as soon
> as I can but I also have to look a bit into the machine descriptions
> myself first.
>
> Martin
>
>
> > ix86_expand_roundeven have dummy code for the sake of time.
> >
> > In i386.md:
> > 1. How should roundeven be defined at certain places where existing
> > floor is defined as:
> > (define_int_attr rounding_insn
> >     [(UNSPEC_FRNDINT_FLOOR "floor")
> >
> > 2. Also, can roundeven be handled like round_floor is handled by:
> > (define_expand "<rounding_insn><mode>2"
> > but definitely with certain changes of flags, options and macros.
> >
> > Thanks,
> > --Tejas

Re: Expanding roundeven (Was: Re: About GSOC.)

[Joseph Myers]

On Mon, 17 Jun 2019, Tejas Joshi wrote:

> > existing ROUND_NO_EXC definition in GCC.  A new definition will need
> > adding alongside ROUND_FLOOR, ROUND_CEIL and ROUND_TRUNC to correspond to
> > rounding to nearest with ties to even, evaluating to 0.)
> 
> So (ROUND_ROUNDEVEN   0x0) be declared for rounding towards nearest
> even for rounding mode argument? But reference says that RC field
> should end up as 00B for rounding ties to even? I am also much

I think the code will be much clearer if it explicitly says 
ROUND_ROUNDEVEN | ROUND_NO_EXC, than if it hardcodes implicit knowledge 
that 0 is the value used for rounding to nearest with ties to even.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Expanding roundeven (Was: Re: About GSOC.)

[Tejas Joshi]

[-- Attachment #1: Type: text/plain, Size: 2120 bytes --]

Hello.
I have made following changes to inspect inlining of roundeven with
the following test code:
double
plusone (double d)
{
    return __builtin_roundeven (d) + 1;
}

Running the program using -O2 foo.c gave internal compiler error which
I believe is because gcc_unreachable() at:

if (TARGET_SSE4_1)
    emit_insn (gen_sse4_1_round<mode>2
           (operands[0], operands[1], GEN_INT (ROUND_<ROUNDING>
                               | ROUND_NO_EXC)));
I think the following condition matches the criterion? :
> I think the code will be much clearer if it explicitly says
> ROUND_ROUNDEVEN | ROUND_NO_EXC,

     else if (TARGET_64BIT || (<MODE>mode != DFmode))
    {
      if (ROUND_<ROUNDING> == ROUND_FLOOR)
        ix86_expand_floorceil (operands[0], operands[1], true);
      else if (ROUND_<ROUNDING> == ROUND_CEIL)
        ix86_expand_floorceil (operands[0], operands[1], false);
      else if (ROUND_<ROUNDING> == ROUND_TRUNC)
        ix86_expand_trunc (operands[0], operands[1]);
      else
        gcc_unreachable ();
    }
in:
(define_expand "<rounding_insn><mode>2"
But with -mavx, generated the vroundsd insn. Does it mean ROUNDEVEN
should have a condition in the else if, but comments above
ix86_expand* functions in i386-expand.c says that those are for SSE2
sequences?

Thanks,
--Tejas


On Mon, 17 Jun 2019 at 22:45, Joseph Myers <joseph@codesourcery.com> wrote:
>
> On Mon, 17 Jun 2019, Tejas Joshi wrote:
>
> > > existing ROUND_NO_EXC definition in GCC.  A new definition will need
> > > adding alongside ROUND_FLOOR, ROUND_CEIL and ROUND_TRUNC to correspond to
> > > rounding to nearest with ties to even, evaluating to 0.)
> >
> > So (ROUND_ROUNDEVEN   0x0) be declared for rounding towards nearest
> > even for rounding mode argument? But reference says that RC field
> > should end up as 00B for rounding ties to even? I am also much
>
> I think the code will be much clearer if it explicitly says
> ROUND_ROUNDEVEN | ROUND_NO_EXC, than if it hardcodes implicit knowledge
> that 0 is the value used for rounding to nearest with ties to even.
>
> --
> Joseph S. Myers
> joseph@codesourcery.com

[-- Attachment #2: roundeven-md1.patch --]
[-- Type: text/x-patch, Size: 5776 bytes --]

diff --git a/gcc/config/i386/i386-builtin.def b/gcc/config/i386/i386-builtin.def
index e547dda80f1..40536d7929c 100644
--- a/gcc/config/i386/i386-builtin.def
+++ b/gcc/config/i386/i386-builtin.def
@@ -906,6 +906,7 @@ BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundpd, "__builtin_ia32_floor
 BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundpd, "__builtin_ia32_ceilpd", IX86_BUILTIN_CEILPD, (enum rtx_code) ROUND_CEIL, (int) V2DF_FTYPE_V2DF_ROUND)
 BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundpd, "__builtin_ia32_truncpd", IX86_BUILTIN_TRUNCPD, (enum rtx_code) ROUND_TRUNC, (int) V2DF_FTYPE_V2DF_ROUND)
 BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundpd, "__builtin_ia32_rintpd", IX86_BUILTIN_RINTPD, (enum rtx_code) ROUND_MXCSR, (int) V2DF_FTYPE_V2DF_ROUND)
+BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundpd, "__builtin_ia32_roundevenpd", IX86_BUILTIN_ROUNDEVENPD, (enum rtx_code) ROUND_ROUNDEVEN, (int) V2DF_FTYPE_V2DF_ROUND)
 
 BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundpd_vec_pack_sfix, "__builtin_ia32_floorpd_vec_pack_sfix", IX86_BUILTIN_FLOORPD_VEC_PACK_SFIX, (enum rtx_code) ROUND_FLOOR, (int) V4SI_FTYPE_V2DF_V2DF_ROUND)
 BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundpd_vec_pack_sfix, "__builtin_ia32_ceilpd_vec_pack_sfix", IX86_BUILTIN_CEILPD_VEC_PACK_SFIX, (enum rtx_code) ROUND_CEIL, (int) V4SI_FTYPE_V2DF_V2DF_ROUND)
@@ -917,6 +918,7 @@ BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundps, "__builtin_ia32_floor
 BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundps, "__builtin_ia32_ceilps", IX86_BUILTIN_CEILPS, (enum rtx_code) ROUND_CEIL, (int) V4SF_FTYPE_V4SF_ROUND)
 BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundps, "__builtin_ia32_truncps", IX86_BUILTIN_TRUNCPS, (enum rtx_code) ROUND_TRUNC, (int) V4SF_FTYPE_V4SF_ROUND)
 BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundps, "__builtin_ia32_rintps", IX86_BUILTIN_RINTPS, (enum rtx_code) ROUND_MXCSR, (int) V4SF_FTYPE_V4SF_ROUND)
+BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundps, "__builtin_ia32_roundevenps", IX86_BUILTIN_ROUNDEVENPS, (enum rtx_code) ROUND_ROUNDEVEN, (int) V4SF_FTYPE_V4SF_ROUND)
 
 BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundps_sfix, "__builtin_ia32_floorps_sfix", IX86_BUILTIN_FLOORPS_SFIX, (enum rtx_code) ROUND_FLOOR, (int) V4SI_FTYPE_V4SF_ROUND)
 BDESC (OPTION_MASK_ISA_SSE4_1, 0, CODE_FOR_sse4_1_roundps_sfix, "__builtin_ia32_ceilps_sfix", IX86_BUILTIN_CEILPS_SFIX, (enum rtx_code) ROUND_CEIL, (int) V4SI_FTYPE_V4SF_ROUND)
diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h
index 01213ccb82c..ce58b5e5c28 100644
--- a/gcc/config/i386/i386.h
+++ b/gcc/config/i386/i386.h
@@ -2468,6 +2468,7 @@ enum ix86_stack_slot
   SLOT_CW_TRUNC,
   SLOT_CW_FLOOR,
   SLOT_CW_CEIL,
+  SLOT_CW_ROUNDEVEN,
   SLOT_STV_TEMP,
   MAX_386_STACK_LOCALS
 };
@@ -2479,6 +2480,7 @@ enum ix86_entity
   I387_TRUNC,
   I387_FLOOR,
   I387_CEIL,
+  I387_ROUNDEVEN,
   MAX_386_ENTITIES
 };
 
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index 01338e294ab..b11af2f4308 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -144,6 +144,7 @@
   UNSPEC_FRNDINT_FLOOR
   UNSPEC_FRNDINT_CEIL
   UNSPEC_FRNDINT_TRUNC
+  UNSPEC_FRNDINT_ROUNDEVEN
   UNSPEC_FIST_FLOOR
   UNSPEC_FIST_CEIL
 
@@ -303,7 +304,8 @@
 
 ;; Constants to represent rounding modes in the ROUND instruction
 (define_constants
-  [(ROUND_FLOOR			0x1)
+  [(ROUND_ROUNDEVEN		0x0)
+   (ROUND_FLOOR			0x1)
    (ROUND_CEIL			0x2)
    (ROUND_TRUNC			0x3)
    (ROUND_MXCSR			0x4)
@@ -779,7 +781,7 @@
 
 ;; Defines rounding mode of an FP operation.
 
-(define_attr "i387_cw" "trunc,floor,ceil,uninitialized,any"
+(define_attr "i387_cw" "trunc,floor,ceil,roundeven,uninitialized,any"
   (const_string "any"))
 
 ;; Define attribute to indicate AVX insns with partial XMM register update.
@@ -16254,7 +16256,8 @@
 (define_int_iterator FRNDINT_ROUNDING
 	[UNSPEC_FRNDINT_FLOOR
 	 UNSPEC_FRNDINT_CEIL
-	 UNSPEC_FRNDINT_TRUNC])
+	 UNSPEC_FRNDINT_TRUNC
+   UNSPEC_FRNDINT_ROUNDEVEN])
 
 (define_int_iterator FIST_ROUNDING
 	[UNSPEC_FIST_FLOOR
@@ -16265,6 +16268,7 @@
 	[(UNSPEC_FRNDINT_FLOOR "floor")
 	 (UNSPEC_FRNDINT_CEIL "ceil")
 	 (UNSPEC_FRNDINT_TRUNC "btrunc")
+   (UNSPEC_FRNDINT_ROUNDEVEN "roundeven")
 	 (UNSPEC_FIST_FLOOR "floor")
 	 (UNSPEC_FIST_CEIL "ceil")])
 
@@ -16272,6 +16276,7 @@
 	[(UNSPEC_FRNDINT_FLOOR "floor")
 	 (UNSPEC_FRNDINT_CEIL "ceil")
 	 (UNSPEC_FRNDINT_TRUNC "trunc")
+   (UNSPEC_FRNDINT_ROUNDEVEN "roundeven")
 	 (UNSPEC_FIST_FLOOR "floor")
 	 (UNSPEC_FIST_CEIL "ceil")])
 
@@ -16279,6 +16284,7 @@
 	[(UNSPEC_FRNDINT_FLOOR "FLOOR")
 	 (UNSPEC_FRNDINT_CEIL "CEIL")
 	 (UNSPEC_FRNDINT_TRUNC "TRUNC")
+   (UNSPEC_FRNDINT_ROUNDEVEN "ROUNDEVEN")
 	 (UNSPEC_FIST_FLOOR "FLOOR")
 	 (UNSPEC_FIST_CEIL "CEIL")])
 
diff --git a/gcc/internal-fn.def b/gcc/internal-fn.def
index 016301a58d8..c07d48594e3 100644
--- a/gcc/internal-fn.def
+++ b/gcc/internal-fn.def
@@ -231,6 +231,7 @@ DEF_INTERNAL_FLT_FLOATN_FN (FLOOR, ECF_CONST, floor, unary)
 DEF_INTERNAL_FLT_FLOATN_FN (NEARBYINT, ECF_CONST, nearbyint, unary)
 DEF_INTERNAL_FLT_FLOATN_FN (RINT, ECF_CONST, rint, unary)
 DEF_INTERNAL_FLT_FLOATN_FN (ROUND, ECF_CONST, round, unary)
+DEF_INTERNAL_FLT_FLOATN_FN (ROUNDEVEN, ECF_CONST, roundeven, unary)
 DEF_INTERNAL_FLT_FLOATN_FN (TRUNC, ECF_CONST, btrunc, unary)
 
 /* Binary math functions.  */
diff --git a/gcc/optabs.def b/gcc/optabs.def
index 8af3a2f43fd..839d250b8c6 100644
--- a/gcc/optabs.def
+++ b/gcc/optabs.def
@@ -267,6 +267,7 @@ OPTAB_D (fnms_optab, "fnms$a4")
 
 OPTAB_D (rint_optab, "rint$a2")
 OPTAB_D (round_optab, "round$a2")
+OPTAB_D (roundeven_optab, "roundeven$a2")
 OPTAB_D (floor_optab, "floor$a2")
 OPTAB_D (ceil_optab, "ceil$a2")
 OPTAB_D (btrunc_optab, "btrunc$a2")

Re: Expanding roundeven (Was: Re: About GSOC.)

[Tejas Joshi]

[-- Attachment #1: Type: text/plain, Size: 2862 bytes --]

Hello.
I have already sent a patch for expanding roundeven for i386 with
relevant doubts. I also was regression testing with
make -k check
after successful bootstrap build with reverting my patches. Turns out
do-check fails without any patches applied, Is it ok to do anyways for
applied patch? Also, /contrib/compare_tests returns with "no common
files to compare" but I see all as the same files (actually, I am
moving *.sum files in manual directory and comparing with build of
applied patch.)? Is it due to failed make check?

Thanks,
-Tejas


On Wed, 19 Jun 2019 at 19:07, Tejas Joshi <tejasjoshi9673@gmail.com> wrote:
>
> Hello.
> I have made following changes to inspect inlining of roundeven with
> the following test code:
> double
> plusone (double d)
> {
>     return __builtin_roundeven (d) + 1;
> }
>
> Running the program using -O2 foo.c gave internal compiler error which
> I believe is because gcc_unreachable() at:
>
> if (TARGET_SSE4_1)
>     emit_insn (gen_sse4_1_round<mode>2
>            (operands[0], operands[1], GEN_INT (ROUND_<ROUNDING>
>                                | ROUND_NO_EXC)));
> I think the following condition matches the criterion? :
> > I think the code will be much clearer if it explicitly says
> > ROUND_ROUNDEVEN | ROUND_NO_EXC,
>
>      else if (TARGET_64BIT || (<MODE>mode != DFmode))
>     {
>       if (ROUND_<ROUNDING> == ROUND_FLOOR)
>         ix86_expand_floorceil (operands[0], operands[1], true);
>       else if (ROUND_<ROUNDING> == ROUND_CEIL)
>         ix86_expand_floorceil (operands[0], operands[1], false);
>       else if (ROUND_<ROUNDING> == ROUND_TRUNC)
>         ix86_expand_trunc (operands[0], operands[1]);
>       else
>         gcc_unreachable ();
>     }
> in:
> (define_expand "<rounding_insn><mode>2"
> But with -mavx, generated the vroundsd insn. Does it mean ROUNDEVEN
> should have a condition in the else if, but comments above
> ix86_expand* functions in i386-expand.c says that those are for SSE2
> sequences?
>
> Thanks,
> --Tejas
>
>
> On Mon, 17 Jun 2019 at 22:45, Joseph Myers <joseph@codesourcery.com> wrote:
> >
> > On Mon, 17 Jun 2019, Tejas Joshi wrote:
> >
> > > > existing ROUND_NO_EXC definition in GCC.  A new definition will need
> > > > adding alongside ROUND_FLOOR, ROUND_CEIL and ROUND_TRUNC to correspond to
> > > > rounding to nearest with ties to even, evaluating to 0.)
> > >
> > > So (ROUND_ROUNDEVEN   0x0) be declared for rounding towards nearest
> > > even for rounding mode argument? But reference says that RC field
> > > should end up as 00B for rounding ties to even? I am also much
> >
> > I think the code will be much clearer if it explicitly says
> > ROUND_ROUNDEVEN | ROUND_NO_EXC, than if it hardcodes implicit knowledge
> > that 0 is the value used for rounding to nearest with ties to even.
> >
> > --
> > Joseph S. Myers
> > joseph@codesourcery.com

[-- Attachment #2: roundeven-md1.patch --]
[-- Type: application/x-patch, Size: 5776 bytes --]

Re: Expanding roundeven (Was: Re: About GSOC.)

[Jan Hubicka]

> Hello.
> I have already sent a patch for expanding roundeven for i386 with
> relevant doubts. I also was regression testing with
> make -k check
> after successful bootstrap build with reverting my patches. Turns out
> do-check fails without any patches applied, Is it ok to do anyways for
> applied patch? Also, /contrib/compare_tests returns with "no common
> files to compare" but I see all as the same files (actually, I am
> moving *.sum files in manual directory and comparing with build of
> applied patch.)? Is it due to failed make check?

The usual procedure is to do make check on clean tree and use
contrib/test_summary to produce summary and then do the same
with patched tree and compare the outputs (by diff)

Honza
> 
> Thanks,
> -Tejas
> 
> 
> On Wed, 19 Jun 2019 at 19:07, Tejas Joshi <tejasjoshi9673@gmail.com> wrote:
> >
> > Hello.
> > I have made following changes to inspect inlining of roundeven with
> > the following test code:
> > double
> > plusone (double d)
> > {
> >     return __builtin_roundeven (d) + 1;
> > }
> >
> > Running the program using -O2 foo.c gave internal compiler error which
> > I believe is because gcc_unreachable() at:
> >
> > if (TARGET_SSE4_1)
> >     emit_insn (gen_sse4_1_round<mode>2
> >            (operands[0], operands[1], GEN_INT (ROUND_<ROUNDING>
> >                                | ROUND_NO_EXC)));
> > I think the following condition matches the criterion? :
> > > I think the code will be much clearer if it explicitly says
> > > ROUND_ROUNDEVEN | ROUND_NO_EXC,
> >
> >      else if (TARGET_64BIT || (<MODE>mode != DFmode))
> >     {
> >       if (ROUND_<ROUNDING> == ROUND_FLOOR)
> >         ix86_expand_floorceil (operands[0], operands[1], true);
> >       else if (ROUND_<ROUNDING> == ROUND_CEIL)
> >         ix86_expand_floorceil (operands[0], operands[1], false);
> >       else if (ROUND_<ROUNDING> == ROUND_TRUNC)
> >         ix86_expand_trunc (operands[0], operands[1]);
> >       else
> >         gcc_unreachable ();
> >     }
> > in:
> > (define_expand "<rounding_insn><mode>2"
> > But with -mavx, generated the vroundsd insn. Does it mean ROUNDEVEN
> > should have a condition in the else if, but comments above
> > ix86_expand* functions in i386-expand.c says that those are for SSE2
> > sequences?
> >
> > Thanks,
> > --Tejas
> >
> >
> > On Mon, 17 Jun 2019 at 22:45, Joseph Myers <joseph@codesourcery.com> wrote:
> > >
> > > On Mon, 17 Jun 2019, Tejas Joshi wrote:
> > >
> > > > > existing ROUND_NO_EXC definition in GCC.  A new definition will need
> > > > > adding alongside ROUND_FLOOR, ROUND_CEIL and ROUND_TRUNC to correspond to
> > > > > rounding to nearest with ties to even, evaluating to 0.)
> > > >
> > > > So (ROUND_ROUNDEVEN   0x0) be declared for rounding towards nearest
> > > > even for rounding mode argument? But reference says that RC field
> > > > should end up as 00B for rounding ties to even? I am also much
> > >
> > > I think the code will be much clearer if it explicitly says
> > > ROUND_ROUNDEVEN | ROUND_NO_EXC, than if it hardcodes implicit knowledge
> > > that 0 is the value used for rounding to nearest with ties to even.
> > >
> > > --
> > > Joseph S. Myers
> > > joseph@codesourcery.com

Re: Expanding roundeven (Was: Re: About GSOC.)

[Joseph Myers]

On Fri, 14 Jun 2019, Martin Jambor wrote:

> Make sure you compile to a target that has the rounding instruction,
> i.e. by using an appropriate -march or -mavx) and also specify
> -ffast-math on the command line.  I have not double checked, but I
> assume the latter is necessary (mainly) because it implies
> -fno-math-errno and most of the math builtin expansion into instructions
> is guarded by check for !flag_errno_math.

fast-math should not be needed; roundeven should never set errno; the only 
exception it should ever raise should be "invalid" for signaling NaN 
arguments (a correct implementation should never raise "inexact").

(TS 18661-1 leaves it implementation-defined whether a signaling NaN input 
to a libm function causes a domain error.  If we find an implementation 
where libm implements semantics such that it does cause a domain error and 
where errno is set for domain errors, *and* we wish the built-in functions 
to be consistent with that, that would be the point to consider a 
conditional to disable such expansion for flag_errno_math && 
flag_signaling_nans.)

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: About GSOC.

[Segher Boessenkool]

On Fri, May 31, 2019 at 12:11:18PM +0200, Martin Jambor wrote:
> On Thu, May 30 2019, Segher Boessenkool wrote:
> > On Thu, May 30, 2019 at 07:08:45PM +0200, Martin Jambor wrote:
> >> Interesting, I was also puzzled for a moment.  But notice that:
> >> 
> >> int main ()
> >> {
> >>     _Float128 x = 18446744073709551617.5f128;
> >>     _Float128 y = __builtin_roundf128 (x);
> >> }
> >> 
> >> behaves as expected... the difference is of course the suffix pegged to
> >> the literal constant (see
> >> https://gcc.gnu.org/onlinedocs/gcc-9.1.0/gcc/Floating-Types.html).
> >> 
> >> I would also expect GCC to use a larger type if a constant does not fit
> >> into a double, but apparently that does not happen.  I would have to
> >> check but it is probably the right behavior according to the standard.
> >
> > 6.4.4.2/4: "An unsuffixed floating constant has type double."  I don't
> > think your suggestion would be okay?
> 
> Sorry if I was not clear but I was definitely not suggesting that we
> change this (or anything).  I wrote that I was also surprised but
> believed that GCC was doing the correct thing.

Ah I see.  Yeah it tricked me too :-)

> Thanks for pointing out where exactly the standard says what has to be
> done though.

The text doesn't really leave room for extensions, either.


Segher

Re: About GSOC.

[Nathan Sidwell]

On 5/30/19 5:38 PM, Segher Boessenkool wrote:
> On Thu, May 30, 2019 at 07:08:45PM +0200, Martin Jambor wrote:
>> Interesting, I was also puzzled for a moment.  But notice that:
>>
>> int main ()
>> {
>>      _Float128 x = 18446744073709551617.5f128;
>>      _Float128 y = __builtin_roundf128 (x);
>> }
>>
>> behaves as expected... the difference is of course the suffix pegged to
>> the literal constant (see
>> https://gcc.gnu.org/onlinedocs/gcc-9.1.0/gcc/Floating-Types.html).
>>
>> I would also expect GCC to use a larger type if a constant does not fit
>> into a double, but apparently that does not happen.  I would have to
>> check but it is probably the right behavior according to the standard.
> 
> 6.4.4.2/4: "An unsuffixed floating constant has type double."  I don't
> think your suggestion would be okay?

Not only that, but

1) there isn't a literal suffix to mean 'double', so one couldn't 
override that extended type.
2) how do you define 'doesn't fit'?  decimal 0.1 has a recurring binary 
representation.  Should that become the longest floating point type?

nathan

-- 
Nathan Sidwell

Re: About GSOC.

[Eric Gallager]

On 5/31/19, Nathan Sidwell <nathan@acm.org> wrote:
> On 5/30/19 5:38 PM, Segher Boessenkool wrote:
>> On Thu, May 30, 2019 at 07:08:45PM +0200, Martin Jambor wrote:
>>> Interesting, I was also puzzled for a moment.  But notice that:
>>>
>>> int main ()
>>> {
>>>      _Float128 x = 18446744073709551617.5f128;
>>>      _Float128 y = __builtin_roundf128 (x);
>>> }
>>>
>>> behaves as expected... the difference is of course the suffix pegged to
>>> the literal constant (see
>>> https://gcc.gnu.org/onlinedocs/gcc-9.1.0/gcc/Floating-Types.html).
>>>
>>> I would also expect GCC to use a larger type if a constant does not fit
>>> into a double, but apparently that does not happen.  I would have to
>>> check but it is probably the right behavior according to the standard.
>>
>> 6.4.4.2/4: "An unsuffixed floating constant has type double."  I don't
>> think your suggestion would be okay?
>
> Not only that, but
>
> 1) there isn't a literal suffix to mean 'double', so one couldn't
> override that extended type.

There's not a standard one, but there is 'D' or 'd' as a GNU
extension. The fact that it's nonstandard, though, is what causes some
projects to ignore -Wunsuffixed-float-constants:
https://lists.gnu.org/archive/html/bug-gzip/2011-11/msg00017.html

> 2) how do you define 'doesn't fit'?  decimal 0.1 has a recurring binary
> representation.  Should that become the longest floating point type?
>
> nathan
>
> --
> Nathan Sidwell
>

Re: About GSOC.

[Tejas Joshi]

[-- Attachment #1: Type: text/plain, Size: 2437 bytes --]

Hello.
I have already sent a patch for roundeven implementation but I do not
know how do I commit my changes to GCC. Am I supposed to create a
branch or anything etc?
Also I have been trying to do folding for constant arguments and
inspecting for only func (func (x)) -> func (x) right now. I made some
changes to make this work including like :
+(for fns (TRUNC_ALL FLOOR_ALL CEIL_ALL ROUND_ALL ROUNDEVEN_ALL
NEARBYINT_ALL RINT_ALL)

Also, BUILT_IN_ROUNDEVEN instead of ROUNDEVEN_ALL is not working here.
Other changes regarding to this after inspecting round are included in
this patch, but this seems not working and I am surely missing
something. Do I need to include roundeven like round:

DEFINE_INT_AND_FLOAT_ROUND_FN (ROUND)

but this would require defining IROUNDEVEN in builtins.def but it is
not supposed to?

Thanks,
--Tejas

On Fri, 31 May 2019 at 19:00, Eric Gallager <egall@gwmail.gwu.edu> wrote:
>
> On 5/31/19, Nathan Sidwell <nathan@acm.org> wrote:
> > On 5/30/19 5:38 PM, Segher Boessenkool wrote:
> >> On Thu, May 30, 2019 at 07:08:45PM +0200, Martin Jambor wrote:
> >>> Interesting, I was also puzzled for a moment.  But notice that:
> >>>
> >>> int main ()
> >>> {
> >>>      _Float128 x = 18446744073709551617.5f128;
> >>>      _Float128 y = __builtin_roundf128 (x);
> >>> }
> >>>
> >>> behaves as expected... the difference is of course the suffix pegged to
> >>> the literal constant (see
> >>> https://gcc.gnu.org/onlinedocs/gcc-9.1.0/gcc/Floating-Types.html).
> >>>
> >>> I would also expect GCC to use a larger type if a constant does not fit
> >>> into a double, but apparently that does not happen.  I would have to
> >>> check but it is probably the right behavior according to the standard.
> >>
> >> 6.4.4.2/4: "An unsuffixed floating constant has type double."  I don't
> >> think your suggestion would be okay?
> >
> > Not only that, but
> >
> > 1) there isn't a literal suffix to mean 'double', so one couldn't
> > override that extended type.
>
> There's not a standard one, but there is 'D' or 'd' as a GNU
> extension. The fact that it's nonstandard, though, is what causes some
> projects to ignore -Wunsuffixed-float-constants:
> https://lists.gnu.org/archive/html/bug-gzip/2011-11/msg00017.html
>
> > 2) how do you define 'doesn't fit'?  decimal 0.1 has a recurring binary
> > representation.  Should that become the longest floating point type?
> >
> > nathan
> >
> > --
> > Nathan Sidwell
> >

[-- Attachment #2: roundeven.patch --]
[-- Type: text/x-patch, Size: 8531 bytes --]

diff --git a/gcc/builtins.c b/gcc/builtins.c
index 25e01e4092b..0b2d6bf82f9 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -2067,6 +2067,7 @@ mathfn_built_in_2 (tree type, combined_fn fn)
     CASE_MATHFN (REMQUO)
     CASE_MATHFN_FLOATN (RINT)
     CASE_MATHFN_FLOATN (ROUND)
+    CASE_MATHFN (ROUNDEVEN)
     CASE_MATHFN (SCALB)
     CASE_MATHFN (SCALBLN)
     CASE_MATHFN (SCALBN)
diff --git a/gcc/builtins.def b/gcc/builtins.def
index ef89729fd0c..f284a3eae3b 100644
--- a/gcc/builtins.def
+++ b/gcc/builtins.def
@@ -542,12 +542,18 @@ DEF_C99_BUILTIN        (BUILT_IN_RINTL, "rintl", BT_FN_LONGDOUBLE_LONGDOUBLE, AT
 #define RINT_TYPE(F) BT_FN_##F##_##F
 DEF_EXT_LIB_FLOATN_NX_BUILTINS (BUILT_IN_RINT, "rint", RINT_TYPE, ATTR_CONST_NOTHROW_LEAF_LIST)
 #undef RINT_TYPE
+DEF_EXT_LIB_BUILTIN    (BUILT_IN_ROUNDEVEN, "roundeven", BT_FN_DOUBLE_DOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
+DEF_EXT_LIB_BUILTIN    (BUILT_IN_ROUNDEVENF, "roundevenf", BT_FN_FLOAT_FLOAT, ATTR_CONST_NOTHROW_LEAF_LIST)
+DEF_EXT_LIB_BUILTIN    (BUILT_IN_ROUNDEVENL, "roundevenl", BT_FN_LONGDOUBLE_LONGDOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_C99_BUILTIN        (BUILT_IN_ROUND, "round", BT_FN_DOUBLE_DOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_C99_BUILTIN        (BUILT_IN_ROUNDF, "roundf", BT_FN_FLOAT_FLOAT, ATTR_CONST_NOTHROW_LEAF_LIST)
 DEF_C99_BUILTIN        (BUILT_IN_ROUNDL, "roundl", BT_FN_LONGDOUBLE_LONGDOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
 #define ROUND_TYPE(F) BT_FN_##F##_##F
 DEF_EXT_LIB_FLOATN_NX_BUILTINS (BUILT_IN_ROUND, "round", ROUND_TYPE, ATTR_CONST_NOTHROW_LEAF_LIST)
 #undef ROUND_TYPE
+#define ROUNDEVEN_TYPE(F) BT_FN_##F##_##F
+DEF_EXT_LIB_FLOATN_NX_BUILTINS (BUILT_IN_ROUNDEVEN, "roundeven", ROUNDEVEN_TYPE, ATTR_CONST_NOTHROW_LEAF_LIST)
+#undef ROUNDEVEN_TYPE
 DEF_EXT_LIB_BUILTIN    (BUILT_IN_SCALB, "scalb", BT_FN_DOUBLE_DOUBLE_DOUBLE, ATTR_MATHFN_FPROUNDING_ERRNO)
 DEF_EXT_LIB_BUILTIN    (BUILT_IN_SCALBF, "scalbf", BT_FN_FLOAT_FLOAT_FLOAT, ATTR_MATHFN_FPROUNDING_ERRNO)
 DEF_EXT_LIB_BUILTIN    (BUILT_IN_SCALBL, "scalbl", BT_FN_LONGDOUBLE_LONGDOUBLE_LONGDOUBLE, ATTR_MATHFN_FPROUNDING_ERRNO)
diff --git a/gcc/fold-const-call.c b/gcc/fold-const-call.c
index 06a420601c0..54315d057a2 100644
--- a/gcc/fold-const-call.c
+++ b/gcc/fold-const-call.c
@@ -792,6 +792,15 @@ fold_const_call_ss (real_value *result, combined_fn fn,
 	}
       return false;
 
+    CASE_CFN_ROUNDEVEN:
+    CASE_CFN_ROUNDEVEN_FN:
+      if (!REAL_VALUE_ISNAN (*arg) || !flag_errno_math)
+  {
+    real_roundeven (result, format, arg);
+    return true;
+  }
+      return false;
+
     CASE_CFN_LOGB:
       return fold_const_logb (result, arg, format);
 
@@ -854,6 +863,10 @@ fold_const_call_ss (wide_int *result, combined_fn fn,
       return fold_const_conversion (result, real_round, arg,
 				    precision, format);
 
+    CASE_CFN_ROUNDEVEN:
+    CASE_CFN_ROUNDEVEN_FN:
+      return fold_const_conversion (result, real_roundeven, arg, precision, format);
+
     CASE_CFN_IRINT:
     CASE_CFN_LRINT:
     CASE_CFN_LLRINT:
diff --git a/gcc/fold-const.c b/gcc/fold-const.c
index 59cedeafd71..ab96f197d5f 100644
--- a/gcc/fold-const.c
+++ b/gcc/fold-const.c
@@ -329,6 +329,8 @@ negate_mathfn_p (combined_fn fn)
     CASE_CFN_LLROUND:
     CASE_CFN_LROUND:
     CASE_CFN_ROUND:
+    CASE_CFN_ROUNDEVEN:
+    CASE_CFN_ROUNDEVEN_FN:
     CASE_CFN_SIN:
     CASE_CFN_SINH:
     CASE_CFN_TAN:
@@ -13060,6 +13062,8 @@ tree_call_nonnegative_warnv_p (tree type, combined_fn fn, tree arg0, tree arg1,
     CASE_CFN_RINT_FN:
     CASE_CFN_ROUND:
     CASE_CFN_ROUND_FN:
+    CASE_CFN_ROUNDEVEN:
+    CASE_CFN_ROUNDEVEN_FN:
     CASE_CFN_SCALB:
     CASE_CFN_SCALBLN:
     CASE_CFN_SCALBN:
@@ -13583,6 +13587,8 @@ integer_valued_real_call_p (combined_fn fn, tree arg0, tree arg1, int depth)
     CASE_CFN_RINT_FN:
     CASE_CFN_ROUND:
     CASE_CFN_ROUND_FN:
+    CASE_CFN_ROUNDEVEN:
+    CASE_CFN_ROUNDEVEN_FN:
     CASE_CFN_TRUNC:
     CASE_CFN_TRUNC_FN:
       return true;
diff --git a/gcc/internal-fn.def b/gcc/internal-fn.def
index cda314e1121..b89918815f9 100644
--- a/gcc/internal-fn.def
+++ b/gcc/internal-fn.def
@@ -224,6 +224,7 @@ DEF_INTERNAL_FLT_FLOATN_FN (FLOOR, ECF_CONST, floor, unary)
 DEF_INTERNAL_FLT_FLOATN_FN (NEARBYINT, ECF_CONST, nearbyint, unary)
 DEF_INTERNAL_FLT_FLOATN_FN (RINT, ECF_CONST, rint, unary)
 DEF_INTERNAL_FLT_FLOATN_FN (ROUND, ECF_CONST, round, unary)
+DEF_INTERNAL_FLT_FLOATN_FN (ROUNDEVEN, ECF_CONST, roundeven, unary)
 DEF_INTERNAL_FLT_FLOATN_FN (TRUNC, ECF_CONST, btrunc, unary)
 
 /* Binary math functions.  */
diff --git a/gcc/match.pd b/gcc/match.pd
index 7cc2374ffeb..98f4729f42d 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -4229,7 +4229,7 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
  (abs @0))
 
 /* trunc(trunc(x)) -> trunc(x), etc.  */
-(for fns (TRUNC_ALL FLOOR_ALL CEIL_ALL ROUND_ALL NEARBYINT_ALL RINT_ALL)
+(for fns (TRUNC_ALL FLOOR_ALL CEIL_ALL ROUND_ALL ROUNDEVEN_ALL NEARBYINT_ALL RINT_ALL)
  (simplify
   (fns (fns @0))
   (fns @0)))
diff --git a/gcc/optabs.def b/gcc/optabs.def
index 5a67f5eed5e..eb9e22acd8f 100644
--- a/gcc/optabs.def
+++ b/gcc/optabs.def
@@ -267,6 +267,7 @@ OPTAB_D (fnms_optab, "fnms$a4")
 
 OPTAB_D (rint_optab, "rint$a2")
 OPTAB_D (round_optab, "round$a2")
+OPTAB_D (roundeven_optab, "roundeven$a2")
 OPTAB_D (floor_optab, "floor$a2")
 OPTAB_D (ceil_optab, "ceil$a2")
 OPTAB_D (btrunc_optab, "btrunc$a2")
diff --git a/gcc/real.c b/gcc/real.c
index f822ae82d61..19c704ec0ec 100644
--- a/gcc/real.c
+++ b/gcc/real.c
@@ -5010,6 +5010,81 @@ real_round (REAL_VALUE_TYPE *r, format_helper fmt,
     real_convert (r, fmt, r);
 }
 
+/* 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;
+
+  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;
+}
+
+/* Return true if R is halfway between two integers, else return false. */
+
+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);
+
+    if (((r->sig[SIGSZ-1] & temp) != 0) && ((r->sig[SIGSZ-1] & (temp-1)) == 0))
+      return true;
+    else
+      return false;
+  }
+
+  else if (REAL_EXP (r) < SIGNIFICAND_BITS)
+  {
+    unsigned int n = SIGNIFICAND_BITS - REAL_EXP (r);
+    int i, w = n / HOST_BITS_PER_LONG;
+
+    for (i = 0; i < w; ++i)
+    {
+      if (r->sig[i] != 0)
+        return false;
+    }
+
+    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;
+  }
+  return false;
+}
+
+/* Round X to nearest integer, rounding halfway cases towards even. */
+
+void
+real_roundeven (REAL_VALUE_TYPE *r, format_helper fmt,
+		const REAL_VALUE_TYPE *x)
+{
+  fprintf (stderr, "\n%s\n", "in roundeven");
+  if (is_halfway_below (x))
+  {
+    do_add (r, x, &dconsthalf, x->sign);
+    if (!is_even (r))
+      do_add (r, r, &dconstm1, x->sign);
+  }
+  else
+    real_round (r, fmt, x);
+}
+
 /* Set the sign of R to the sign of X.  */
 
 void
diff --git a/gcc/real.h b/gcc/real.h
index 0ce42565708..ebe66d234af 100644
--- a/gcc/real.h
+++ b/gcc/real.h
@@ -41,11 +41,18 @@ struct GTY(()) real_value {
      sure they're packed together, otherwise REAL_VALUE_TYPE_SIZE will
      be miscomputed.  */
   unsigned int /* ENUM_BITFIELD (real_value_class) */ cl : 2;
+  /* 1 if number is decimal floating point */
   unsigned int decimal : 1;
+  /* 1 if number is negative */
   unsigned int sign : 1;
+  /* 1 if number is signalling */
   unsigned int signalling : 1;
+  /* 1 if number is canonical
+  All are generally used for handling cases in real.c */
   unsigned int canonical : 1;
+  /* unbiased exponent of the number */
   unsigned int uexp : EXP_BITS;
+  /* significand of the number */
   unsigned long sig[SIGSZ];
 };
 
@@ -499,6 +506,8 @@ extern void real_ceil (REAL_VALUE_TYPE *, format_helper,
 		       const REAL_VALUE_TYPE *);
 extern void real_round (REAL_VALUE_TYPE *, format_helper,
 			const REAL_VALUE_TYPE *);
+extern void real_roundeven (REAL_VALUE_TYPE *, format_helper,
+      const REAL_VALUE_TYPE *);
 
 /* Set the sign of R to the sign of X.  */
 extern void real_copysign (REAL_VALUE_TYPE *, const REAL_VALUE_TYPE *);

Committing patches and other conventions (Was: Re: About GSOC)

[Martin Jambor]

Hi,

On Mon, Jun 03 2019, Tejas Joshi wrote:
> Hello.
> I have already sent a patch for roundeven implementation but I do not
> know how do I commit my changes to GCC. Am I supposed to create a
> branch or anything etc?

You don't have to create a branch unless you think it would make ease
your own workflow.  Once a patch is ready to go and has been explicitely
approved by a corresponding maintainer, you will be expected to commit
it directly to svn (we'll ask for a svn write access for you when we get
to that point).  You'll find the list of maintainers in the MAINTAINERS
file of the gcc repository, I believe your patches will need approval
from a global reviewer, most probably Joseph.

Before that happens, the code must be of course considered correct but
also must adhere to some conventions, please see
https://gcc.gnu.org/codingconventions.html.  Your patches so far lacked
a ChangeLog and testcases.  Have a look at what other do when they post
patches to gcc-patches: https://gcc.gnu.org/ml/gcc-patches/2019-06/

ChangeLog has to have the given, fairly strict format, but should be
very brief.  When posting patches, you don't make it part of the patch
even though when committing, you are expected it to prepend the
corresponding ChangeLog file with your bit (see e.g. gcc/ChangeLog and
gcc/testsuite/ChangeLog).

You have always stated how you tested your patches but you are actually
supposed to add the testsuite and committed along with the functional
patch, so that other can then test they do not regress on the
functionality you have just added.

That is why everybody including you has to test their patches also by
doing:

make bootstrap
make -k check

(with a -j level appropriate for your computer) and then collect *.sum
files from unpatched and patched runs and compare them (see script in
contrib/compare_tests) to make sure they did not introduce any
regressions.

See section on "Testing patches" at https://gcc.gnu.org/contribute.html
for more details.

Please ask about these mechanisms and conventions if anything is not
clear.  I'll go and find the latest version of your roundeven patch and
see if I can help you a little (but I am likely to finish that only
tomorrow morning).

Thanks,

Martin

Re: Committing patches and other conventions (Was: Re: About GSOC)

[Tejas Joshi]

Thank you for this mail.
As soon as the implementation of roundeven is approved, I will do the
documentation in ChangeLogs wherever necessary and the testing part.
Will also make changes where my code does not match the GCC coding
conventions and will try to follow it further.

Thanks.
-Tejas

On Thu, 6 Jun 2019 at 22:26, Martin Jambor <mjambor@suse.cz> wrote:
>
> Hi,
>
> On Mon, Jun 03 2019, Tejas Joshi wrote:
> > Hello.
> > I have already sent a patch for roundeven implementation but I do not
> > know how do I commit my changes to GCC. Am I supposed to create a
> > branch or anything etc?
>
> You don't have to create a branch unless you think it would make ease
> your own workflow.  Once a patch is ready to go and has been explicitely
> approved by a corresponding maintainer, you will be expected to commit
> it directly to svn (we'll ask for a svn write access for you when we get
> to that point).  You'll find the list of maintainers in the MAINTAINERS
> file of the gcc repository, I believe your patches will need approval
> from a global reviewer, most probably Joseph.
>
> Before that happens, the code must be of course considered correct but
> also must adhere to some conventions, please see
> https://gcc.gnu.org/codingconventions.html.  Your patches so far lacked
> a ChangeLog and testcases.  Have a look at what other do when they post
> patches to gcc-patches: https://gcc.gnu.org/ml/gcc-patches/2019-06/
>
> ChangeLog has to have the given, fairly strict format, but should be
> very brief.  When posting patches, you don't make it part of the patch
> even though when committing, you are expected it to prepend the
> corresponding ChangeLog file with your bit (see e.g. gcc/ChangeLog and
> gcc/testsuite/ChangeLog).
>
> You have always stated how you tested your patches but you are actually
> supposed to add the testsuite and committed along with the functional
> patch, so that other can then test they do not regress on the
> functionality you have just added.
>
> That is why everybody including you has to test their patches also by
> doing:
>
> make bootstrap
> make -k check
>
> (with a -j level appropriate for your computer) and then collect *.sum
> files from unpatched and patched runs and compare them (see script in
> contrib/compare_tests) to make sure they did not introduce any
> regressions.
>
> See section on "Testing patches" at https://gcc.gnu.org/contribute.html
> for more details.
>
> Please ask about these mechanisms and conventions if anything is not
> clear.  I'll go and find the latest version of your roundeven patch and
> see if I can help you a little (but I am likely to finish that only
> tomorrow morning).
>
> Thanks,
>
> Martin

Re: Committing patches and other conventions (Was: Re: About GSOC)

[Tejas Joshi]

Hello.
Is this the correct sequence for regression test:
1. Revert back all the changes I made and then configure, build along with
make bootstrap
make -k check
collect the *.sum files
2. Apply the patch and do the configuration, build as above 1 and then
collect the *.sum files and compare them.

How do I collect and inspect these *.sum files?

Thanks,
-Tejas

On Thu, 6 Jun 2019 at 22:26, Martin Jambor <mjambor@suse.cz> wrote:
>
> Hi,
>
> On Mon, Jun 03 2019, Tejas Joshi wrote:
> > Hello.
> > I have already sent a patch for roundeven implementation but I do not
> > know how do I commit my changes to GCC. Am I supposed to create a
> > branch or anything etc?
>
> You don't have to create a branch unless you think it would make ease
> your own workflow.  Once a patch is ready to go and has been explicitely
> approved by a corresponding maintainer, you will be expected to commit
> it directly to svn (we'll ask for a svn write access for you when we get
> to that point).  You'll find the list of maintainers in the MAINTAINERS
> file of the gcc repository, I believe your patches will need approval
> from a global reviewer, most probably Joseph.
>
> Before that happens, the code must be of course considered correct but
> also must adhere to some conventions, please see
> https://gcc.gnu.org/codingconventions.html.  Your patches so far lacked
> a ChangeLog and testcases.  Have a look at what other do when they post
> patches to gcc-patches: https://gcc.gnu.org/ml/gcc-patches/2019-06/
>
> ChangeLog has to have the given, fairly strict format, but should be
> very brief.  When posting patches, you don't make it part of the patch
> even though when committing, you are expected it to prepend the
> corresponding ChangeLog file with your bit (see e.g. gcc/ChangeLog and
> gcc/testsuite/ChangeLog).
>
> You have always stated how you tested your patches but you are actually
> supposed to add the testsuite and committed along with the functional
> patch, so that other can then test they do not regress on the
> functionality you have just added.
>
> That is why everybody including you has to test their patches also by
> doing:
>
> make bootstrap
> make -k check
>
> (with a -j level appropriate for your computer) and then collect *.sum
> files from unpatched and patched runs and compare them (see script in
> contrib/compare_tests) to make sure they did not introduce any
> regressions.
>
> See section on "Testing patches" at https://gcc.gnu.org/contribute.html
> for more details.
>
> Please ask about these mechanisms and conventions if anything is not
> clear.  I'll go and find the latest version of your roundeven patch and
> see if I can help you a little (but I am likely to finish that only
> tomorrow morning).
>
> Thanks,
>
> Martin

Re: Committing patches and other conventions (Was: Re: About GSOC)

[Martin Jambor]

Hi Tejas,

On Wed, Jun 12 2019, Tejas Joshi wrote:
> Hello.
> Is this the correct sequence for regression test:
> 1. Revert back all the changes I made and then configure, build along with
> make bootstrap
> make -k check
> collect the *.sum files
> 2. Apply the patch and do the configuration, build as above 1 and then
> collect the *.sum files and compare them.

Yes, exactly  (make sure to pass an appropriate -j parameter to make, of
course).

>
> How do I collect and inspect these *.sum files?

I collect *.sum files with a small script that internally simply does

  cp -vp `find . -name '*.sum' -print` $DEST_DIRECTORY

with different $DEST_DIR for pristine trunk and the patched version.

I admit I have my own script for comparing *.sum files but the usual way
is to use the compare_tests in the contrib directory, so for comparing
the old and new gcc.sum, you would do something like:

  ./src/contrib/compare_tests ../trunk/logs/gcc.sum logs/gcc.sum

with the directories matching your setup, of course.

Writing about scripts in contrib, you might also want to look at
check_GNU_style.sh and/or check_GNU_style.py.  They take a patch file as
they argument and check GNU style (things like two spaces after each
sentence, long lines, these tiny things where we still however try to be
consistent).  Of course, some of the errors given should be ignored,
in your case probably long lines in a *.def file.

Hope this helps,

Martin

About gsoc

[mokshagnareddyc]

Hello sir/mam
I am mokshagna reddy from Mahindra university and i am currently in my second year of under graduation in Btech artificial intelligence i had intrest in your organization and i know programming languages like c, c++,python   how can i contribute from now and can u send details about the project . Thank you hope i will get reply as soon as possible.
Sent from my iPhone

Re: About gsoc

[Jonathan Wakely]

On Mon, 4 Mar 2024 at 06:58, mokshagnareddyc--- via Gcc <gcc@gcc.gnu.org> wrote:
>
> Hello sir/mam
> I am mokshagna reddy from Mahindra university and i am currently in my second year of under graduation in Btech artificial intelligence i had intrest in your organization and i know programming languages like c, c++,python   how can i contribute from now and can u send details about the project . Thank you hope i will get reply as soon as possible.

If you want to apply for GSoC and convince people you're a suitable
candidate and would invest the necessary time and effort, maybe you
should find details of the project for yourself instead of asking
others to provide them.

A simple web search would have found https://gcc.gnu.org/wiki/SummerOfCode

Re: About gsoc

[Dave Blanchard]

On Mon, 4 Mar 2024 10:06:34 +0000
Jonathan Wakely via Gcc <gcc@gcc.gnu.org> wrote:

> On Mon, 4 Mar 2024 at 06:58, mokshagnareddyc--- via Gcc <gcc@gcc.gnu.org> wrote:
> >
> > Hello sir/mam
> > I am mokshagna reddy from Mahindra university and i am currently in my second year of under graduation in Btech artificial intelligence i had intrest in your organization and i know programming languages like c, c++,python   how can i contribute from now and can u send details about the project . Thank you hope i will get reply as soon as possible.
> 
> If you want to apply for GSoC and convince people you're a suitable
> candidate and would invest the necessary time and effort, maybe you
> should find details of the project for yourself instead of asking
> others to provide them.
> 
> A simple web search would have found https://gcc.gnu.org/wiki/SummerOfCode

Wow, what a fucking prick this guy is.

My apologies to our friend Mr. Mokshagna Reddy for this extreme rudeness. 

Maybe he did you a favor with such a response. Why should anyone waste their time and energy donating free work to a dumpster fire project like GCC, when this is the thanks you get? I recommend contributing your valuable time to LLVM/clang or some other non-GNU project instead, where it will likely be more appreciated.

Dave

Re: About gsoc

[Jonathan Wakely]

On Tue, 5 Mar 2024 at 01:59, Dave Blanchard <dave@killthe.net> wrote:
>
> On Mon, 4 Mar 2024 10:06:34 +0000
> Jonathan Wakely via Gcc <gcc@gcc.gnu.org> wrote:
>
> > On Mon, 4 Mar 2024 at 06:58, mokshagnareddyc--- via Gcc <gcc@gcc.gnu.org> wrote:
> > >
> > > Hello sir/mam
> > > I am mokshagna reddy from Mahindra university and i am currently in my second year of under graduation in Btech artificial intelligence i had intrest in your organization and i know programming languages like c, c++,python   how can i contribute from now and can u send details about the project . Thank you hope i will get reply as soon as possible.
> >
> > If you want to apply for GSoC and convince people you're a suitable
> > candidate and would invest the necessary time and effort, maybe you
> > should find details of the project for yourself instead of asking
> > others to provide them.
> >
> > A simple web search would have found https://gcc.gnu.org/wiki/SummerOfCode
>
> Wow, what a fucking prick this guy is.
>
> My apologies to our friend Mr. Mokshagna Reddy for this extreme rudeness.
>
> Maybe he did you a favor with such a response. Why should anyone waste their time and energy donating free work to a dumpster fire project like GCC, when this is the thanks you get? I recommend contributing your valuable time to LLVM/clang or some other non-GNU project instead, where it will likely be more appreciated.

GSoC isn't free work, it's paid. Get a clue, or go away.

Re: About gsoc

[Jonathan Wakely]

On Tue, 5 Mar 2024 at 09:31, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>
> On Tue, 5 Mar 2024 at 01:59, Dave Blanchard <dave@killthe.net> wrote:
> >
> > On Mon, 4 Mar 2024 10:06:34 +0000
> > Jonathan Wakely via Gcc <gcc@gcc.gnu.org> wrote:
> >
> > > On Mon, 4 Mar 2024 at 06:58, mokshagnareddyc--- via Gcc <gcc@gcc.gnu.org> wrote:
> > > >
> > > > Hello sir/mam
> > > > I am mokshagna reddy from Mahindra university and i am currently in my second year of under graduation in Btech artificial intelligence i had intrest in your organization and i know programming languages like c, c++,python   how can i contribute from now and can u send details about the project . Thank you hope i will get reply as soon as possible.
> > >
> > > If you want to apply for GSoC and convince people you're a suitable
> > > candidate and would invest the necessary time and effort, maybe you
> > > should find details of the project for yourself instead of asking
> > > others to provide them.
> > >
> > > A simple web search would have found https://gcc.gnu.org/wiki/SummerOfCode
> >
> > Wow, what a fucking prick this guy is.
> >
> > My apologies to our friend Mr. Mokshagna Reddy for this extreme rudeness.
> >
> > Maybe he did you a favor with such a response. Why should anyone waste their time and energy donating free work to a dumpster fire project like GCC, when this is the thanks you get? I recommend contributing your valuable time to LLVM/clang or some other non-GNU project instead, where it will likely be more appreciated.
>
> GSoC isn't free work, it's paid. Get a clue, or go away.

That's directed at Dave, in case it wasn't obvious. He contributes
nothing here except bile.

Re: About gsoc

[Dave Blanchard]

On Tue, 5 Mar 2024 09:32:26 +0000
Jonathan Wakely <jwakely.gcc@gmail.com> wrote:

> On Tue, 5 Mar 2024 at 09:31, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> >
> > On Tue, 5 Mar 2024 at 01:59, Dave Blanchard <dave@killthe.net> wrote:
> > >
> > > On Mon, 4 Mar 2024 10:06:34 +0000
> > > Jonathan Wakely via Gcc <gcc@gcc.gnu.org> wrote:
> > >
> > > > On Mon, 4 Mar 2024 at 06:58, mokshagnareddyc--- via Gcc <gcc@gcc.gnu.org> wrote:
> > > > >
> > > > > Hello sir/mam
> > > > > I am mokshagna reddy from Mahindra university and i am currently in my second year of under graduation in Btech artificial intelligence i had intrest in your organization and i know programming languages like c, c++,python   how can i contribute from now and can u send details about the project . Thank you hope i will get reply as soon as possible.
> > > >
> > > > If you want to apply for GSoC and convince people you're a suitable
> > > > candidate and would invest the necessary time and effort, maybe you
> > > > should find details of the project for yourself instead of asking
> > > > others to provide them.
> > > >
> > > > A simple web search would have found https://gcc.gnu.org/wiki/SummerOfCode
> > >
> > > Wow, what a fucking prick this guy is.
> > >
> > > My apologies to our friend Mr. Mokshagna Reddy for this extreme rudeness.
> > >
> > > Maybe he did you a favor with such a response. Why should anyone waste their time and energy donating free work to a dumpster fire project like GCC, when this is the thanks you get? I recommend contributing your valuable time to LLVM/clang or some other non-GNU project instead, where it will likely be more appreciated.
> >
> > GSoC isn't free work, it's paid. Get a clue, or go away.

Oh, I see! Since this poor young university student might expect to receive small payment  for his time spent in improving GCC--which is a very complex project that is not easily modified--therefore you're excused in treating him like yesterday's trash.

Makes perfect sense to you, I guess.

> 
> That's directed at Dave, in case it wasn't obvious. He contributes
> nothing here except bile.

Have you read any of your own posts? You are one of the biggest assholes I've encountered in the open source world, and I've met some real dicks. People like you have been driving newbies away from Linux/BSD for decades. You never learn.

What you call "bile" is merely me being the one guy who's willing to call you on your bullshit. This is hardly the first time you've shown your ass to someone who was trying to help the GCC project in some way. Remember Stefan Kanthak? Others may remember he pointed out serious problems with the GCC optimizer on x86-32 which you also rudely dismissed, calling him a noob, etc.

Are you an official representative of the GCC project, or just some random asshole who lurks here and thinks he owns the place? What do YOU actually contribute to this list that is so valuable it excuses your rudeness? I wonder if Mr. Stallman approves of you helping to drive away potential GNU contributors, at a time when this project needs fresh blood arguably more than ever. Let's find out.

Dave

Re: About gsoc

[Mark Wielaard]

Hi Dave,

On Sun, Mar 10, 2024 at 08:17:31PM -0500, Dave Blanchard wrote:
> > > On Tue, 5 Mar 2024 at 01:59, Dave Blanchard <dave@killthe.net> wrote:
> > > > Wow, what a fucking prick this guy is.
> > > > [...]
> You are one of the biggest assholes I've encountered in the open
> source world, and I've met some real dicks.

You have been warned before. Please stop sending these negative
unproductive messages to this list attacking well respected productive
maintainers of the project. Your attitude is not welcome.

Thanks,

Mark

Re: About gsoc

[Martin Jambor]

Hello,

On Mon, Mar 04 2024, mokshagnareddyc--- via Gcc wrote:
> Hello sir/mam
> I am mokshagna reddy from Mahindra university and i am currently in my
> second year of under graduation in Btech artificial intelligence i had
> intrest in your organization and i know programming languages like c,
> c++,python how can i contribute from now and can u send details about
> the project.

We are delighted you found contributing to GCC interesting.

Please note that apart from C/C++ coding skills, most projects require
some rudimentary theoretical background in compilers.

Please look again at the "Before you apply" section of our GSoC page at
https://gcc.gnu.org/wiki/SummerOfCode#Before_you_apply and make sure you
are able to build, install and test GCC.  I strongly suggest that you
also try generating dumps of the IR of a simple compiled program and
stepping through some function during compilation in a debugger.

Afterwards, look at the suggested projects, try to identify the portion
of GCC source where it needs to be implemented and think about how.
Then email us back to this mailing list describing your current plan
together with any technical questions you'd like to have answered to
proceed further.  We'll be happy to help.

Good luck,

Martin

Re: About gsoc

[Julian Waters]

Hello again, Dave. Have you managed to learn how a basic language
Interpreter works before commenting on the significantly-more-complex
gcc's efficiency? Or were you not able to because your IQ is below the
freezing point of water and you can't even understand what a basic
tree walker is?

Then again, with an address like killthe.net, why should we even take
you seriously? Hell, even though I miraculously agree that stuff like
GNU and Linux is not beginner friendly, and gcc could do with some
improvements in that department, no one wants to take any advice from
a self righteous and idiotic piece of shit like yourself. At least
Stefan was smart enough to bail when others pointed out the holes in
his examples of gcc's instruction selection allegedly being poor. You,
not so much. I doubt the clang people want you either, so do them a
favour and stay the hell away from LLVM, and this is coming from
someone who doesn't really like LLVM in the first place