[SYCL] Solve name resolution problems due to Windows integer types

[mibintc]

There are 3 Windows CTS tests, math_builtin_relational_base,
math_builtin_float_double, math_builtin_integer that fail at compile
time in all 3 environments.

Here's a small reproducer showing the symptom:

The error is like this,
math_builtin_float_double.cpp:8:12: error: no matching function for call to 'nan'
auto x = cl::sycl::nan(y);
^~~~~~~~~~~~~
...include\CL/sycl/builtins.hpp:398:1: note: candidate template
ignored: requirement 'detail::integral_constant<bool, false>::value' was not satisfied [with T = int]
nan(T nancode) __NOEXC {
^
1 error generated.

Here’s a smaller version of the invoker,

int foo(void)
{
//unsigned long int y = 1; FAIL like above
//long int y = 1; FAIL like above
//int y = 1; FAIL like above
unsigned y = 1; // This one is OK
auto x = cl::sycl::nan(y);
}

Erich suggested,

https://godbolt.org/z/XkWVHg

Even on MSVC, “unsigned int” and “unsigned long” are different types, despite sizeof being the same for both.

The header itself uses __int32 and __int64, which are just aliases on MSVC for “unsigned int” and “unsigned long long”.

THUS, the list in the headers (which I copied below) doesn’t contain ANY version of “unsigned long” on Windows. Ulonglong (the other being checked) is ALSO “unsigned long long”

On linux, the list is:
cl_uint == unsigned int
cl_ulong == unsigned long
ulonglong == unsigned long long.

Thus, the whole list is covered.

I suspect that one of the checks (is_ugenlong probably ) simply needs to have “unsigned long” added to it as an option in addition to cl_ulong. Alternatively, cl_ulong could be corrected.

Either way, a header issue.

Signed-off-by: Melanie Blower [email protected]

[mibintc]

I made a git error trying to upload another revision of #516, so i uploaded a clearn version here.

[bader]

@mibintc, could you check if #623 solves "name resolution problems", please?

[mibintc]

@mibintc, could you check if #623 solves "name resolution problems", please?

I applied #623 to my windows otcshare / workspace and i tried the test
tc -t khronos_sycl_cts/math_builtin_relational_base -l opt_use_cpu -r none -x efi2_win64_sycl

But the error diagnostics are similar to what was seen before. Let me know if there's a different test case that you want me to try.

======== math_builtin_relational_base log file =============================================
Test result: compfail compiler exit status 1
-------- compiler output ----------------------------------------------
math_builtin_relational_base.cpp:870:8: error: no matching function for call to 'any'
return cl::sycl::any(inputData_0);
^~~~~~~~~~~~~
d:\iusers\mblower\otcshare.0909\build\lib\clang\9.0.0\include\CL/sycl/builtins.hpp:1337:1: note: candidate template ignored: requirement 'detail::integral_constant<bool, false>::value' was not satisfied [with T = long]
any(T x) __NOEXC {
^
d:\iusers\mblower\otcshare.0909\build\lib\clang\9.0.0\include\CL/sycl/builtins.hpp:1345:1: note: candidate template ignored: requirement 'detail::integral_constant<bool, false>::value' was not satisfied [with T = long]
any(T x) __NOEXC {
^

[alexeyvoronov-intel]

Please rebase.

[alexeyvoronov-intel]

Will something broken if we will delete cl_ulong from here?
I prefer see one type here, like in a comment(SYCL spec, ugenlong set) above.
The same applies to other changes.

[bader]

@mibintc, @alexeyvoronov, does #669 resolve "name resolution problems"?

[alexeyvoronov-intel]

@mibintc, @alexeyvoronov, does #669 resolve "name resolution problems"?

Yes,
The SYCL headers use standard C++ types. The SYCL library uses types prefixed with cl_. In SelectMatchingOpenCLType_t function mapping occurs C++ types and OpenCL type aliases.

[bader]

@mibintc, please, close this PR, if you agree with @alexeyvoronov.