compile failed of v0.3.5 in Red Hat 4.8 with Xeno gold 6148

[aagu]

../kernel/x86_64/dgemm_tcopy_8_skylakex.c:118:2: error: unknown type name ‘__m256d’ __m256d row1, row2, row3, row4, row5, row6, row7, row8; ^ ../kernel/x86_64/dgemm_tcopy_8_skylakex.c:119:2: warning: implicit declaration of function ‘_mm256_loadu_pd’ [-Wimplicit-function-declaration] row1 = _mm256_loadu_pd(aoffset1); ^ ../kernel/x86_64/dgemm_tcopy_8_skylakex.c:136:2: warning: implicit declaration of function ‘_mm256_storeu_pd’ [-Wimplicit-function-declaration] _mm256_storeu_pd(boffset2 + 0, row1); ^ ../kernel/x86_64/dgemm_tcopy_8_skylakex.c:232:4: error: unknown type name ‘__m512d’ __m512d row1, row2, row3, row4; ^ ../kernel/x86_64/dgemm_tcopy_8_skylakex.c:253:2: error: unknown type name ‘__m256d’ __m256d row1, row2, row3, row4; ^ ../kernel/x86_64/dgemm_tcopy_8_skylakex.c:320:4: error: unknown type name ‘__m512d’ __m512d row1, row2; ^ ../kernel/x86_64/dgemm_tcopy_8_skylakex.c:334:2: error: unknown type name ‘__m256d’ __m256d row1, row2; ^ ../kernel/x86_64/dgemm_tcopy_8_skylakex.c:380:2: error: unknown type name ‘__m512d’ __m512d row1; ^ ../kernel/x86_64/dgemm_tcopy_8_skylakex.c:391:2: error: unknown type name ‘__m256d’ __m256d row1; ^ make[1]: *** [dgemm_itcopy.o] Error 1 make[1]: Leaving directory /home/huanghai/g/xianyi-OpenBLAS-eebc189/kernel'
make: *** [libs] Error 1
`
this was the last few lines of output.
I tried to add TARGET=SKYLAKEX and NO_AVX512=1, but still went wrong.

[martin-frbg]

SKYLAKEX with NO_AVX512=1 is equivalent to setting TARGET=HASWELL so you could try that just to get it to build. As the build system does not catch this, it seems your compiler has at least some AVX512 capability, but still lacks some key type definitions (or the compiler did not find its only include files). Which compiler version is this ?

[aagu]

SKYLAKEX with NO_AVX512=1 is equivalent to setting TARGET=HASWELL so you could try that just to get it to build. As the build system does not catch this, it seems your compiler has at least some AVX512 capability, but still lacks some key type definitions (or the compiler did not find its only include files). Which compiler version is this ?

gcc version 4.8.5

[aagu]

and I made a mistake, the distro is Red Hat 4.8.5-11

[martin-frbg]

Hmm. There does appear to be a loophole when one sets TARGET=SKYLAKEX ... does it still fail when you do not specify a TARGET ?

[aagu]

Hmm. There does appear to be a loophole when one sets TARGET=SKYLAKEX ... does it still fail when you do not specify a TARGET ?

Yes, I tried execute 'make' without parameters, the results I posted earlier were the outputs

[fenrus75]

looks like this vintage compiler does not even support AVX2...

https://access.redhat.com/support/policy/updates/errata claims the RHEL4.x series went end of life in 2017 though so not sure what can be easily done about it, other than "don't try to use AVX on it"

[fenrus75]

(one can likely use a newer compiler to compile, and then use the compiled output on RHEL4.x)

[martin-frbg]

Oh well. The compiler test actually gets called too late to affect cpu target selection - it does set NO_AVX512=1 but this does not get picked up in time now. Not sure why (I thought) it worked in earlier versions.
gcc 4.8.5 should support AVX2 I think, but for AVX512 you would need at least gcc 6.x

[martin-frbg]

Actually the compile-time check is only good for adding avx512-specific compiler options, but this did not hurt as the first of the skylakex kernels had a builtin fallback to the corresponding haswell kernel if the gcc version was found to be too old.

[fenrus75]

error: unknown type name ‘__m256d’

that's avx2 already

the fallback can't work for the gemm kernels since we need different in/out copy sizes ;=(

[martin-frbg]

gcc should support AVX2 since 4.7.0 , but apparently it needs -mavx2 to actually enable the intrinsics (which was not an issue with inline assembly). I can make TARGET=SKYLAKEX NO_AVX512=1 act like make TARGET=HASWELL, and if I borrow your gcc version check perhaps I can even teach getarch to do the right thing on its own.

[brada4]

It is RHEL7 actually
https://distrowatch.com/table.php?distribution=centos
You can get updated compilers as described here:
https://github.com/xianyi/OpenBLAS/wiki/faq#binutils
(install gcc binutils gfortran from latest devtoolset, also check uname -r if you have recent enough kernel, I will rewrite that considering 0.3.4+ AVX512 support one day)

Alternatively you can get AVX2-enabled (and AVX-512 disabled) openblas from Fedora EPEL without any need for compilers

@martin-frbg @fenrus75 - multiple things are necessary - as supporting AVX2 and AVX512, and gcc supporting intrinsics header , and gfortran supporting -mavx* flag, RHEL6 has old binutils, RHEL7 misses any intrinsics headers, even both support -march flags
There is no AVX(1) in RHEL4, there was a chance to get AVX2 from RHEL5 via devtoolset 2.1, but released after end of sales when RHEL7 was already available.
Also up to 0.3.3 there was no need for AVX2 intrinsics headers, probably costs heavier ifdef-s

[martin-frbg]

I believe this should be covered by PR #1980 - AVX2 intrinsics are only required by the most recent Haswell kernels, with a fallback mechanism already in place for compilers that do not announce AVX2 capability. I am not convinced there is still a need to add workarounds for compilers that do not even support AVX after all these years. (Or if there is, perhaps a new issue should be created if and when this becomes a problem)