Can't compile on CentOS 7 #464
Labels
No labels
announcement
bug
build
CI
dependencies
documentation
duplicate
enhancement
experience feedback
feature request
github_actions
help wanted
install
invalid
Long-term
optimization
portability
question
target-specific
test issue
wontfix
No milestone
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
gh-Cyan4973/xxHash#464
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
I'm trying to do best-efforts compilation of 0.8.0 including the X86 dispatch code for use in my database synchronization software.
CentOS 7 has GCC 4.8.5 which doesn't support AVX-512, that is, it doesn't support the
-mavx512fand-mavx512vlflags and gives errors likeerror: attribute(target("avx512f")) is unknown,error: '__m512i' was not declared in this scopeetc. without them.As a result, I can't compile the dispatch code, because it will turn on compilation of all vectorized variants:
#if (XXH_VECTOR == XXH_AVX512) || defined(XXH_X86DISPATCH)We could mix in more of the
__AVX512F__define tests, but I suspect that's going to require compiler-specific stuff to be spread throughout the file. Instead I propose that we refactor this to a set of vectorization support flags (eg.XXH_VECTOR_SUPPORT_AVX512), which can be left unset when the compiler flag tests fail.(I don't use CentOS and I don't really get why people do. But they do, and they sent me bug reports and patches for my open-source software to support it.)
That's a good point @willbryant .
We do have one mechanism for such situation, though it is currently code-driven :
disable the definition of
XXH_DISPATCH_AVX512.This should disable any trace of
AVX512code generation.Try to test if commenting this line solves your problem.
If it does, then we could leverage this mechanism to make this feature selectable at compile time,
and then make the build system able to automatically detect and trigger the feature.
Perhaps we could add a check before defining it?
I am thinking this
Apparently for AVX2, we need GCC 4.7, avx2intrin.h, or VS 2013 Update 2.
@willbryant Can you test my
dispatch-fixesbranch?No different at first:
But what compiler options and defines are you expecting to be passed?
Here's a minimal Dockerfile extracted from my test build for Centos 7:
Not sure if you would expect those options (noting the absence of -mavx512* options), no options at all, or something more like -march=native, but I think all three fail the same way right now.
I see the issue now.
While I successfully disabled generating the dispatch table, I need to also disable the code path on xxhash.h.
Side note, you are supposed to compile xxh_x86dispatch.c with the minimum target options. I should add a sanity check in that file as it seems to be a common misconception.
@willbryant Try now. It should also error if you use
-mavx*, as that defeats the purpose of the dispatching altogether.Just do
gcc -O2 -c xxh_x86dispatch.c, macro magic will handle the rest. 😉Cool, no options is what I tried first, but good to prevent it altogether.
Compilation now failing with:
Oh, I see... Damn this is dumb.
So before GCC 4.9 (specifically this commit), GCC required
__AVX__,__SSE2__, etc to include the SSE headers.That makes it impossible to implement this in a single file without some incredibly ugly hacks that mess with the internals.
Right, messy.
FWIW before seeing how you were able to implement most of the detection in the header files, my expectation was that I would need to compile both xxhash.c and xxh_x86dispatch.c, the former with all of the supported flags on (ie.
-msse2 -msse4.1 -mavx2on this distro,-msse2 -msse4.1 -mavx2 -mavx512f -mavx512vland maybe-mavx512bwon others), the latter with no flags.I expected xxh_x86dispatch to need to be told which variants to try and link against/dispatch to, which I would know because my build system would have had to figure out which flags to use.
For example, in BLAKE3 I set defines like
BLAKE3_NO_AVX512to turn off dispatch to the AVX-512 variant if that variant isn't compilable/linkable.Hmm. Found a CentOS machine on the compiler farm with GCC 4.8.5 (yay no recompile).
My two filthy, ugly, evil hack ideas all resulted in
inlining failed in call to always_inline ‘...': target specific option mismatchI don't know what's going to be harder, trying to get this to work or getting CentOS to update GCC.
Also, Clang 3.4 does not work; it lacks
__attribute__((__target__)).Requiring GCC to be 4.9 and Clang to be 3.8 will fix this, but it is not something I want...
Welp, this looks like the most accurate check I can find. 🤢