Open cgohlke opened 7 months ago
@cgohlke Thanks for reporting this issue. Although I don't expect any difference, do earlier versions of zfp pass with 14.38.33130?
It's possible that the data model is not detected properly, even though both compilers report LLP64. Can you please build with
-DZFP_INT64="long long" -DZFP_INT64_SUFFIX=ll -DZFP_UINT64="unsigned long long" -DZFP_UINT64_SUFFIX=ull
and see if that fixes the issue?
do earlier versions of zfp pass with 14.38.33130
No, but I only tried with 1.0.0 and 1.0.1 git tags so far.
see if that fixes the issue?
No, unfortunately not.
zfp-0.5.5 passes with 14.38.33130
zfp version 0.5.5 (May 5, 2019)
library version 85
CODEC version 5
data model LLP64
testing 1D array of floats
compress: rate= 2 OK
decompress: rate= 2 1.626e+01 <= 1.627e+01 OK
compress: rate= 8 OK
decompress: rate= 8 8.276e-02 <= 8.277e-02 OK
compress: rate=32 OK
decompress: rate=32 0.000e+00 <= 0.000e+00 OK
compress: precision= 4 ratio= 7.474 OK
decompress: precision= 4 OK
compress: precision= 8 ratio= 4.995 OK
decompress: precision= 8 OK
compress: precision=16 ratio= 2.589 OK
decompress: precision=16 OK
compress: tolerance=9.766e-04 ratio= 2.589 OK
decompress: tolerance=9.766e-04 3.662e-04 <= 9.766e-04 OK
compress: tolerance=2.384e-07 ratio= 1.372 OK
decompress: tolerance=2.384e-07 0.000e+00 <= 2.384e-07 OK
compress: tolerance=0.000e+00 ratio= 1.194 OK
decompress: tolerance=0.000e+00 0.000e+00 <= 0.000e+00 OK
compress: reversible ratio= 2.253 OK
decompress: reversible OK
construct: 4.578e-05 <= 4.578e-05 OK
update: 2.155e-02 ~ 2.155e-02 OK
testing 1D array of doubles
compress: rate= 3 OK
decompress: rate= 3 1.626e+01 <= 1.627e+01 OK
compress: rate= 4 OK
decompress: rate= 4 1.600e+01 <= 1.601e+01 OK
compress: rate=16 OK
decompress: rate=16 1.831e-04 <= 1.832e-04 OK
compress: rate=64 OK
decompress: rate=64 0.000e+00 <= 0.000e+00 OK
compress: precision= 8 ratio= 8.943 OK
decompress: precision= 8 OK
compress: precision=16 ratio= 4.882 OK
decompress: precision=16 OK
compress: precision=32 ratio= 2.323 OK
decompress: precision=32 OK
compress: tolerance=9.766e-04 ratio= 4.882 OK
decompress: tolerance=9.766e-04 3.662e-04 <= 9.766e-04 OK
compress: tolerance=4.441e-16 ratio= 1.266 OK
decompress: tolerance=4.441e-16 0.000e+00 <= 4.441e-16 OK
compress: tolerance=0.000e+00 ratio= 1.127 OK
decompress: tolerance=0.000e+00 0.000e+00 <= 0.000e+00 OK
compress: reversible ratio= 4.210 OK
decompress: reversible OK
construct: 1.831e-04 <= 1.832e-04 OK
update: 2.155e-02 ~ 2.155e-02 OK
testing 2D array of floats
compress: rate= 2 OK
decompress: rate= 2 1.500e+00 <= 1.500e+00 OK
compress: rate= 8 OK
decompress: rate= 8 3.662e-03 <= 3.663e-03 OK
compress: rate=32 OK
decompress: rate=32 0.000e+00 <= 0.000e+00 OK
compress: precision= 4 ratio= 27.676 OK
decompress: precision= 4 OK
compress: precision= 8 ratio= 12.337 OK
decompress: precision= 8 OK
compress: precision=16 ratio= 3.737 OK
decompress: precision=16 OK
compress: tolerance=9.766e-04 ratio= 3.319 OK
decompress: tolerance=9.766e-04 3.395e-04 <= 9.766e-04 OK
compress: tolerance=2.384e-07 ratio= 1.481 OK
decompress: tolerance=2.384e-07 0.000e+00 <= 2.384e-07 OK
compress: tolerance=0.000e+00 ratio= 1.309 OK
decompress: tolerance=0.000e+00 0.000e+00 <= 0.000e+00 OK
compress: reversible ratio= 3.210 OK
decompress: reversible OK
construct: 7.629e-06 <= 7.630e-06 OK
update: 3.755e-01 ~ 3.755e-01 OK
testing 2D array of doubles
compress: rate= 1 OK
decompress: rate= 1 2.376e+01 <= 2.376e+01 OK
compress: rate= 4 OK
decompress: rate= 4 1.797e-01 <= 1.797e-01 OK
compress: rate=16 OK
decompress: rate=16 8.583e-06 <= 8.584e-06 OK
compress: rate=64 OK
decompress: rate=64 0.000e+00 <= 0.000e+00 OK
compress: precision= 8 ratio= 23.011 OK
decompress: precision= 8 OK
compress: precision=16 ratio= 7.314 OK
decompress: precision=16 OK
compress: precision=32 ratio= 2.597 OK
decompress: precision=32 OK
compress: tolerance=9.766e-04 ratio= 6.512 OK
decompress: tolerance=9.766e-04 3.395e-04 <= 9.766e-04 OK
compress: tolerance=4.441e-16 ratio= 1.260 OK
decompress: tolerance=4.441e-16 0.000e+00 <= 4.441e-16 OK
compress: tolerance=0.000e+00 ratio= 1.131 OK
decompress: tolerance=0.000e+00 0.000e+00 <= 0.000e+00 OK
compress: reversible ratio= 6.263 OK
decompress: reversible OK
construct: 8.583e-06 <= 8.584e-06 OK
update: 3.756e-01 ~ 3.755e-01 OK
testing 3D array of floats
compress: rate= 2 OK
decompress: rate= 2 1.500e+00 <= 1.500e+00 OK
compress: rate= 8 OK
decompress: rate= 8 9.583e-03 <= 9.583e-03 OK
compress: rate=32 OK
decompress: rate=32 0.000e+00 <= 0.000e+00 OK
compress: precision= 4 ratio=107.789 OK
decompress: precision= 4 OK
compress: precision= 8 ratio= 15.754 OK
decompress: precision= 8 OK
compress: precision=16 ratio= 3.562 OK
decompress: precision=16 OK
compress: tolerance=9.766e-04 ratio= 2.684 OK
decompress: tolerance=9.766e-04 2.203e-04 <= 9.766e-04 OK
compress: tolerance=2.384e-07 ratio= 1.394 OK
decompress: tolerance=2.384e-07 0.000e+00 <= 2.384e-07 OK
compress: tolerance=0.000e+00 ratio= 1.282 OK
decompress: tolerance=0.000e+00 0.000e+00 <= 0.000e+00 OK
compress: reversible ratio= 2.688 OK
decompress: reversible OK
construct: 3.147e-05 <= 3.148e-05 OK
update: 1.846e+00 ~ 1.846e+00 OK
testing 3D array of doubles
compress: rate= 1 OK
decompress: rate= 1 5.210e+00 <= 5.210e+00 OK
compress: rate= 4 OK
decompress: rate= 4 2.002e-01 <= 2.002e-01 OK
compress: rate=16 OK
decompress: rate=16 3.338e-05 <= 3.338e-05 OK
compress: rate=64 OK
decompress: rate=64 0.000e+00 <= 0.000e+00 OK
compress: precision= 8 ratio= 30.797 OK
decompress: precision= 8 OK
compress: precision=16 ratio= 7.087 OK
decompress: precision=16 OK
compress: precision=32 ratio= 2.558 OK
decompress: precision=32 OK
compress: tolerance=9.766e-04 ratio= 5.347 OK
decompress: tolerance=9.766e-04 2.201e-04 <= 9.766e-04 OK
compress: tolerance=4.441e-16 ratio= 1.208 OK
decompress: tolerance=4.441e-16 0.000e+00 <= 4.441e-16 OK
compress: tolerance=0.000e+00 ratio= 1.122 OK
decompress: tolerance=0.000e+00 0.000e+00 <= 0.000e+00 OK
compress: reversible ratio= 5.347 OK
decompress: reversible OK
construct: 3.338e-05 <= 3.338e-05 OK
update: 1.846e+00 ~ 1.846e+00 OK
testing 4D array of floats
compress: rate= 2 OK
decompress: rate= 2 1.372e+01 <= 1.373e+01 OK
compress: rate= 8 OK
decompress: rate= 8 6.632e-01 <= 6.633e-01 OK
compress: rate=32 OK
decompress: rate=32 0.000e+00 <= 0.000e+00 OK
compress: precision= 4 ratio=256.000 OK
decompress: precision= 4 OK
compress: precision= 8 ratio= 9.309 OK
decompress: precision= 8 OK
compress: precision=16 ratio= 2.798 OK
decompress: precision=16 OK
compress: tolerance=9.766e-04 ratio= 1.736 OK
decompress: tolerance=9.766e-04 1.359e-04 <= 9.766e-04 OK
compress: tolerance=2.384e-07 ratio= 1.166 OK
decompress: tolerance=2.384e-07 0.000e+00 <= 2.384e-07 OK
compress: tolerance=0.000e+00 ratio= 1.166 OK
decompress: tolerance=0.000e+00 0.000e+00 <= 0.000e+00 OK
compress: reversible ratio= 2.387 OK
decompress: reversible OK
testing 4D array of doubles
compress: rate= 1 OK
decompress: rate= 1 1.016e+01 <= 1.016e+01 OK
compress: rate= 4 OK
decompress: rate= 4 8.984e+00 <= 8.985e+00 OK
compress: rate=16 OK
decompress: rate=16 3.312e-03 <= 3.312e-03 OK
compress: rate=64 OK
decompress: rate=64 0.000e+00 <= 0.000e+00 OK
compress: precision= 8 ratio= 18.534 OK
decompress: precision= 8 OK
compress: precision=16 ratio= 5.588 OK
decompress: precision=16 OK
compress: precision=32 ratio= 2.331 OK
decompress: precision=32 OK
compress: tolerance=9.766e-04 ratio= 3.468 OK
decompress: tolerance=9.766e-04 1.360e-04 <= 9.766e-04 OK
compress: tolerance=4.441e-16 ratio= 1.076 OK
decompress: tolerance=4.441e-16 0.000e+00 <= 4.441e-16 OK
compress: tolerance=0.000e+00 ratio= 1.076 OK
decompress: tolerance=0.000e+00 0.000e+00 <= 0.000e+00 OK
compress: reversible ratio= 4.768 OK
decompress: reversible OK
all tests passed
As a workaround, compile with the /Ob1
instead of the default /Ob2
compiler switch, for example using -DCMAKE_C_FLAGS_RELEASE:STRING=/MD /O2 /Ob1 /DNDEBUG
for release builds.
/Ob1
"allows expansion only of functions marked inline
, __inline
, or __forceinline
, or in a C++ member function defined in a class declaration", while /Ob2
"allows the compiler to expand any function not explicitly marked for no inlining" (https://learn.microsoft.com/en-us/cpp/build/reference/ob-inline-function-expansion?view=msvc-170).
Thanks for the suggestion. I doubt that we have access to the same compiler/OS/hardware setup, so debugging this from our end will be challenging. AppVeyor supports Visual Studio Community 2022 version 17.5.0. We can take a look and see if the issue can be reproduced with that compiler, though it seems unlikely as the issue seems confined to one particular compiler version and system.
By the way, zfp 1.0.x is not ABI compatible with 0.5.y. I assume you've rebuilt any binaries that depend on zfp.
Yes, it could be a compiler bug introduced by the latest VS update. This issue is meant as a "heads-up" in case someone else runs into it. The workaround, to build with /Ob1
, is good enough for now. I think the issue can be closed (?)
By the way, zfp 1.0.x is not ABI compatible with 0.5.y. I assume you've rebuilt any binaries that depend on zfp.
Sure, I was just rebuilding 0.5.5 temporarily for testing this issue.
Thanks for the heads-up. I ran into the same issue with Visual Studio 2022 17.9.5. The "/Ob1" workaround fixed the issue. Is there any progress? Would it help to identify the exact compiler version for which the problem appeared? Would it help to build some source files with "/Ob1" and others with "/Ob2" to identify the files with issues?
@VReichelt Are you observing this on AMD64 only? We do not have access to that combination of hardware, OS, and compiler to debug what is going wrong, so I'm unsure how to proceed. I also suspect that every object file would change when switching /Ob1
to /Ob2
, so I'm not sure that's really helpful. But it may be instructive to see the impact of removing the inline
keyword here:
I only have AMD64 available on WIndows. (I don't have any issues on Linux with various GCC versions.)
I haven't tried your suggestion yet, but I tried different Visual Studio versions in the meantime. With the latest 17.6.x version (17.6.15) everything is OK. With the latest 17.8, 17.9, 17.10 versions (17.8.10, 17.9.5, 17.10.1) the problem is there. I couldn't test 17.7 anymore, because that's not an LTS version.
I'll try your suggestion and fiddle around with inlining in a couple of weeks.
Another workaround is to build ZFP with LLVM clang compiler. Set these environment variables before running cmake:
set CC=clang-cl
set CXX=clang-cl
Same issue when building ZFP as part of hdf5plugin with Visual Studio 2022 17.10.3 (MSVC/14.40.33807): /Ob1
fixes the issue as well.
Heads-up: this may not be an issue with the ZFP source code, but I get many test failures when compiling zfp 1.0.1 from source with the current/latest Visual Studio 2022 compiler version 14.38.33130 on Windows 11. This is for the AMD64-bit build (32-bit and ARM64 pass):
CMake output
Reverting to the previous compiler version 14.37.32822 fixes the issue:
Most ZFP related tests in imagecodecs also fail or segfault when linked with zfp.lib compiled with the 14.38.33130 compiler.