From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 88138 invoked by alias); 22 Sep 2018 10:08:24 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 88124 invoked by uid 89); 22 Sep 2018 10:08:23 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: =?ISO-8859-1?Q?No, score=-0.6 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,KAM_SHORT autolearn=no version=3.3.2 spammy=lef=e8vre, Lef=e8vre, Hx-languages-length:1007, H*Ad:U*aph?= X-HELO: joooj.vinc17.net Received: from joooj.vinc17.net (HELO joooj.vinc17.net) (155.133.131.76) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 22 Sep 2018 10:08:22 +0000 Received: from smtp-zira.vinc17.net (91-163-229-198.subs.proxad.net [91.163.229.198]) by joooj.vinc17.net (Postfix) with ESMTPSA id F1EC62B8; Sat, 22 Sep 2018 12:08:19 +0200 (CEST) Received: by zira.vinc17.org (Postfix, from userid 1000) id 810DFC2008A; Sat, 22 Sep 2018 12:08:19 +0200 (CEST) Date: Sat, 22 Sep 2018 10:08:00 -0000 From: Vincent Lefevre To: Liu Hao , Andrew Haley , Neha Gowda , gcc-help@gcc.gnu.org Subject: Re: Should rand() return a RAND_MAX value for 32 bit target? Message-ID: <20180922100819.GA32380@zira.vinc17.org> Mail-Followup-To: Liu Hao , Andrew Haley , Neha Gowda , gcc-help@gcc.gnu.org References: <9194d2a2-74c0-2d51-c4b5-433d2744cd43@redhat.com> <20180920144238.GB24856@cventin.lip.ens-lyon.fr> <20180920150550.GA4852@cventin.lip.ens-lyon.fr> <590e8205.c4aa.165f7924592.Coremail.lh_mouse@126.com> <20180920155829.GA304@joooj.vinc17.net> <702886d4.135ef.165fa081a93.Coremail.lh_mouse@126.com> <20180922081704.GA25565@zira.vinc17.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20180922081704.GA25565@zira.vinc17.org> X-Mailer-Info: https://www.vinc17.net/mutt/ User-Agent: Mutt/1.10.1+96 (4350694b) vl-108074 (2018-09-18) X-IsSubscribed: yes X-SW-Source: 2018-09/txt/msg00072.txt.bz2 On 2018-09-22 10:17:04 +0200, Vincent Lefevre wrote: > Thus if one does > > float a; > int b; > > /* ... */ > a + b; > > with FLT_EVAL_METHOD = 2, the evaluation type of a is long double, b > is converted to the semantic type float, but its evaluation type is > long double, so that its value should not change if representable as > a long double. That's what FLT_EVAL_METHOD means. The *only* cases > for which the precision and range need to be reduced to those of the > semantic type if for assignment and cast, but here one just has an > implicit conversion. Bug reported here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87390 (note that the tests do not involve constants, these are just about implicit type conversions). -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)