Test fails to pass when building with GCC 15

[dbermond]

When using GCC 15, it builds fine but the tests fails to pass.

Tests output: https://pastebin.com/XU5nRrTf

When building with GCC 14, the tests passes fine.

Commands used:

$ cmake -B build -S OpenJPH-0.21.3 \
        -G 'Unix Makefiles' \
        -DCMAKE_BUILD_TYPE:STRING='None' \
        -DCMAKE_INSTALL_PREFIX:PATH='/usr' \
        -DOJPH_DISABLE_SSSE3:BOOL='ON' \
        -DOJPH_DISABLE_SSE4:BOOL='ON' \
        -DOJPH_DISABLE_AVX:BOOL='ON' \
        -DOJPH_DISABLE_AVX2:BOOL='ON' \
        -DOJPH_DISABLE_AVX512:BOOL='ON' \
        -DOJPH_BUILD_TESTS:BOOL='ON' \
        -Wno-dev
$ cmake --build build
$ ctest --test-dir build --output-on-failure

System Information:

• OS: Arch Linux
• CMake: 4.0.2
• Compiler: gcc 15.1.1
• libtiff: 4.7.0

[aous72]

Hi Daniel,

Thank you for putting this in.

Are you able to supply any extra environment variables -- not sure what to call them.
In particular, was -flto used?

Kind regards,
Aous.

[dbermond]

Thank you for the reply.

Yes, LTO is being used. And disabling it with GCC 15 does not make any difference in the test failures.

I could track it as being due to the compiler optimization flag. The failures happens when using -O2, -O3, -Ofast and -Os. The problem does not happen with -O1 and -O0.

Not sure if this is a compiler bug or something that should be fixed here.

[aous72]

Hi @dbermond

I was unable to re-create your results, but I got these failures, when using gcc 15.1.1, and also on Ubuntu 25.04 using gcc 15.0.1, -O3.

          9 - TestExecutables.SimpleDecIrv97512x8 (Failed)
         10 - TestExecutables.SimpleDecIrv978x512 (Failed)
         11 - TestExecutables.SimpleDecIrv97256x16 (Failed)
         12 - TestExecutables.SimpleDecIrv9716x256 (Failed)
         13 - TestExecutables.SimpleDecIrv97128x32 (Failed)
         40 - TestExecutables.SimpleDecIrv9764x64GrayTiles (Failed)
         41 - TestExecutables.SimpleDecIrv9764x6416bit (Failed)
         45 - TestExecutables.SimpleDecIrv53BhvhbLowLatency (Failed)

Notice these are all in the irreversible path -- errors are expected but now the error margin with gcc 15 is larger than it used to be (with gcc 14).
It is worth noting that the error margins are fine AVX2.

Do you know if gcc 15 changed floating-point rounding behaviour, or floating-point behaviour in general, compared to gcc 14?

Kind regards,
Aous.

PS: It might be some undefined behaviour that is breaking now. In any case, I need to get to the bottom of this.

[dbermond]

I could not find any documentation about significant changes in x86_64 floating point operations in gcc 15.

[aous72]

Hi Daniel,

Please let me know if you disagree with any of these statements.
I suspect this is a bug in the compiler -- it is weird, or the problem is somewhere else that I did not discover.
I think the problem is occurring because the line

ui16 prev_row_sig[256 + 8] = {0};

does not clear the array in

OpenJPH/src/core/coding/ojph_block_decoder32.cpp

Line 1369 in eb1774a

ui16 prev_row_sig[256 + 8] = {0}; // 528 Bytes

and

OpenJPH/src/core/coding/ojph_block_decoder_ssse3.cpp

Line 1756 in eb1774a

ui16 prev_row_sig[256 + 8] = {0}; // 528 Bytes

but works correctly in

OpenJPH/src/core/coding/ojph_block_decoder_avx2.cpp

Line 1730 in eb1774a

ui16 prev_row_sig[256 + 8] = {0}; // 528 Bytes

Not clearing the array affects the Significance Propagation Pass (SPP), which usually exists in lossy compression only. Changes in SPP changes the reconstructed value by a small amount leading to increased error margin.

I have modified the code to do array clearing in the code in the just pushed branch issue_186.
If you have the time, please see if this solves the problem; if it does, I will push it as version 0.21.4.

Thank you.

Kind regards,
Aous

[dbermond]

Thank you for investigating this.

After applying commit 62450e6 on top of version 0.21.3, the tests still fails to pass.

The errors are in the same line (value differency), but now more tests passes, and fewer tests fails. Now only 7 tests fails to pass, instead of 33 in the initial report. And if I compile using my machine/cpu in the -march flag, 8 tests fails. Summary result:

90% tests passed, 8 tests failed out of 82

Total Test time (real) =  12.07 sec

The following tests FAILED:
          4 - TestExecutables.SimpleDecIrv9732x32 (Failed)
          5 - TestExecutables.SimpleDecIrv9716x16 (Failed)
         11 - TestExecutables.SimpleDecIrv97256x16 (Failed)
         12 - TestExecutables.SimpleDecIrv9716x256 (Failed)
         13 - TestExecutables.SimpleDecIrv97128x32 (Failed)
         14 - TestExecutables.SimpleDecIrv9732x128 (Failed)
         41 - TestExecutables.SimpleDecIrv9764x6416bit (Failed)
         45 - TestExecutables.SimpleDecIrv53BhvhbLowLatency (Failed)
Errors while running CTest

[aous72]

Hi Daniel,

Thank you for testing the code.
I need to ask you for another favour to test new commit.
The new commit is functionally equivalent to the code on the master branch.
If the tests pass successfully, then it is more likely a compiler issue.

Thank you again.

Kind regards,
Aous.

[dbermond]

Applying both commits of branch issue_186 fixes the error with gcc 15.

All tests passes fine with gcc 15 using the Arch Linux standard compiler flags (which uses -O2), and also when adding my machine/cpu in the -march flag. Also tested other combinations, like without any flags, with just -O2 and with just -O3, and these worked fine.

I could find another similar floating point issue with gcc 15 in another software, and maybe this can be of interest: mixxxdj/mixxx#14716

[aous72]

Thank you Daniel for running all these tests. This was useful for my sanity.

I misspoke earlier regarding floating-point; the problem is NOT with floating point implementation.

The problem is that the line

 ui16 prev_row_sig[256 + 8] = {0};

and similar lines (all in ojph_block_decoder32.cpp) do not generate correct code (or maybe optimized away); it is hard to check the -O3 optimized assembly code.
This leaves many entries in the array uninitialized to 0.

This line, in my understanding, should set to first entry to the value provided, which 0, and then all other entries to 0 regardless of the provided value.

Similar lines exist in other files, but they do not seem to cause problems.

Replacing that line with

 ui16 prev_row_sig[256 + 8];
 memset(prev_row_sig, 0, sizeof(prev_row_sig));

which is functionally similar to the above, fixes the issues. This was done in ojph_block_decoder32.cpp and ojph_block_decoder64.cpp only.

I am not sure what is the best coarse of action.
Have a new release of OpenJPH, or wait for gcc 15.2, which hopefully fixes the issue.

Thank you again.

Kind regards,
Aous.

[dbermond]

Thank you for the detailed explanation. Now it's totally clear what is happening.

Since this is tracked to be a compiler bug, fell free to close this issue.