[Tests] Skipping c++20 MSVC comparison checks on sycl
MSVC STL implementation a consteval trick to allow comparisons with literal zero but not other integers which involves eliminated a dead code function call. However, within a sycl kernel, it seems this dead function call still causes an error complaining that the undefined function call is not SYCL_EXTERNAL.
This was included in https://github.com/microsoft/STL/releases/tag/vs-2022-17.7, specifically this commit https://github.com/microsoft/STL/commit/581b4f089c303123071a173a16ca2f2260a3a891 which corresponds to _MSVC_STL_UPDATE 202303L, 202304L, 202305L. Therefore, we encounter issues on the device after that update when using C++20.
I've added a check for compiler version, and we will follow up with the compiler team to see future versions of intel llvm compiler can compile this code.
Some additional information here: https://github.com/microsoft/STL/issues/4359
It's not a precompiled routine, it's a deliberately undefined routine which is named to give a hint to what's wrong with the code that does not link. The idea is that the type _Literal_zero has an implicit consteval constructor (see https://en.cppreference.com/w/cpp/language/consteval) which argument may only have the value of 0. Due to consteval the only allowed context is constant expressions, so compilers can throw away the function call when the code is valid - but it looks like icpx does not do that for device code.
Some additional information here: microsoft/STL#4359 It's not a precompiled routine, it's a deliberately undefined routine which is named to give a hint to what's wrong with the code that does not link. The idea is that the type
_Literal_zerohas an implicitconstevalconstructor (see https://en.cppreference.com/w/cpp/language/consteval) which argument may only have the value of0. Due to consteval the only allowed context is constant expressions, so compilers can throw away the function call when the code is valid - but it looks like icpx does not do that for device code.
Aha, yes that makes sense now. Thanks for pointing this out. Seems to be an issue with icx not being able to eliminate the function call. We will need to include a icx version number and follow up with the icx team.
I've updated the PR description and added a version check for the compiler, as well as a comment in the code to better describe the issue.