From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 116600 invoked by alias); 8 Sep 2015 20:00:30 -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 116579 invoked by uid 89); 8 Sep 2015 20:00:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-yk0-f176.google.com Received: from mail-yk0-f176.google.com (HELO mail-yk0-f176.google.com) (209.85.160.176) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 08 Sep 2015 20:00:25 +0000 Received: by ykdu9 with SMTP id u9so61301273ykd.2 for ; Tue, 08 Sep 2015 13:00:23 -0700 (PDT) X-Received: by 10.129.52.10 with SMTP id b10mr30027856ywa.58.1441742423297; Tue, 08 Sep 2015 13:00:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.231.7 with HTTP; Tue, 8 Sep 2015 13:00:03 -0700 (PDT) From: Mathieu Malaterre Date: Tue, 08 Sep 2015 20:00:00 -0000 Message-ID: Subject: -ffloat-store behavior (Re: Susprising behavior of gcc on x86 (-m32)) To: gcc-help@gcc.gnu.org Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-09/txt/msg00035.txt.bz2 Andrew, On Tue, Sep 8, 2015 at 3:22 PM, Andrew Haley wrote: > On 09/08/2015 01:40 PM, Mathieu Malaterre wrote: >> On Tue, Sep 8, 2015 at 2:00 PM, Mathieu Malaterre wrote: >>> FYI, >>> >>> On Tue, Sep 8, 2015 at 12:04 PM, Jonathan Wakely wrote: >>> [...] >>>> That's not the only option. You could compile one file with GCC and >>>> all others with Clang and see if you can reproduce it. Repeat for each >>>> file, which will narrow down the file where the problem occurs. Then >>>> you can try splitting that file into smaller pieces, with one function >>>> per file, and repeat the process. That would tell you which function >>>> or functions get miscompiled by GCC. >>> >>> Ok so if I compile eveything with gcc and then only `tcd.c` using >>> clang, then everything works as expected (no symptoms). >>> ref: https://github.com/uclouvain/openjpeg/blob/master/src/lib/openjp2/tcd.c >>> >>> I'll repeat your approach to find the culprit function. >> >> And the culprit function is `opj_tcd_makelayer`: >> >> https://github.com/uclouvain/openjpeg/blob/master/src/lib/openjp2/tcd.c#L218 >> >> Other than the `if (dd / dr >= thresh)` I do not see anything >> obviously suspicious. > > I see floating point, despite your earlier denial. :-) lol. Sorry about that :( > Libopenjpeg has a bad reputation for messing with the floating- > point state. Please make sure the library is not linked with > -ffast-math. > > Beyond that, a few printf()s and "diff" should find the problem. So here what seems to be working for me, replace: if (dd / dr >= thresh) with: double div; /* OPJ_FLOAT64 */ div = dd / dr; if (div >= thresh) However reading the documentation of gcc: https://gcc.gnu.org/onlinedocs/gcc-5.2.0/gcc/Optimize-Options.html#index-ffloat-store-1074 It appears that -ffloat-store is not activated by default (I did check that using also the output of `gcc -Q -v`). So could someone please let me know why `gcc -m32` (no other option!) produce different behavior (=removes excess precision if my understanding is correct) in the two above cases ? Thanks much again for help,