From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 82054 invoked by alias); 20 Sep 2018 15:46:43 -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 81917 invoked by uid 89); 20 Sep 2018 15:46:43 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.2 spammy=4500, MSB, msb, Hx-languages-length:1628 X-HELO: atl4mhob06.registeredsite.com Received: from atl4mhob06.registeredsite.com (HELO atl4mhob06.registeredsite.com) (209.17.115.44) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 20 Sep 2018 15:46:41 +0000 Received: from mailpod.hostingplatform.com (atl4qobmail02pod2.registeredsite.com [10.30.77.36]) by atl4mhob06.registeredsite.com (8.14.4/8.14.4) with ESMTP id w8KFkcsm011370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 20 Sep 2018 11:46:39 -0400 Received: (qmail 36192 invoked by uid 0); 20 Sep 2018 15:46:38 -0000 X-TCPREMOTEIP: 174.118.245.214 X-Authenticated-UID: dclarke@blastwave.org Received: from unknown (HELO ?172.16.35.3?) (dclarke@blastwave.org@174.118.245.214) by 0 with ESMTPA; 20 Sep 2018 15:46:38 -0000 Subject: Re: Should rand() return a RAND_MAX value for 32 bit target? To: 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> From: Dennis Clarke Message-ID: Date: Thu, 20 Sep 2018 15:46:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20180920150550.GA4852@cventin.lip.ens-lyon.fr> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2018-09/txt/msg00064.txt.bz2 On 09/20/2018 11:05 AM, Vincent Lefevre wrote: > Actually, there may be a bug with -m32: > > #include > #include > > int main (void) > { > float f = 2147483646; > printf ("FLT_EVAL_METHOD = %d\n", (int) FLT_EVAL_METHOD); > if (f == 2147483647) > { > printf("%.20g\n", (double) f); > } > return 0; > } > > $ gcc -std=c99 -m32 -O tst.c -o tst > $ ./tst > FLT_EVAL_METHOD = 2 > 2147483648 > > Since FLT_EVAL_METHOD = 2, float_t is long double, thus shouldn't > 2147483647 be converted to long double directly (as f is regarded > as an operand of type long double), so that the result of the > equality test should be false? > > The C standard says for FLT_EVAL_METHOD = 2: "evaluate all operations > and constants to the range and precision of the long double type". > ^^^^^^^^^^^^^ > > Converting f first to float is contrary to the idea behind > FLT_EVAL_METHOD = 2, which is to avoid loss of precision in > intermediate operations. > Hrmmm ... I see FLT_EVAL_METHOD = 0 here with gcc 8.1.0 on sparc : $ file ./flt_eval ./flt_eval: ELF 32-bit MSB executable SPARC32PLUS Version 1, V8+ Required, dynamically linked, not stripped, no debugging information available $ ./flt_eval FLT_EVAL_METHOD = 0 2147483648 I see similar on ppc64 : $ file flt_eval flt_eval: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV), dynamically linked, interpreter /lib/ld.so.1, for GNU/Linux 3.2.0, not stripped $ ./flt_eval FLT_EVAL_METHOD = 0 2147483648 $ Not sure how you are getting FLT_EVAL_METHOD as 2. What platform is this on ? Dennis