From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 40198 invoked by alias); 8 Sep 2015 09:57:35 -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 40187 invoked by uid 89); 8 Sep 2015 09:57:35 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_05,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-yk0-f180.google.com Received: from mail-yk0-f180.google.com (HELO mail-yk0-f180.google.com) (209.85.160.180) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 08 Sep 2015 09:57:33 +0000 Received: by ykdu9 with SMTP id u9so34685193ykd.2 for ; Tue, 08 Sep 2015 02:57:31 -0700 (PDT) X-Received: by 10.129.52.10 with SMTP id b10mr25447429ywa.58.1441706251077; Tue, 08 Sep 2015 02:57:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.231.7 with HTTP; Tue, 8 Sep 2015 02:57:11 -0700 (PDT) In-Reply-To: <55EEAE4A.40307@redhat.com> References: <55EEAE4A.40307@redhat.com> From: Mathieu Malaterre Date: Tue, 08 Sep 2015 09:57:00 -0000 Message-ID: Subject: Re: Susprising behavior of gcc on x86 (-m32) To: Andrew Haley Cc: gcc-help@gcc.gnu.org Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-09/txt/msg00023.txt.bz2 On Tue, Sep 8, 2015 at 11:45 AM, Andrew Haley wrote: > On 09/08/2015 10:15 AM, Mathieu Malaterre wrote: >> What is even more surprising is that I can no longer reproduce the >> behavior using `valgrind` from my 32bits chroot. >> >> I understand that my bug description is relatively small, but I am >> eager to report a more specific gcc issue. If anyone could help me >> narrow down this issue, I'd appreciate your comments. >> >> Please note that that I disabled any kind of optimizations by using >> (explicitly!) -O0. > > I'm guessing that it's some silliness with the FPU, but that's a wild > guess. Technically this code path is *not* using floating point at all (by JPEG 2000 reversible kernel design). integer based shift&additions operations only. > You first need to find out what part of the file is different, and > narrow it down from there. One question: how well do you understand > the OpenJPEG code base? Let me answer it this way: this is a huge task -for me- to narrow down this issue to a minimal C code.