From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-199229-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 20682 invoked by alias); 31 May 2019 10:11:23 -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 20674 invoked by uid 89); 31 May 2019 10:11:23 -0000
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=-4.7 required=5.0 tests=AWL,BAYES_00,KAM_SHORT,SPF_PASS autolearn=ham version=3.3.1 spammy=
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; Fri, 31 May 2019 10:11:21 +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 290E3AFFB;	Fri, 31 May 2019 10:11:19 +0000 (UTC)
From: Martin Jambor <mjambor@suse.cz>
To: Segher Boessenkool <segher@kernel.crashing.org>
Cc: Tejas Joshi <tejasjoshi9673@gmail.com>, gcc@gcc.gnu.org, hubicka@ucw.cz
Cc:
Subject: Re: About GSOC.
In-Reply-To: <20190530213839.GF31586@gate.crashing.org>
References: <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> <ri6muj3amzm.fsf@suse.cz> <20190530213839.GF31586@gate.crashing.org>
User-Agent: Notmuch/0.28.4 (https://notmuchmail.org) Emacs/26.2 (x86_64-suse-linux-gnu)
Date: Fri, 31 May 2019 10:11:00 -0000
Message-ID: <ri6k1e79bnd.fsf@suse.cz>
MIME-Version: 1.0
Content-Type: text/plain
X-IsSubscribed: yes
X-SW-Source: 2019-05/txt/msg00274.txt.bz2

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