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

[Andrew Haley <aph at redhat dot com>]

On 09/08/2015 01:40 PM, Mathieu Malaterre wrote:
> On Tue, Sep 8, 2015 at 2:00 PM, Mathieu Malaterre <malat@debian.org> wrote:
>> FYI,
>>
>> On Tue, Sep 8, 2015 at 12:04 PM, Jonathan Wakely <jwakely.gcc@gmail.com> 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.  :-)

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.

Andrew.