icc 17.0 can't compile immintrin.h header from gcc 4.4.7

icc 17.0 can't compile immintrin.h header from gcc 4.4.7

I am trying to compile our project with icc with -mavx option, and it cannot recognise gcc built-ins from avxintrin.h (such as __builtin_ia32_loadupd256 and __m256d). We don't include the header directly, it comes from tbb headers through immintrin.h header. How can I fix this issue? Or is gcc 4.7 just too old for icc 17, i.e. not supported?

Update: it looks like Intel compiler looks in gcc headers for immintrin.h, even when I supply only Intel include directory on command line. Is gcc include dir picked from some env variables?

7 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Can you provide us a test case to investigate?

Thanks,

I figured today that icpc was a bash shell that set up some variables and invoked the compiler, icpcbin. Then I tried icpcbin directly, and it worked, so the error comes from the setup done by icpc. It is this setup that directs icpcbin to gcc headers.

The test case:

command line:   

/xenv/ICC/X/17.0/bin/icpc -o test.exe -c test.cpp -m64  -O3  -unroll8 -mavx  -I/xenv/ICC/X/17.0/include/icc

Source file:

#include "/xenv/ICC/X/17.0/include/icc/immintrin.h"     //case 1
//#include <immintrin.h>                                //case 2

 

Case 1 produces following errors:

/xenv/C++/ia64/4.4.7r11_64/RH6.6AS_64/usr/lib/gcc/x86_64-redhat-linux/4.4.7/include/wmmintrin.h(34): error: #error directive: "AES/PCLMUL instructions not enabled"

/xenv/ICC/X/17.0/include/icc/immintrin.h(31): error: expected an identifier
    typedef union  _MMINTRIN_TYPE(32) __m256 {

/xenv/ICC/X/17.0/include/icc/immintrin.h(31): error: expected a ";"
    typedef union  _MMINTRIN_TYPE(32) __m256 {

    (the last two errors repeat for all __m256 typedefs)
    When immintrin.h is included explicitly from ICC directroy, the headers included from within immintrin.h are picked from gcc directories due to setup created by icpc script.

 

Case 2 produces following errors:

xenv/C++/ia64/4.4.7r11_64/RH6.6AS_64/usr/lib/gcc/x86_64-redhat-linux/4.4.7/include/avxintrin.h(847): error: no declaration for "__m256d"; missing #include directive
    return (__m256d) __builtin_ia32_loadupd256 (__P);
                     ^
/xenv/C++/ia64/4.4.7r11_64/RH6.6AS_64/usr/lib/gcc/x86_64-redhat-linux/4.4.7/include/avxintrin.h(847): error: identifier "__builtin_ia32_loadupd256" is undefined
    return (__m256d) __builtin_ia32_loadupd256 (__P);
                     ^

    (again, the errors are repeated for all __m256 types)
    This time immintrin.h is included from the direcory set up by icpc script, which is the gcc include dir. As a result, ICC cannot recognize gcc built-ins (because in ICC the intrinsics are not based on built-ins).

By the way, icpc script in our installation has a typo at the end, $ICC}  instead of  ${ICC}, which gets invoked when the script is run without parameters. Please check if the typo exists in the latest version.

Did you source the compilervar before invoke it?

 

I hadn't; I just did, but it didn't help - same errors...

I couldn't be able to reproduce it on my system.

vahoang@orcsle100:/tmp$ icpc -o t.out t.cpp -m64  -O3  -unroll8 -mavx -I/cts/tools/compiler/cpro/Compiler/17.0/update_2/compilers_and_libraries_2017.2.174/linux/compiler/include/icc/immintrin.h -c
vahoang@orcsle100:/tmp$ cat t.cpp
#include"/cts/tools/compiler/cpro/Compiler/17.0/update_2/compilers_and_libraries_2017.2.174/linux/compiler/include/icc/immintrin.h"
//#include<immintrin.h>
vahoang@orcsle100:/tmp$ icpc -o t.out t.cpp -m64  -O3  -unroll8 -mavx -I/cts/tools/compiler/cpro/Compiler/17.0/update_2/compilers_and_libraries_2017.2.174/linux/compiler/include/icc/immintrin.h -c
vahoang@orcsle100:/tmp$ cat t.cpp
//#include"/cts/tools/compiler/cpro/Compiler/17.0/update_2/compilers_and_libraries_2017.2.174/linux/compiler/include/icc/immintrin.h"
#include<immintrin.h>

vahoang@orcsle100:/tmp$ gcc -v
gcc version 4.4.4 20100726 (Red Hat 4.4.4-13) (GCC)
vahoang@orcsle100:/tmp$
 

Leave a Comment

Please sign in to add a comment. Not a member? Join today