From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-199218-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 15580 invoked by alias); 30 May 2019 17:08:50 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
Received: (qmail 15255 invoked by uid 89); 30 May 2019 17:08:49 -0000
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=-3.5 required=5.0 tests=AWL,BAYES_50,KAM_SHORT,SPF_PASS autolearn=ham version=3.3.1 spammy=Tejas, tejas, _Float128, _float128
X-HELO: mx1.suse.de
Received: from mx2.suse.de (HELO mx1.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 30 May 2019 17:08:48 +0000
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Cc"
Received: from relay2.suse.de (unknown [195.135.220.254])	by mx1.suse.de (Postfix) with ESMTP id 7D24EAF25;	Thu, 30 May 2019 17:08:46 +0000 (UTC)
From: Martin Jambor <mjambor@suse.cz>
To: Tejas Joshi <tejasjoshi9673@gmail.com>, gcc@gcc.gnu.org
Cc: hubicka@ucw.cz
Cc:
Subject: Re: About GSOC.
In-Reply-To: <CACMrGjB41A2BSPJqGs3ckH+w4xX6iXyc7Kk1siPYFm-TreKWjg@mail.gmail.com>
References: <CACMrGjCeaZ7EoYqjLYiAJXjOtOfpJNo9zcbWhfarfkiLMN8YYA@mail.gmail.com> <CACMrGjC6Gk6UFr9T5iY0OgW5PJ92bB3tSrx59+D3FK+fMGYErQ@mail.gmail.com> <CAAgBjMk+8M2MYNdePb=rNfSkkCW=ZCezQPmqkMbYHe0nVJLzwQ@mail.gmail.com> <CACMrGjBu3+X5HCbPGyzn95gpzHY+8JvkfpyQGj_DoEeCJu2GqA@mail.gmail.com> <CACMrGjATDLe-i+EqVaH4Q6gpaGLmAJ8KgnCS-9qRbxgXOmhgLg@mail.gmail.com> <CACMrGjAeHRzkrao5bxZ2SSYBU-9Kvp_Dtn7qEWbt4wiOn18cvg@mail.gmail.com> <alpine.DEB.2.21.1904011947310.25789@digraph.polyomino.org.uk> <CACMrGjCNdbQ0=cV0kDUdi-DpWp3czxEpSCzPgr13a=Ck9-3=NA@mail.gmail.com> <CACMrGjDw6JXz_PPiNDUp=jCPwXERA-pirt7NOD88upmLiciZuA@mail.gmail.com> <alpine.DEB.2.21.1905071701330.3445@digraph.polyomino.org.uk> <CACMrGjDFkKzH5Dwahe-yHF6crFLvsR-YQxNv8dJuNn2T=7Zg0g@mail.gmail.com> <CACMrGjBV5PcUU7_yzpko1RrqxGmvMKO8e07mJ5opCLFpJ1pdOg@mail.gmail.com> <CACMrGjC442-jDFG5NLX0R1LpPsz8C2TateF1GC1xTLxQcywsqw@mail.gmail.com> <ri61s0tf7n3.fsf@suse.cz> <alpine.DEB.2.21.1905202143270.19503@digraph.polyomino.org.uk> <CACMrGjB41A2BSPJqGs3ckH+w4xX6iXyc7Kk1siPYFm-TreKWjg@mail.gmail.com>
User-Agent: Notmuch/0.28.4 (https://notmuchmail.org) Emacs/26.2 (x86_64-suse-linux-gnu)
Date: Thu, 30 May 2019 17:08:00 -0000
Message-ID: <ri6muj3amzm.fsf@suse.cz>
MIME-Version: 1.0
Content-Type: text/plain
X-IsSubscribed: yes
X-SW-Source: 2019-05/txt/msg00263.txt.bz2

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