Open yurivict opened 3 years ago
I do not have access to test this on a processor that doesn't support AVX at all, but just asked a colleague to test it on a processor that has AVX but not AVX2. It worked as expected.
Could you please post your CMakeOutput.log and CMakeError.log files?
On the one processor I have available for testing this type of issue (Intel Xeon E5-2690 v2), CMake Chrono configuration correctly identifies AVX support but no AVX2 support when using clang 10.0.1 (same as what you use).
Having said that, when using GCC we force testing the host architecture by adding -march=native
.
We do not do that for clang. I am not sure why it works with my setup but doesn't with yours.
I pushed a modification to also set the native architecture when testing SIMD support with clang in the feature/clang
branch. Could you please test that code and let me know if it fixes your issue?
The latest rev. c4921ab from feature/clang
still builds with these SIMD flags: -msse4.2 -mfpmath=sse -mavx2 -mfma
.
You are not cross-compiling, right?
Could you maybe print a message somewhere in the elseif branch at lines 38-41 of cmake/FindAVX.cmake in the feature/clang
branch code and check that it gets executed?
You are not cross-compiling, right?
Not ctoss-compiling.
Could you maybe print a message somewhere in the elseif branch at lines 38-41 of cmake/FindAVX.cmake in the feature/clang branch code and check that it gets executed?
I prefixed it with (Clang)
and it printed this:
-- (Clang) Using CPU native flags for AVX optimization:
-mavx2
is added elsewhere.
Yes, that is added a few lines below when attempting to build a small test program. Without -march-native
, clang compiles that successfully even if the host does not support AVX2 (this is actually also the case with GCC) and so -mavx2
is used from there on.
The question is why isn't -march=native
appended to AVX_FLAGS at line 39.
I'm curious about the behavior of this issue in release 7.0.3. The SIMD changes that I made in PR #384 removed a bit of redundant checking that might have caused some problems. If it's still a problem, hopefully I can shed a little bit more light on the issue as I merge the changes into develop
as well.
relevant cmake output section:
cpu identification: