Giters

ebiggers / libdeflate

Heavily optimized library for DEFLATE/zlib/gzip compression and decompression

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Tests fail on Windows in Release mode with VS platform toolset v141

frank-aurich opened this issue · comments

commented

Hi,

I'm compiling libdeflate on Windows 10 (Build 19045.3208) using Visual Studio 2022 Professional, v17.6.4.
The CPU is an Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz.

When using the platform toolset {{"v141"}}, which is the compiler used in Visual Studio 2017, two of the unittests fail when compiling as "Release or "RelWithDebInfo", but not when compiling in "Debug" mode:

D:\devel\libdeflate-org> cmake -S . -B b_141 -T v141 -DCMAKE_VS_PLATFORM_TOOLSET=v141 -DCMAKE_PREFIX_PATH=C:\Entwicklung\zlib-1.2.13 -DLIBDEFLATE_BUILD_TESTS=1
D:\devel\libdeflate-org> cmake --build b_141 --config Release
D:\devel\libdeflate-org> cd b_141\programs
D:\devel\libdeflate-org> ctest -C Release

Produces this output:

6/7 Test #3: test_incomplete_codes ............Exit code 0xc0000409
***Exception:   0.13 sec
test_incomplete_codes.exe: Assertion failed: res == LIBDEFLATE_SUCCESS at D:\devel\libdeflate-org\programs\test_incomplete_codes.c:26

7/7 Test #7: test_trailing_bytes ..............Exit code 0xc0000409
***Exception:   0.14 sec
test_trailing_bytes.exe: Assertion failed: res == LIBDEFLATE_SUCCESS at D:\devel\libdeflate-org\programs\test_trailing_bytes.c:104

Notes:

  • Debugging shows that library uses deflate_decompress_bmi2() for decompressing the data.
    If I manually set HAVE_BMI2_INTRIN=0, the issue does not occur
  • I cannot say if this also happens when using Visual Studio 2017 directly.
  • I tested with the master branch, as well as release v1.15 of the library (I didn't go back any further due to a lack of a CMakeLists.txt)
  • When using the default platform toolset for Visual Studio 2022, which is "v143" (or by simply omitting the -T flag from the cmake command), all tests run successfully in both "Release" and "Debug" mode
commented

I think this is probably a MSVC compiler bug with the bzhi intrinsics.

Further investigation is not really possible, as MSVC is closed source.

#326 will disable the bzhi intrinsics on MSVC versions before VS2022 (tools v143).