Re: Susprising behavior of gcc on x86 (-m32)

[Jonathan Wakely <jwakely dot gcc at gmail dot com>]

On 8 September 2015 at 10:57, Mathieu Malaterre <malat@debian.org> wrote:
> On Tue, Sep 8, 2015 at 11:45 AM, Andrew Haley <aph@redhat.com> 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.

That was my first thought too. To rule it out you could compile with
-mfpmath=sse


> Technically this code path is *not* using floating point at all (by
> JPEG 2000 reversible kernel design). integer based shift&additions
> operations only.

Then I suggest compiling with -fsanitize=undefined to see if there are
any undefined shifts.

You could try that with both GCC and Clang, they both support UBsan
with slightly different feature sets.

>> 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.

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.