I would like to submit this patch to xz to support the Intel compiler (see 

A new version of the Intel compiler (not yet released) requires that 
_bit_scan_reverse be used via #include <immintrin.h> ; this is because it will 
be implemented via an inline assembler call. If you use the intrinsic without 
the #include then at link time there is an undefined symbol [c code], or if in 
c++ code, there is a compilation error due to undefined name. (In a new version 
of the Intel compiler, the "intrinsic" name will no longer be known by the 
compiler.)  This problem is seen, for example, in our experimental builds of 
"cmake" and also "kokkos"

BTW I see there is something in "configure" to automatically include 
immintrin.h and it's referred to in the file ./src/liblzma/common/memcmplen.h; 
I'm not sure if that's working correctly. I don't know how to configure the 
"git clone" from configure.ac--I couldn't build. So I downloaded the tar.bz 
file for xz.5.2.3, configure and build on Linux with CC=icc; in a separate 
build/ directory. I didn't see evidence that the automatic include was 
occurring, so I'm doubtful about those lines in the file memcmplen.h which are 
#include immintrin.h conditionally.  I'd be glad to follow up on this if you 
send me a recipe.  As well it is possible to get a free developer license for 
the Intel c++ compiler for certain open source usages.  In any source file that 
refers to Intel intrinsics, there should be a #include of <immintrin.h> to 
future-proof the usage.

I work for Intel on the Intel C++ compiler team. --Melanie Blower

diff --git a/src/common/tuklib_integer.h b/src/common/tuklib_integer.h
index a7fda67..830e49e 100644
--- a/src/common/tuklib_integer.h
+++ b/src/common/tuklib_integer.h
@@ -98,6 +98,15 @@

+// Compiler specific features //
+#if defined(__INTEL_COMPILER) && (__INTEL_COMPILER >= 1500)
+#include <immintrin.h>
 // Byte swapping //
@@ -168,7 +177,6 @@
 #      endif

Reply via email to