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 <<a href="mailto:jos...@codesourcery.com"; target="_blank">jos...@codesourcery.com</a>> 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> > About roundeven, there might be need to add case to<br> > expand_builtin_int_roundingfn similar to<br> > ceil, for expansion.<br> > But how is round() expanded since there's no<br> > 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. <br> Those functions are of no relevance to adding support for built-in <br> roundeven. (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. But I don't think inventing __builtin_lroundeven <br> would be appropriate.)<br> <br> > Also, is it right to have an added case for roundeven in convert.c<br> > along CASE_FLT_FN (BUILT_IN_ROUND)<br> > in convert_to_integer_1?<br> <br> Not until doing things with fromfp functions. There is no lroundeven (for <br> example) in TS 18661-1.<br> <br> -- <br> Joseph S. Myers<br> <a href="mailto:jos...@codesourcery.com"; target="_blank">jos...@codesourcery.com</a><br> </blockquote></div>
