From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 97072 invoked by alias); 9 Sep 2015 09:24:14 -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 97058 invoked by uid 89); 9 Sep 2015 09:24:14 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-wi0-f173.google.com Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com) (209.85.212.173) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 09 Sep 2015 09:24:13 +0000 Received: by wiclk2 with SMTP id lk2so149477924wic.0 for ; Wed, 09 Sep 2015 02:24:10 -0700 (PDT) X-Received: by 10.180.93.196 with SMTP id cw4mr55365229wib.54.1441790650133; Wed, 09 Sep 2015 02:24:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.186.214 with HTTP; Wed, 9 Sep 2015 02:23:30 -0700 (PDT) In-Reply-To: References: <55EF53AC.9020306@gmail.com> From: =?UTF-8?B?TWFudWVsIEzDs3Blei1JYsOhw7Fleg==?= Date: Wed, 09 Sep 2015 09:24:00 -0000 Message-ID: Subject: Re: -ffloat-store behavior (Re: Susprising behavior of gcc on x86 (-m32)) To: Mathieu Malaterre Cc: gcc-help , Andrew Haley , Markus Trippelsdorf Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2015-09/txt/msg00045.txt.bz2 On 9 September 2015 at 09:18, Mathieu Malaterre wrote: >> Thanks for the link. However -in my case- the compile option >> `-fexcess-precision=standard` does produce the same code as >> `-ffloat-store`. At least for > > Meant to say `does not produce` The FAQ now says: "(whether this option has effect or not depends on other options, please read the manual entry for -fexcess-precision= carefully)." The manual says: "-fexcess-precision=standard is not implemented for languages other than C, and has no effect if -funsafe-math-optimizations or -ffast-math is specified. On the x86, it also has no effect if -mfpmath=sse or -mfpmath=sse+387 is specified; in the former case, IEEE semantics apply without excess precision, and in the latter, rounding is unpredictable" > >> [...] >> double div; /* OPJ_FLOAT64 */ >> div = dd / dr; >> if (div >= thresh) >> [...] >> >> Is there a longer description for `-fexcess-precision=standard` which >> explains case of failures ? The manual says: "if -fexcess-precision=standard is specified then excess precision follows the rules specified in ISO C99; in particular, both casts and assignments cause values to be rounded to their semantic types (whereas -ffloat-store only affects assignments)." The FAQ says: "Floating-point results may still depend on the optimization level and target architecture in some cases that are allowed by the ISO C standard. For instance, different sets of instructions may be used for code such as x*y+z depending on the target architecture and the optimization level, and this difference may change the results." I don't have a list of cases allowed by the standard. If you know more examples, we could add them to the answer. > From a clean debian/sid 32bits chroot I can no longer reproduce this. > In summary: > > 1. removed -ffast-math > 2. add -std=c99 > 3. Change the code for an explicit storage of division (div = dd / dr) > => issue solved ! The manual says: "This option is enabled by default for C if a strict conformance option such as -std=c99 is used." Thus, you are in fact using -fexcess-precision=standard. That only means that floating-point computations will follow ISO C rules. FAQ: "Floating-point results may still depend on the optimization level and target architecture". Cheers, Manuel.