From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 83732 invoked by alias); 21 Jan 2019 19:13:11 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 83721 invoked by uid 89); 21 Jan 2019 19:13:10 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-0.6 required=5.0 tests=BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,MISSING_HEADERS,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.2 spammy=me!, HX-HELO:sk:mail-ed, Though, HX-Received:a50 X-HELO: mail-ed1-f41.google.com Received: from mail-ed1-f41.google.com (HELO mail-ed1-f41.google.com) (209.85.208.41) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 21 Jan 2019 19:13:08 +0000 Received: by mail-ed1-f41.google.com with SMTP id p6so17473645eds.0 for ; Mon, 21 Jan 2019 11:13:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:cc; bh=jhK2S1HdpQlPn5xbpfFanHv5vUgAhXZlVTezscgaeF4=; b=lp2RlSJt/NjQhK5dMA5bsSS9ZGYL9smutr45LU8lTF5Hy7gsq5B8GfmHNJ6kMjw58Y 9P2eRNp3RB0MMlvFCqcVjR8eTINRNF9TjWUuDt/ixXVV4skDgWIsyyES04XgyyctgI+Y SZvuN5xV/MVbhFDG275P/ueb3DHaVumbKLg0q32E9DTnh7Cp3VkwLO5LE7vwVVZRm434 5kW6r0cRCuH2sUGPzoABPx1uqMsGPBZuyXhrTsu5uF4oRpYGMuwDiDQDvVBTWXMh4H9I H5IijY2Fmj+7W7Fbg5/idNC7RcT9LXo39XE5aHaXxsdskswvskrAThTKMuz28p3kKz5n Lbow== MIME-Version: 1.0 References: In-Reply-To: From: Tejas Joshi Date: Mon, 21 Jan 2019 19:13:00 -0000 Message-ID: Subject: Re: About GSOC. Cc: gcc@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2019-01/txt/msg00161.txt.bz2 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


On Fri, 16 Nov 2018 at 22:20, Joseph Myers <joseph@codesourcery.com> wrote:
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