CI: Intel icx/icpx via oneAPI

[ax3l]

Add testing for Intel icx/icpx via the oneAPI images.
This is Intel's next-gen compiler and new C++ support, e.g. C++17 bug fixes, first land here.

For the Intel "classic" compilers icc/icpc, please see #2573

[YannickJadoul]

New compiler, all green, within 24h? Is this possible, or am I dreaming?

EDIT: Oh... no. Somehow, the CI workflow hasn't even run :-(

[henryiii]

Yaml must be invalid?

[henryiii]

@ax3l The issue now is in the CMake config to force it to recognize icpx.

[ax3l]

Potential these two are also needed:
Fix compiler detection that made it into the CMake shipped with oneAPI. This is already fixed in CMake upstream.

[ax3l]

Is this actually preferred over $(which python3)?

[henryiii]

This works on bash for Windows or something like that, I don't remember exactly why. Pretty sure it had to do with portability somehow. which should be just fine for this sort of thing on linux for sure.

[henryiii]

I am making vectorize a bit easier to compile in #2729 - don't know why it's compiling but not working here.

[henryiii]

What is this identifying as, I wonder? Does it define the intel macros? Clang macros? Both? Neither?

[ax3l]

What is this identifying as, I wonder? Does it define the intel macros? Clang macros? Both? Neither?

Oh that's a bug that slipped into CMake v3.19.0-rc1-v3.19.1 (reverted afterwards) and that in turn slipped into a oneAPI release: https://gitlab.kitware.com/cmake/cmake/-/issues/21551

It's reverted now and complete IntelLLVM and SYCL/DPC++ support is being worked on:

• https://gitlab.kitware.com/cmake/cmake/-/merge_requests/5594 (merged as IntelLLVM for icx: CMake 3.20+)
• https://gitlab.kitware.com/cmake/cmake/-/merge_requests/5701 (FindSYCL.cmake: essentially icx --dpcpp -fsycl aka dpcpp)

So if we leave this open until the next oneAPI release comes out and ships CMake 3.20+ (usually a month max.) then we should be able to remove the work-around of the compiler detection.

[ax3l]

Once we have IntelLLVM (icx) in, we can start to explore the reason for those multiple-definition errors of math functions with dpc++ (aka icx --dpcpp -fsycl).
AMReX-Codes/pyamrex#5

Likely an upstream Intel issue, but we'll see.

[ax3l]

Yay, made some progress. Now we have a few tests that fail the vectorization tests.

test_vectorize

________________________________ test_vectorize ________________________________
def test_vectorize():
n = 3
array = m.create_rec_simple(n)
values = m.f_simple_vectorized(array)
> np.testing.assert_array_equal(values, [0, 10, 20])
E AssertionError: E Arrays are not equal
E E Mismatched elements: 2 / 3 (66.7%)
E Max absolute difference: 20
E Max relative difference: 1.
E x: array([0, 0, 0], dtype=uint32)
E y: array([ 0, 10, 20])
../../tests/test_numpy_dtypes.py:375: AssertionError

test_vectorized_noreturn

___________________________ test_vectorized_noreturn ___________________________
def test_vectorized_noreturn():
x = m.NonPODClass(0)
assert x.value == 0
m.add_to(x, [1, 2, 3, 4])
> assert x.value == 10
E assert 4 == 10
E + where 4 = <pybind11_tests.numpy_vectorize.NonPODClass object at 0x7f52c5d3f730>.value
../../tests/test_numpy_vectorize.py:263: AssertionError