Re: About GSOC.

[Tejas Joshi <tejasjoshi9673@gmail.com>]

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>