Eugene Kliuchnikov
Eugene Kliuchnikov
Rolling back HWY version helps. @jan-wassenberg any ideas how to pinpoint the problem? Going to play with compiler version first.
According to clang instructions, something bad is in frontend ('-emit-llvm -Xclang -disable-llvm-passes' does not fix the build)
Running a standalone command does not hang. Perhaps it is ninja problem.
It is LLVM middle-end optimizations bug. ``` /usr/local/bin/clang++ -emit-llvm -Xclang -disable-llvm-passes -DJPEGXL_MAJOR_VERSION=0 -DJPEGXL_MINOR_VERSION=7 -DJPEGXL_PATCH_VERSION=0 -DJXL_ENABLE_FUZZERS -DJXL_INTERNAL_LIBRARY_BUILD '-D__DATE__="redacted"' '-D__TIMESTAMP__="redacted"' '-D__TIME__="redacted"' -I/src/libjxl -I/src/libjxl/lib/include -I/src/libjxl/third_party/highway -I/src/libjxl/third_party/brotli/c/include -I/work/libjxl-corpus/out/lib/include -funwind-tables -Xclang -mrelax-all -Xclang -mconstructor-aliases -fno-omit-frame-pointer...
This first "bad" commit in Highway is `4cc4806 Update SSSE3 target for 32-bit support; new f64->i64 conversion`
The latest HWY release before this commit is 0.12.2. Looking into what might make compiler unhappy.
Disabling SSSE3 support (e.g. passing `-DCMAKE_CXX_FLAGS=-DHWY_DISABLED_TARGETS=HWY_SSSE3` to cmake) fixes the problem. Going to use that as a workaround until problem in HWY/Clang is fixed.
See https://github.com/google/oss-fuzz/pull/6837 Not closing this issue, until the root problem is fixed (and workaround is unrolled)
Sure, but fist have to minimise the case...
Do we need to mention this in changelog? It is not a binary API, still an important change