This bug has the double intention to catch rawtherapee users which experience the problem and to alert @toolchain of a subtle gcc miscompilation. Previous version of gcc are unaffected (it is a regression) The issue is well described in: https://github.com/Beep6581/RawTherapee/issues/5749 possibly related to gc bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93334 basically an initialization loop over two matrices produce wrong results when "-ftree-loop-vectorize" is used (which rawtherapee add by default)
(In reply to Francesco Riosa from comment #0) > This bug has the double intention to catch rawtherapee users which > experience the problem and to alert @toolchain of a subtle gcc > miscompilation. > Previous version of gcc are unaffected (it is a regression) [ i'll reoreder a bit ] > possibly related to gc bug: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93334 This bug is tagged 'missed-optimization'. Is there a bug about wrong code? > basically an initialization loop over two matrices produce wrong results > when "-ftree-loop-vectorize" is used (which rawtherapee add by default) > The issue is well described in: > https://github.com/Beep6581/RawTherapee/issues/5749 I did not find the instructions to reproduce. I'm not familiar with this package. Is there a sample C code with compiler flags I could run to see the difference between working and non-working code? Or at lease commandline run on a known static input to see the difference?
(In reply to Sergei Trofimovich from comment #1) > (In reply to Francesco Riosa from comment #0) > > This bug has the double intention to catch rawtherapee users which > > experience the problem and to alert @toolchain of a subtle gcc > > miscompilation. > > Previous version of gcc are unaffected (it is a regression) > > [ i'll reoreder a bit ] > > > possibly related to gc bug: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93334 > > This bug is tagged 'missed-optimization'. Is there a bug about wrong code? Not that I can find, nor one that I can open in confidence most analysis work has been done from others > > > basically an initialization loop over two matrices produce wrong results > > when "-ftree-loop-vectorize" is used (which rawtherapee add by default) > > > The issue is well described in: > > https://github.com/Beep6581/RawTherapee/issues/5749 > > I did not find the instructions to reproduce. I'm not familiar with this > package. > > Is there a sample C code with compiler flags I could run to see the > difference between working and non-working code? Or at lease commandline run > on a known static input to see the difference? No sample C code but a snippet has been extracted by rawtherapee upstream dev. https://github.com/Beep6581/RawTherapee/issues/5749#issuecomment-639467551 Snippet came from this file: https://github.com/Beep6581/RawTherapee/blob/421f86892170078efc8ceb45e74e0e38e12fe019/rtengine/rawimagesource.cc#L1138 Comment on github reported here for commodity: If I change for (int i = 0; i < 3; i++) for (int j = 0; j < 3; j++) for (int k = 0; k < 3; k++) { imatrices.xyz_cam[i][j] += xyz_sRGB[i][k] * imatrices.rgb_cam[k][j]; } to for (int k = 0; k < 3; k++) for (int i = 0; i < 3; i++) for (int j = 0; j < 3; j++) { imatrices.xyz_cam[i][j] += xyz_sRGB[i][k] * imatrices.rgb_cam[k][j]; } which should do exactly the same, it works fine^W^W^W. Edit: I just detected that it works fine for some files, but not for all...
I'm afraid I need an executable example to make the bug actionable.
I picked the image from upstream bug report, built media-gfx/rawtherapee with -O3 -ftree-vectorize, clicked something to get neutral profile (prrobably incorrect) and converted an image as: $ rawtherapee-cli -o a.png -a -p 2600-1448-max.png.pp3 -Y -n -c 2600-1448-max.png I see no color artifacts. Maybe because ebuild already filters out -O3? src_configure() { # upstream tested that "fast-math" give wrong results, so filter it # https://bugs.gentoo.org/show_bug.cgi?id=606896#c2 filter-flags -ffast-math # -Ofast enable "fast-math" both in gcc and clang replace-flags -Ofast -O3
Please reopen if you have a reproducer.
for the record gcc 10.2 is fixed
My understanding is that there is no evidence it was explicitly fixed or even reported to gcc upstream. If you have it please provide it. Otherwise real error (in gcc or client code) can well be masked by generated code changes of gcc and will resurface again.
(In reply to Sergei Trofimovich (RETIRED) from comment #7) > My understanding is that there is no evidence it was explicitly fixed or > even reported to gcc upstream. If you have it please provide it. > > Otherwise real error (in gcc or client code) can well be masked by generated > code changes of gcc and will resurface again. In the linked gh issue, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96133 is mentioned.
