khronosgroup/sycl-cts

SYCL Conformance Tests

SYCL 2020 Conformance Test Suite

This is the SYCL Conformance Test Suite for the Khronos Group SYCL standard.

The test suite comes in the form of multiple binary executables that must be compiled before running, a step that requires CMake. All test cases inside the tests directory are grouped into categories. Compilation produces executables for each category and one fat executable that contains the tests from all categories.

Important: Due to its large size, by default the CTS is compiled in a lighter configuration that omits some combinations of testing logic for the sake of reduced compilation and execution time. This can be useful during development, however is not sufficient to establish conformance. See the sections on CMake Configuration Options and Generating a Conformance Report for more information.

Configuration & Compilation

To compile the CTS, the following dependencies are required:

• Python 3.7 or higher
• CMake 3.15 or higher
• A SYCL implementation
  • The CTS currently supports DPC++ and hipSYCL
  • See the AddSYCLExecutable.cmake module on how to add support for additional SYCL implementations

Configuration and compilation then follow standard CMake procedures. Begin by cloning this repository and its submodules:

git clone --recurse-submodules https://github.com/KhronosGroup/SYCL-CTS.git

Then enter the SYCL-CTS folder and configure the build using CMake:

cmake -S . -B build -DSYCL_IMPLEMENTATION=<DPCPP|hipSYCL>

See CMake Configuration Options for additional configuration options that can be passed here.

Finally, start the compilation:

cmake --build ./build

After the compilation has finished, test executables for each category will be placed in the build/bin directory. The test_all executable contains tests for all categories.

CMake Configuration Options

The CTS can be configured using the following CMake configuration options:

SYCL_IMPLEMENTATION (default: None) DPCPP or hipSYCL.

SYCL_CTS_EXCLUDE_TEST_CATEGORIES (default: None) Optional file specifying a list of test categories to be excluded from the build.

SYCL_CTS_ENABLE_FULL_CONFORMANCE (default: OFF) Enable extended type coverage and testing logic with significantly increased compilation and execution time. This mode is required to establish the conformance of a SYCL implementation.

SYCL_CTS_VERBOSE_LOG (default: OFF) Enable verbose debug-level logging.

SYCL_CTS_ENABLE_DOUBLE_TESTS (default: ON) Enable tests that require double precision floating point capabilities.

SYCL_CTS_ENABLE_HALF_TESTS (default: ON) Enable tests that require half precision floating point capabilities.

SYCL_CTS_ENABLE_DEPRECATED_FEATURES_TESTS (default: ON) Enable tests for legacy SYCL features. Should be switched on for conformance.

SYCL_CTS_ENABLE_OPENCL_INTEROP_TESTS (default: ON) Enable OpenCL interoperability tests.

Additionally, the following SYCL implementation-specific options can be used:

DPCPP_INSTALL_DIR (default: None)

DPCPP_FLAGS (default: None) Set additional compiler flags for DPC++ compiler. This options applies only if SYCL_IMPLEMENTATION is set to DPCPP.

DPCPP_TARGET_TRIPLES (default: None) Configures compilation for specified target triple.

DPCPP_DISABLE_SYCL2020_DEPRECATION_WARNINGS (default: ON) Disables warnings about using features deprecated by SYCL 2020.

DPCPP_SYCL2020_CONFORMANT_APIS (default: ON) Enables conformant SYCL 2020 API in DPC++ implementation. Current DPC++ version exposes SYCL 1.2.1 compatible API version by default.

Running the Test Suite

Each of the executables produced in the build/bin directory acts as a standalone test runner that can be used to launch tests for a particular test category (or all tests in the case of build/bin/test_all).

The --device argument is used to specify which device to run the tests on. Selection is based on substring matching of the device name. ECMAScript regular expression syntax is supported. To get a list of all available devices, use --list-devices.

Please see <test_executable> --help for a complete list of available filtering and output formatting options.

Generating a Conformance Report

To generate a conformance report, use the run_conformance_tests.py script. This script automates the configuration, compilation and execution of the CTS, generating a report file conformance_report.xml. By default, the script will enable the SYCL_CTS_ENABLE_FULL_CONFORMANCE option, resulting in long compilation and execution times.

Please see run_conformance_tests.py --help for a complete list of available options.

Contributing to the CTS

See the SYCL CTS Developer Documentation.

sycl-cts's Issues

[CI] Change host compiler to Clang

Mixing GCC and Clang can lead to all kinds of issues (e.g. #483), and it is not a high-priority use case. It was therefore decided in today's call that we'll change the host compiler to Clang.

Possible bug in `accessor_legacy` tests

I am currently trying to run the accessor_legacy tests with Open SYCL.

The parallel_for in this line is a nd_range parallel_for. The kernel is defined here and takes a sycl_id_t<dim> as its argument which is basically an alias to sycl::id<dim == 0 ? 1 : dim>. Shouldn't this be a sycl::nd_item instead?

I tried to just change it to a sycl::nd_item but there are other functions that expect the index to be a sycl::id (for instance the function expected_write here) and I wanted to make sure that my understanding is correct and that this is a bug before working on this further.

Using accessor with vector load store methods

Conformance tests invoke vec's load and store methods passing accessor:

SYCL-CTS/tests/vector_load_store/generate_vector_load_store.py

Lines 40 to 41 in d7281bf

	testVec${type_as_str}${size}.load(0, inPtr${type_as_str}${size});
	testVec${type_as_str}${size}.store(0, outPtr${type_as_str}${size});

There's no such overloading in the spec. And while there's a constructor that can create a multi_ptr from an accessor, looks like compilers fail to deduce template arguments in such cases.
I have prepared a small reproducer that implements the same interface as in the spec:

#include <type_traits>

enum class address_space {
    local,
    global
};

enum class access_target {
    global,
    local,
    constant
};

enum class mode {
    read,
    write
};

enum class placeholder {
    true_t,
    false_t
};

template <typename ElementType, int dimensions, mode AccMode, access_target Target,
         placeholder isPlaceholder>
class accessor {
};

template <typename ElementType, address_space Space>
class multi_ptr {
  template <int dimensions, mode Mode, placeholder isPlaceholder,
           typename = typename std::enable_if<Space == address_space::global>::type>
  multi_ptr(accessor<ElementType, dimensions, Mode, access_target::global, isPlaceholder>) {}
};

template <typename ElementType, address_space Space>
void foo(multi_ptr<ElementType, Space> mptr) {}

void bar() {
    accessor<int, 1, mode::read, access_target::global, placeholder::false_t> a;
    foo(a);
}

Neither of clang, gcc or MSVC is able to compile this code. One could use template deduction guides, but they're C++17 feature.
So, should we update the spec by adding a new overload or is it a deficiency of the conformance test suite?

Commit "add tests for common reference semantics" fails CTS compilation on CUDA with DPCPP

Guilty commit: 4c073ce (might be not the only one)

Logs: https://github.com/intel/llvm/actions/runs/4129760637/jobs/7136039243

@nolmoonen could you please take a look?

@bader, FYI

`test_vector_operators` does not cover logical and relational operators

They are generated as part of the following template:

SYCL-CTS/tests/vector_operators/generate_vector_operators.py

Line 432 in eec8701

specific_return_type_test_template = Template("""

Which is only used by the following function:

SYCL-CTS/tests/vector_operators/generate_vector_operators.py

Line 1351 in eec8701

def generate_all_types_specific_return_type_test(type_str, size):

Which is in turn never called from anywhere in the generator script, leaving all those operators completely untested by CTS.

Note: I'm actually working on rewriting this particular test to drop python generator script, use catch2 and improve error messages. This rewrite should fix the problem, but I still wanted to highlight it here. Work-in-progress branch for very early preview can be found here: https://github.com/AlexeySachkov/SYCL-CTS/commits/private/asachkov/refactor-vector-operators-test

CTS uses type aliases which do not exist in the spec

SYCL-CTS/tests/math_builtin_api/modules/sycl_types.py

Line 102 in b856fd7

t_schar_2 = argtype("sycl::schar2", "vector", "char", 2, [])

According to 4.14.2.2. Aliases, there are no more aliases like schar3 or ulonglong2.

Perhaps this was a spec mistake to remove some of them, there is a related spec issue KhronosGroup/SYCL-Docs#335

Simplify CLI device selection mechanism

The current mechanism for selecting a device to run the CTS on requires the user to specify a combination of SYCL device type and one out of a hard-coded list of vendor names for platform selection (e.g. Intel or ARM). This is both outdated (in that it distinguishes between a "host device" and "OpenCL device") and -- in my opinion -- needlessly cumbersome.

I would like to propose a simpler yet more flexible alternative based on substring matching. Instead of the four existing CLI parameters --platform / -p / --device / -d, there would only be two: The existing --device and a new --list-devices. While the latter can be used to list all devices currently available (including their device type and platform name), the former is used for selecting one of the devices based on substring matching (and optionally regex syntax).

Examples:

> ./bin/test_all --list-devices --device "OpenCL.*Xe"
4 devices available (* = currently selected):
  Type         Platform / Device
  cpu          Intel(R) OpenCL / 11th Gen Intel(R) Core(TM) i7-1185G7 @ 3.00GHz
* gpu          Intel(R) OpenCL HD Graphics / Intel(R) Iris(R) Xe Graphics [0x9a49]
  gpu          Intel(R) Level-Zero / Intel(R) Iris(R) Xe Graphics [0x9a49]
  host         SYCL host platform / SYCL host device

> ./bin/test_all --list-devices --device "Level-Zero.*Xe"
4 devices available (* = currently selected):
  Type         Platform / Device
  cpu          Intel(R) OpenCL / 11th Gen Intel(R) Core(TM) i7-1185G7 @ 3.00GHz
  gpu          Intel(R) OpenCL HD Graphics / Intel(R) Iris(R) Xe Graphics [0x9a49]
* gpu          Intel(R) Level-Zero / Intel(R) Iris(R) Xe Graphics [0x9a49]
  host         SYCL host platform / SYCL host device

In this case I've chosen to match over not just the device name, but the platform name as well (as listed, i.e., <platform name> / <device name>). The --device flag could therefore also be called --platform-device or something, but that may be a bit awkward.

Question about test cases distribution between FULL and non-FULL modes

Hi folks,

We have been working on support for SYCL 2020 specialization constants in our SYCL implementation at intel/llvm and we have realized that unless you switch into FULL mode, you are missing a huge piece of data type coverage for test_specialization_constants. In particular, we do not test vec and marray data types in non-FULL mode at all in those tests.

Therefore, I was wondering if there are some guideline about how CTS should be written to ensure meaningful coverage in both FULL and non-FULL modes? Do we need to explicitly document the distribution in test plans?

[SYCL-CTS] The CTS selector queries name for vendor, instead of simply vendor

The snippet below shows what I think its an obvious typo:

SYCL-CTS/tests/common/cts_selector.h

Lines 100 to 101 in 7e469d1

	cl::sycl::string_class vendor =
	dev.get_platform().get_info<cl::sycl::info::platform::name>();

If everyone agrees it is a typo, we can submit an MR with a fix.

sub-group warning: variable length arrays in C++ are a Clang extension

SYCL-CTS/tests/sub_group/sub_group_semantics.cpp

Lines 120 to 123 in 9691bc0

	TEST_CASE("Check sycl::sub_group equality", "[sub_group]") {
	size_t code_count =
	to_integral(common_by_value_semantics::current_check::size);
	bool result[code_count];

Build log:

[649/1195] Building CXX object tests/sub_group/CMakeFiles/test_sub_group_objects.dir/sub_group_semantics.cpp.o
../tests/sub_group/sub_group_semantics.cpp:123:15: warning: variable length arrays in C++ are a Clang extension [-Wvla-cxx-extension]
  123 |   bool result[code_count];
      |               ^~~~~~~~~~
../tests/sub_group/sub_group_semantics.cpp:123:15: note: read of non-const variable 'code_count' is not allowed in a constant expression
../tests/sub_group/sub_group_semantics.cpp:121:10: note: declared here
  121 |   size_t code_count =
      |          ^
1 warning generated.

Evaluate current CTS coverage

Background

An accurate picture of the current coverage is essential to prioritize a breadth-first approach for further enhancement of the CTS. Currently, there is no detailed description of the exact feature coverage of the CTS.

Proposed approach

We intend to produce a preliminary feature list using scripts, which are subsequently hand-verified by developers. We will pay special attention to Chapter 4 of the CTS and Appendix B during this process. We plan on analyzing the already existing development plans to get insight into the required level of coverage.

Can you please highlight additional resources and parts of the specification that we should consider?

Output

We will share an excel sheet with the estimated level of coverage for each section of the considered part of the specification.

Does `OpenCL` is really required?

Hi,

SYCL-CTS/CMakeLists.txt

Line 12 in 94a4b36

find_package(OpenCL REQUIRED)

Does OpenCL is really required?

I try to build the CTS on a system where OpenCL is not available.

Update CTS for stream interface clarifications

Tracking of CTS investigation for spec MR: KhronosGroup/SYCL-Docs#58

Math arrays and new function overloads missing from the math built-in api tests

The math built-in api test is missing coverage for math arrays. It looks like this can be fixed by adding code to the generic types (in a similar way as vec already in the test) and adding the missing overloads.

Improve ranges and index space identifiers tests

Several tests for the ranges and index space identifiers launch a kernel which returns a single status code indicating whether the test passed or failed. This is suboptimal, as it does not help the user in identifying which specific member function is not conforming. Examples of this are h_item/h_item_api.cpp, item/item_(1|2|3)d.cpp, and nd_item/nd_item_api.cpp, perhaps others as well.

A better solution could be to return an array of status codes (group/group_api.cpp or range/range_api.cpp) or to use multiple independent kernel launches (id/id.cpp). Perhaps these approaches can be consolidated as well.

vector operators `bool` warnings

Can't insert a nice source code snippet in here, because source code is generated. Generator can be found here: tests/vector_operators/generate_vector_operators.py

Build log:

[936/1195] Building CXX object tests/vector_operators/CMakeFiles/test_vector_operators_objects.dir/vector_operators_bool.cpp.o
tests/vector_operators/vector_operators_bool.cpp:732:40: warning: converting the result of '<<' to a boolean; did you mean '(static_cast<_Bool>(1) << static_cast<_Bool>(2)) != 0'? [-Wint-in-bool-context]
  732 |       resArr[i] = static_cast<bool>(1) << static_cast<bool>(2);
      |                                        ^
tests/vector_operators/vector_operators_bool.cpp:836:40: warning: converting the result of '<<' to a boolean; did you mean '(static_cast<_Bool>(1) << static_cast<_Bool>(2)) != 0'? [-Wint-in-bool-context]
  836 |       resArr[i] = static_cast<bool>(1) << static_cast<bool>(2);
      |                                        ^
tests/vector_operators/vector_operators_bool.cpp:976:19: warning: bitwise negation of a boolean expression always evaluates to 'true'; did you mean logical negation? [-Wbool-operation]
  976 |       resArr[i] = ~static_cast<bool>(1);
      |                   ^~~~~~~~~~~~~~~~~~~~~
      |                   !

[sycl next] Add tests for newly introduced `queue query`

SYCL next added/may/will add new members functions to sycl::queue. (Similar to the function added by this intel extension: https://github.com/intel/llvm/blob/sycl/sycl/doc/extensions/proposed/sycl_ext_oneapi_queue_status_query.asciidoc).

We should create tests for those.

PS: Please assign me to it.

Introducing new tests *.exe-files architecture

Hi all,

After building some test we have only one *.exe-file for each test group (exceptions, buffer, etc.), but test for kernel_bundle required few *.exe-files due to we must have stricted set of kernels in the application.
For example: test for get_kernel_ids_multiple_kernels, get_kernel_ids_single_kernel and get_kernel_ids_no_kernels
should contained in separate *.exe-file due to get_kernel_ids function couldn't chose which kernel should use and which kernel should be ignored
Building process:
if we will use make test_kernel_bundle then will be builded all tests, except tests, that mentioned in independent_cases_list in the the tests/kernel_bundle/CMakeLists.txt file.
for build this tests need call building process for each test separately: make test_get_kernel_ids_multiple_kernels, make test_get_kernel_ids_single_kernel and make test_get_kernel_ids_no_kernels
But if use make all tests will be builded

Some tests for kernel_bundle thematic can be found here: KhronosGroup/SYCL-CTS PR #218

Incorrect usage of half data type?

If I understand correctly, SYCL 1.2.1 specification doesn't define cl::sycl::half data type and only defines cl::sycl::cl_half data type.

However, the former is used a lot across SYCL CTS tests. Could please someone help to understand if it is a bug of SYCL CTS or SYCL 1.2.1 spec?

this search query shows 29 results, but some of them are incorrect, so, there is only ~15 places where cl::sycl::half is used.

SYCL_CTS_ENABLE_OPENCL_INTEROP_TESTS=Off doesn't disable "vector_swizzles_opencl" test

When -DSYCL_CTS_ENABLE_OPENCL_INTEROP_TESTS=Off is provided to build sycl-cts tests "opencl_interop" is not build.
But "vector_swizzles_opencl" is built and this tests passes when using DPCPP CUDA backend.

This is confusing, is this an expected behaviour? Shouldn't the test be disabled when SYCL_CTS_ENABLE_OPENCL_INTEROP_TESTS=Off?

Possible errors in `accessor_legacy` tests

Hello,

I am currently trying to compile the accessor_legacy test with Open SYCL (previously known as hipSYCL) and I am getting a number of compile errors where I am not 100% sure if it is an error in the CTS or in Open SYCL.

In the tests, there are a number of constructs that essentially boil down to this: There is a templated function of the following form

template <typename T>
void foo() {
  auto val = static_cast<T>(42);
}

and the this function is then called with various types for T, in particular with sycl::vecs, for example

  using type = sycl::vec<float, 2>;
  foo<type>();

One example can be found here.

This leads to a compile error because according to the specification, the constructor of a sycl::vec that only takes a single argument of type const DataT& (the type of the elements that the vec holds) is marked explicit. However, in most of the cases (as in the example above), the type of the argument (42 in this example) and the type of the vec's elements (float in this example) do not match.

This could be solved by introducing a type trait that checks if T is a sycl::vec and, if T is indeed a sycl::vec, replacing the line in the example above by something like

auto val = T(static_cast<typename T::element_type>(42));

i.e., explicitly casting the argument to the correct type before calling the constructor.

My question basically is whether or not I correctly understand the spec, i.e., if something like the example above should compile according to the spec or not.

Kernel bundle tests warning: non-void function does not return a value in all control paths

The following function triggers warning during CTS build:

SYCL-CTS/tests/kernel_bundle/use_kernel_bundle.h

Lines 102 to 115 in 9691bc0

	template <typename KernelT>
	inline sycl::kernel_bundle<sycl::bundle_state::executable> get_non_empty_bundle(
	const sycl::context &ctx) {
	auto kernel_id = sycl::get_kernel_id<KernelT>();
	try {
	auto k_bundle = sycl::get_kernel_bundle<sycl::bundle_state::executable>(
	ctx, ctx.get_devices(), {kernel_id});
	return k_bundle;
	} catch (const sycl::exception &e) {
	if (sycl::errc::invalid == e.code())
	SKIP(
	"Test skipped because no device is compatible with requested kernel");
	}
	}

Example of build log:

In file included from ../tests/kernel_bundle/use_kernel_bundle_call_set_spec_const_after_use_kb_no_second_queue.cpp:13:
../tests/kernel_bundle/use_kernel_bundle.h:115:1: warning: non-void function does not return a value in all control paths [-Wreturn-type]
  115 | }
      | ^
../tests/kernel_bundle/use_kernel_bundle_call_set_spec_const_after_use_kb_no_second_queue.cpp:73:9: note: in instantiation of function template specialization 'sycl_cts::tests::use_kernel_bundle::get_non_empty_bundle<sycl_cts::test
s::use_kernel_bundle::kernel_for_kernel_bundle>' requested here
   73 |         get_non_empty_bundle<kernel_for_kernel_bundle>(ctx);
      |         ^
1 warning generated.
[426/1195] Building CXX object tests/kernel_bundle/CMakeFiles/test_kernel_bundle_objects.dir/use_kernel_bundle_call_set_spec_const_after_use_kb_with_second_queue.cpp.o
In file included from ../tests/kernel_bundle/use_kernel_bundle_call_set_spec_const_after_use_kb_with_second_queue.cpp:13:
../tests/kernel_bundle/use_kernel_bundle.h:115:1: warning: non-void function does not return a value in all control paths [-Wreturn-type]
  115 | }
      | ^
../tests/kernel_bundle/use_kernel_bundle_call_set_spec_const_after_use_kb_with_second_queue.cpp:76:9: note: in instantiation of function template specialization 'sycl_cts::tests::use_kernel_bundle::get_non_empty_bundle<sycl_cts::te
sts::use_kernel_bundle::kernel_for_kernel_bundle>' requested here
   76 |         get_non_empty_bundle<kernel_for_kernel_bundle>(ctx);
      |         ^
1 warning generated.

Using ComputeCPP in GitHub Actions CI.

According to https://codeplay.com/portal/news/2023/07/07/the-future-of-computecpp, there will be no support for ComputeCpp starting September 1 2023. Considering that ComputeCpp won't be able to pass all conformance tests by that time, I suggest we remove compilation with ComputeCpp in CI and clean-up conditional compilation configured for ComputeCpp.

Reduce duplicate code in tests for `sycl::item`

The one-, two-, and three-dimensional tests for sycl::item in tests/item/item_1d.cpp, tests/item/item_2d.cpp, and tests/item/item_3d.cpp have a lot of code in common. This common code should be factored out. The tests for the other multidimensional classes can serve as an example of how this can be done (id, range, nd_range, nd_item).

Tests for deprecated features.

I wonder if there are any plans to have some separate test category for deprecated APIs. Deprecation doesn't mean removal and it still means that the functionality must be supported. What is CTS development strategy in that regard?

Originally posted by @AlexeySachkov in #163 (comment)

Update sycl::id tests for SYCL 2020

I'm opening this issue somewhat "post-mortem", as I've already updated the tests for sycl::id in #246. However, since then two problems have come up, and I'd like to use this opportunity to give the CTS Development GitHub project I've just created a try.

• Convert id tests to SYCL 2020 (done in #246)
• Don't require unnamed kernels (currently heavily used in DEVICE_EVAL)
• Remove id_constructors.cpp, which was brought back accidentally with a recent merge commit.

Pull request workflow - require up-to-date branches?

We currently have a problem where a PR (#203) that predates the CI setup was merged, breaking compilation for ComputeCpp. This then lead to all new PRs in the last month to also fail CI. While CI has been fixed, those existing PRs are still marked as failed, and re-running the GitHub actions unfortunately doesn't help: While the pull_request trigger used for our workflow first merges the source branch into the base (target) branch and then runs the tests, it seems that re-running does not merge into the current version of the base branch, instead reusing the revision from when the PR was created (a bit of a limitation on GitHub's part, in my opinion).

There are basically two ways how the existing PRs can be run against the current SYCL-2020 branch:

1. The author force-pushes the source branch (at least I think that will then use the current base branch, haven't tested it though)
2. The base branch is back-merged into the source branch

To avoid further breakage from these now untested PRs I've temporarily enabled branch protection on the SYCL-2020 branch, which requires that all CI checks pass before we can merge, and also requires that the source branch is up-to-date. The latter setting causes GitHub to show the following button:

I've tried this for #230, where you can see that while DPCPP is still running at the time of writing, the ComputeCpp run has already passed.

Now my question is, should we keep this setting in general? The advantage is that we're guaranteed that merging a PR won't break CI. The downside is that we'll introduce more noise into the history with all those back-merge commits.

optional kernel features warning: an attribute specifier sequence in this position is a C++23 extension

SYCL-CTS/tests/optional_kernel_features/kernel_features_common.h

Lines 336 to 342 in 9691bc0

	} else if constexpr (CallType ==
	call_attribute_type::external_decorated_with_attr) {
	return [acc] [[sycl::device_has(AnotherFeatureAspect)]] {
	use_feature_function_external_decorated<FeatureTypeT, FeatureAspectT>(
	acc);
	};
	} else if constexpr (CallType == call_attribute_type::non_decorated) {

Example of build log:

[560/1195] Building CXX object tests/optional_kernel_features/CMakeFiles/test_optional_kernel_features_objects.dir/kernel_features_sub_group_size_exceptions.cpp.o
In file included from ../tests/optional_kernel_features/kernel_features_sub_group_size_exceptions.cpp:26:
../tests/optional_kernel_features/kernel_features_common.h:338:18: warning: an attribute specifier sequence in this position is a C++23 extension [-Wc++23-extensions]
  338 |     return [acc] [[sycl::device_has(AnotherFeatureAspect)]] {
      |                  ^
../tests/optional_kernel_features/kernel_features_common.h:353:16: warning: an attribute specifier sequence in this position is a C++23 extension [-Wc++23-extensions]
  353 |     return [=] [[sycl::device_has(FeatureAspectT)]] {
      |                ^
../tests/optional_kernel_features/kernel_features_common.h:359:16: warning: an attribute specifier sequence in this position is a C++23 extension [-Wc++23-extensions]
  359 |     return [=] [[sycl::device_has(AnotherFeatureAspect)]] {
      |                ^
3 warnings generated.

vector deduction guides warning: variable length arrays in C++ are a Clang extension

SYCL-CTS/tests/vector_deduction_guides/vec_deduction_guides.cpp

Lines 30 to 36 in 9691bc0

	template <typename T>
	class check_vec_deduction {
	public:
	void operator()(const std::string& type) {
	type_name = type;
	T data[max_size];

If I understand correctly, we need to replace const with constexpr static here:

SYCL-CTS/tests/vector_deduction_guides/vec_deduction_guides.cpp

Lines 66 to 67 in 9691bc0

	private:
	const int max_size = 16;

The fact that class member variable is defined as const doesn't make it into a compile-time-known constant, it only means that it is immutable.

Build log:

[834/1195] Building CXX object tests/vector_deduction_guides/CMakeFiles/test_vector_deduction_guides_objects.dir/vec_deduction_guides.cpp.o
../tests/vector_deduction_guides/vec_deduction_guides.cpp:36:12: warning: variable length arrays in C++ are a Clang extension [-Wvla-cxx-extension]
   36 |     T data[max_size];
      |            ^~~~~~~~
../tests/vector_deduction_guides/../common/../common/type_coverage.h:404:5: note: in instantiation of member function 'vec_deduction_guides::check_vec_deduction<float>::operator()' requested here
  404 |   ((action<types, actionArgsT...>{}(std::forward<argsT>(args)...,
      |     ^
../tests/vector_deduction_guides/vec_deduction_guides.cpp:90:3: note: in instantiation of function template specialization 'for_all_types<vec_deduction_guides::check_vec_deduction, char, signed char, unsigned char, short, unsigned
short, unsigned int, long, unsigned long, long long, unsigned long long, bool, float>' requested here
   90 |   for_all_types<check_vec_deduction>(deduction::vector_types);
      |   ^
../tests/vector_deduction_guides/../common/disabled_for_test_case.h:42:3: note: expanded from macro 'DISABLED_FOR_TEST_CASE'
   42 |   INTERNAL_CTS_DISABLED_FOR_TEST_CASE(__VA_ARGS__)
      |   ^
../tests/vector_deduction_guides/../common/disabled_for_test_case.h:130:40: note: expanded from macro 'INTERNAL_CTS_DISABLED_FOR_TEST_CASE'
  130 |   INTERNAL_CTS_MAYBE_DISABLE_TEST_CASE(INTERNAL_CTS_ENABLED_TEST_CASE, \
      |                                        ^
../tests/vector_deduction_guides/vec_deduction_guides.cpp:36:12: note: implicit use of 'this' pointer is only allowed within the evaluation of a call to a 'constexpr' member function
   36 |     T data[max_size];
      |            ^

The next `SYCL-2020` functional to cover by tests

Now we don't have any goal to cover by SYCL-2020 conformance tests.
We need help to set goal that will be covered by conformance tests.

`marray` test does not test everything (or anything?) on device

Maybe I'm missing something as I haven't reviewed the whole test, but here is at least one code path which I've traced:

SYCL-CTS/tests/marray/marray_operators_core.cpp

Lines 29 to 32 in eec8701

	TEST_CASE("operators core", "[marray]") {
	const auto types = marray_common::get_types();
	for_all_types<check_marray_operators_for_type>(types);
	}

Which brings us to:

SYCL-CTS/tests/marray/marray_operators.h

Lines 482 to 486 in eec8701

	static const auto unary_operators =
	named_type_pack<op_upos, op_uneg, op_pre_inc, op_pre_dec, op_lnot,
	op_bnot>::generate("unary +", "unary -", "pre ++",
	"pre --", "!", "~");
	for_all_combinations<run_unary, DataT>(num_elements, unary_operators);

Then:

SYCL-CTS/tests/marray/marray_operators.h

Lines 150 to 155 in eec8701

	void operator()(const std::string& operator_name) {
	INFO("for operator \"" << operator_name << "\": ");
	const auto functions = get_sequences<NumElementsT::value>();
	for_all_combinations<run_unary_sequence, DataT, NumElementsT, OpT>(
	functions);

And finally:

SYCL-CTS/tests/marray/marray_operators.h

Lines 120 to 133 in eec8701

	void operator()(const std::string& function_name) {
	INFO("for input (sequence) \"" << function_name << "\": ");
	OpT op;
	typename helper::varray_t val_expected(helper::NumElements);
	helper::template init<SequenceT>(val_expected);
	auto res_expected = op(val_expected);
	typename helper::marray_t val_actual;
	helper::template init<SequenceT>(val_actual);
	auto res_actual = op(val_actual);
	CHECK(value_operations::are_equal(res_expected, res_actual));

From what I can see, there is no mention of queues or devices at all. Perhaps it is hidden somewhere deep in the helpers, but I don't think that it is the case. Looks more like we really only test marray functionality on host

Potential bugs in CTS when running with hipSYCL

Hello,

I am currently trying to compile and run the tests with hipSYCL to see what is missing in hipSYCL but I came across a few tests that fail not because hipSYCL does not support certain things required by the standard but because the tests are (as far as I can tell) testing things that are in fact not required by the standard. I'd be very happy to contribute to the CTS but I first wanted to discuss these things here, since I might also just misunderstand parts of the SYCL specification.

Here are a few of the things I found so far:

• Edit: I somehow missed the SYCL_CTS_ENABLE_OPENCL_INTEROP_TESTS flag, so ignore this point.
  Some tests use the sycl::cl_ types (e.g. the scalars test and the stream tests) but I think SYCL implementations without an OpenCL backend do not require those types. So maybe these types should be tested in a separate test that can be enabled/disabled depending on the SYCL implementation that is used.
• marray has its own test but a few other test make use of marray and hence fail if marray is not implemented (e.g., the buffer tests and the multi_ptr tests). We have not (yet) implemented marray in hipSYCL and so some tests now fail only because they depend on marray but might otherwise work.
• In the device_selector tests, there are a bunch of conversion errors (e.g. conversion from gpu_selector to device_selector fails). These arise since the method get_cts_object::device in tests/common/get_cts_object.h expects a sycl::device_selector as its argument but the SYCL spec does not require [...]_selector to be derived from device_selector (see Table 14 in Section 4.6.1.1 of the SYCL 2020 Specification). I guess this could easily be fixed by just replacing the sycl::device_selector argument by a generic template parameter, for example.
• In the vector_alias tests, there are two issues:
  • First, the tests do not take the environment variable SYCL_CTS_ENABLE_HALF_TESTS into account (but this is of course easily fixed).
  • Second, the tests expect char2 == vec<char,2> but the standard requires char2 == vec<int8_t, 2>, see Section 4.14.2.2 of the SYCL 2020 spec, and in general char != int8_t.

That's what I found so far, let me know what you think.

set_final_data in image test segfaults

set_final_data in the image_api test writes to memory that goes out of scope before the image, leading to a segfault.

sycl::mix testing is problematic

sycl::mix testing is both overly strict, and insufficiently wide.

sycl::mix is specified as

https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#_common_functions

Preconditions: If the inputs are scalars, the value of a must be in the range [0.0, 1.0]. If the inputs are not scalars, each element of a must be in the range [0.0, 1.0].

Returns: The linear blend of x and y. When the inputs are scalars, returns x + (y - x) * a. Otherwise, returns x[i] + (y[i] - x[i]) * a[i] for each element of x, y, and a.

This is tested in the CTS by making sure that we are within 1 ULP of x + (y - x) * a for randomized inputs between 0.1 and 0.9.

The first problem here is that the SYCL specification uses a blend of mathematical expressions and C++ expressions without specifying which is which, almost certainly this is meant to be taken as a mostly-mathematical expression (see e.g. degrees, where the vector version is specified as returning (180 / π) * radians[i], which clearly cannot be a C++ expression), the C++ expression x + (y - x) * a is not (in general) within 1 ULP of the mathematical result rounded suitably to the appropriate C++ floating point type, and the C++ expression x + (y - x) * a is not (in general) a good implementation.

mix was added to C++20 as std::lerp (except without the restriction on 0 <= a <= 1) and this was carefully considered at that time. In P0811R3: Well-behaved interpolation for numbers and pointers, S. Davis Herring writes:

Both obvious approaches used in published implementations of floating-point linear interpolation have issues:

1. a+t*(b-a) does not in general reproduce b when t==1, and can overflow if a and b have the largest exponent and opposite signs.
2. t*b+(1-t)*a is not monotonic in general (unless the product ab≤0).

It goes on to list properties that are desired for std::lerp, including these. By testing that mix is within 1 ULP of a reference implementation that is known to not generally be useful, the CTS requires an implementation of mix that is not generally useful.

Additionally, in OpenCL, single-precision mix is specified as "absolute error tolerance of 1e-3" (full profile) or "Implementation-defined" (embedded profile). A stricter check for mix than what OpenCL specifies implies that a sycl::mix implementation that defers to OpenCL mix cannot, in general, pass the SYCL CTS, which seems undesirable.

The second problem here is that by only testing values between 0.1 and 0.9, the worst problems with this reference implementation never even come up during CTS tests and go unnoticed, both in the CTS itself and in implementations that take guidance from the CTS.

New builtin guarantees should be covered by the builtins tests

With the clarifications to the SYCL builtins in KhronosGroup/SYCL-Docs#428 and KhronosGroup/SYCL-Docs#440, the builtins now make additional guarantees about how they can be used. These additional guarantees should be tested.

Tentative list of additional test cases:

1. Tests for swizzle to vector implicit conversion when used in a vector builtin.
2. Tests for implicit conversion of arguments for non-templated overloads.
3. Tests for explicit template instantiations for templated overloads.

Build reduction failed

The project in branch SYCL-2020 is builed by command:

cmake -DCMAKE_BUILD_TYPE=Debug -DSYCL_IMPLEMENTATION=DPCPP -DDPCPP_TARGET_TRIPLES=amdgcn-amd-amdhsa -DDPCPP_INSTALL_DIR=/my/llvm/build/ -DOpenCL_INCLUDE_DIR=/my/llvm/build/include/sycl/ -DOpenCL_LIBRARY=/my/llvm/build/lib/libOpenCL.so ..

Then, I want to test reduction. But it is builded failed with command : make -j 8 test_reduction.
Is there any problem about intel/llvm version?
The build failed log:

/home/shaoen/mlx/SYCL-CTS-Debug/tests/reduction/reduction_without_identity_param_fp64.cpp:38:40: error: reference to 'without_property' is ambiguous
run_tests_for_all_functors<double, without_property>()(range, queue, log,
^
/home/shaoen/mlx/SYCL-CTS-Debug/tests/reduction/reduction_without_identity_param_common.h:56:7: note: candidate found by name lookup is 'reduction_without_identity::without_property'
using without_property = std::false_type;
^
/home/shaoen/mlx/SYCL-CTS-Debug/tests/reduction/reduction_common.h:20:16: note: candidate found by name lookup is 'reduction_common::without_property'
constexpr bool without_property{false};
^
/home/shaoen/mlx/SYCL-CTS-Debug/tests/reduction/reduction_without_identity_param_fp64.cpp:38:40: error: reference to 'without_property' is ambiguous
run_tests_for_all_functors<double, without_property>()(range, queue, log,
^
/home/shaoen/mlx/SYCL-CTS-Debug/tests/reduction/reduction_without_identity_param_common.h:56:7: note: candidate found by name lookup is 'reduction_without_identity::without_property'
using without_property = std::false_type;
^
/home/shaoen/mlx/SYCL-CTS-Debug/tests/reduction/reduction_common.h:20:16: note: candidate found by name lookup is 'reduction_common::without_property'
constexpr bool without_property{false};
^
/home/shaoen/mlx/SYCL-CTS-Debug/tests/reduction/reduction_without_identity_param_fp64.cpp:40:40: error: reference to 'with_property' is ambiguous
run_tests_for_all_functors<double, with_property>()(nd_range, queue, log,
^
/home/shaoen/mlx/SYCL-CTS-Debug/tests/reduction/reduction_without_identity_param_common.h:55:7: note: candidate found by name lookup is 'reduction_without_identity::with_property'
using with_property = std::true_type;
.....
too many error，not shown....

build problem

How do I set the cmake options on a machine with oneapi base kit installed under /opt/intel/oneapi

cmake .. -DOpenCL_FOUND=True -DOpenCL_LIBRARY=/usr/lib/x86_64-linux-gnu
-- The CXX compiler identification is GNU 9.3.0
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMake Deprecation Warning at cmake/FindOpenCLTargets.cmake:27 (message):
Use the official FindOpenCL module if CMake <3.7 support can be dropped
Call Stack (most recent call first):
CMakeLists.txt:12 (find_package)

-- Looking for CL_VERSION_2_2
-- Looking for CL_VERSION_2_2 - found
-- Found OpenCL: /usr/lib/x86_64-linux-gnu (found version "2.2")
-- Found OpenCLTargets: /usr/include
-- Found PythonInterp: /opt/intel/oneapi/intelpython/latest/bin/python3 (found suitable version "3.7.10", minimum required is "3")
CMake Error at /usr/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:146 (message):
Could NOT find ComputeCpp (missing: ComputeCpp_EXECUTABLE
ComputeCpp_LIBRARIES ComputeCpp_INCLUDE_DIRS)
Call Stack (most recent call first):
/usr/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:393 (_FPHSA_FAILURE_MESSAGE)
cmake/FindComputeCpp.cmake:24 (find_package_handle_standard_args)
cmake/AddSYCLExecutable.cmake:13 (find_package)
CMakeLists.txt:26 (include)

accessor_iterator_requirement.cpp uses virtual functions on device side

Hi,

We recently added accessor iterators support to intel/llvm repo and I've been trying to enable corresponding CTS tests. Unfortunately, they can't be compiled due to some errors in them and while some of them are trivial to fix, there is one I would like to discuss first.

As the title says, there is a code within those tests, which uses virtual functions on device side of the test. It originates from WARN macro we have in some tests to indicate that coverage might not be full due to parameters passed to a helper function.

Error example:

In file included from KhronosGroup/SYCL-CTS/tests/accessor/accessor_iterator_requirement.cpp:9:
In file included from KhronosGroup/SYCL-CTS/tests/accessor/../../util/named_requirement_verification/legacy
_random_access_iterator.h:14:
In file included from KhronosGroup/SYCL-CTS/tests/accessor/../../util/named_requirement_verification/legacy
_bidirectional_iterator.h:14:
In file included from KhronosGroup/SYCL-CTS/tests/accessor/../../util/named_requirement_verification/legacy
_forward_iterator.h:17:
In file included from KhronosGroup/SYCL-CTS/vendor/Catch2/src/catch2/../catch2/catch_test_macros.hpp:11:
In file included from KhronosGroup/SYCL-CTS/vendor/Catch2/src/catch2/../catch2/internal/catch_test_macro_im
pl.hpp:11:
KhronosGroup/SYCL-CTS/vendor/Catch2/src/catch2/../catch2/internal/catch_assertion_handler.hpp:41:33: error:
·
      SYCL kernel cannot call a virtual function
                m_resultCapture.handleIncomplete( m_assertionInfo );
                                ^
In file included from KhronosGroup/SYCL-CTS/tests/accessor/accessor_iterator_requirement.cpp:9:
In file included from KhronosGroup/SYCL-CTS/tests/accessor/../../util/named_requirement_verification/legacy
_random_access_iterator.h:14:
In file included from KhronosGroup/SYCL-CTS/tests/accessor/../../util/named_requirement_verification/legacy
_bidirectional_iterator.h:14:
KhronosGroup/SYCL-CTS/tests/accessor/../../util/named_requirement_verification/legacy_forward_iterator.h:11
9:7: error:·
      SYCL kernel cannot call an undefined function without SYCL_EXTERNAL attribute
      WARN(
      ^
KhronosGroup/SYCL-CTS/vendor/Catch2/src/catch2/../catch2/catch_message.hpp:131:23: note:·
      expanded from macro 'WARN'
  #define WARN( msg ) INTERNAL_CATCH_MSG( "WARN", Catch::ResultWas::Warning, Catch::ResultDisposition::ContinueOnFailure, msg )
                      ^
KhronosGroup/SYCL-CTS/vendor/Catch2/src/catch2/../catch2/catch_message.hpp:94:33: note:·
      expanded from macro 'INTERNAL_CATCH_MSG'
        Catch::AssertionHandler catchAssertionHandler( macroName##_catch_sr, CATCH_INTERNAL_LINEINFO, Catch::StringRef(), resul...
                                ^
KhronosGroup/SYCL-CTS/vendor/Catch2/src/catch2/../catch2/internal/catch_assertion_handler.hpp:34:9: note:·
      'AssertionHandler' declared here
        AssertionHandler
        ^
KhronosGroup/SYCL-CTS/tests/accessor/../../util/named_requirement_verification/legacy_forward_iterator.h:51
:3: note:·
      called by 'is_satisfied_for<int *>'
  is_satisfied_for(It valid_iterator, const size_t container_size) {
  ^

An example of code triggering the error:

SYCL-CTS/util/named_requirement_verification/legacy_forward_iterator.h

Lines 118 to 122 in be8304d

	if (container_size == 0) {
	WARN(
	"Some of the test requires container size more than 0. These tests "
	"have been skipped.");
	} else {

Note: we one more similar occurrences in legacy_bidirectional_iterator.h.

I haven't prototyped any solution yet, just commented out uses of WARN macro in those files simply to proceed further. Before I submit a PR, I would like to get an early feedback to see which solution would be preferable:

1. Drop the warning completely. This could lead to incomplete testing coverage later on
2. Do not support use case when warning is required. Basically, the idea is to fail the test if container_size passed to the helper is 0
3. Convert warning into a message printed through sycl::stream
4. Refactor those "requirement" classes so they have separate host-only method for arguments verification: the test must first call that method to (potentially) trigger the warning on host and only then proceed with the test. Well that sounds like (1) with extra steps
5. Drop the container_size parameter completely with corresponding branch.

Personally, I would vote for (5), because we anyway don't have any checks in that container_size == 0 branch and container_size doesn't seem to be used anywhere else. Unless I'm missing something or there were further plans to add more checks.

Several comments/suggestions/questions about scalars_sycl_types test

There are bunch of checks which look strange/unnecessary to me:

First of all, why do we check sizes of char, short int, long int and other standard C++ types? I understand that SYCL compiler might be bad and break C++ spec by changing size of standard C++ types on the host, but do we really need to check that SYCL compiler is conformant with C++ standard? If so, we also need to check for a lot more things than just sizes of standard C++ types.

Anyway, the following check is wrong:

SYCL-CTS/tests/scalars/scalars_sycl_types.cpp

Lines 39 to 42 in a5c913e

	if (!check_type_min_size<char>(1)) {
	FAIL(log,
	"The following host type does not have the correct size: char");
	}

C++ standard guarantees that sizeof(char) == 1, while this check will accept the compiler where sizeof(char) >= 1.

SYCL spec defines bunch of aliases which has exact bit-width (Table 4.95), but these types are not properly tested as well:

SYCL-CTS/tests/scalars/scalars_interopability_types.cpp

Lines 41 to 42 in 3744dc3

	check_type_min_size_sign_log<cl::sycl::cl_char>(log, 1, true,
	"cl::sycl::cl_char");

cl_char - Alias to a signed 8-bit integer, as defined by the C++11 ISO Standard.

But the code in CTS will accept implementation with sizeof(cl_char) == 2, for example, which is not conformant with the SYCL spec

SYCL-CTS/tests/scalars/scalars_sycl_types.cpp

Lines 102 to 118 in a5c913e

	// sizes
	accSizeResult[0] = check_type_min_size<char>(1);
	accSizeResult[1] = check_type_min_size<unsigned char>(1);
	accSizeResult[2] = check_type_min_size<signed char>(1);
	accSizeResult[3] = check_type_min_size<unsigned short int>(2);
	accSizeResult[4] = check_type_min_size<short int>(2);
	accSizeResult[5] = check_type_min_size<unsigned int>(2);
	accSizeResult[6] = check_type_min_size<int>(2);
	accSizeResult[7] = check_type_min_size<unsigned long int>(4);
	accSizeResult[8] = check_type_min_size<long int>(4);
	accSizeResult[9] = check_type_min_size<unsigned long long int>(8);
	accSizeResult[10] = check_type_min_size<long long int>(8);
	accSizeResult[11] = check_type_min_size<size_t>(host_size_t_size);
	accSizeResult[12] = check_type_min_size<cl::sycl::byte>(1);
	accSizeResult[13] = check_type_min_size<cl::sycl::half>(2);
	accSizeResult[14] = check_type_min_size<float>(4);
	accSizeResult[15] = check_type_min_size<double>(8);

What is the purpose of these checks? According to Section 6.5 Built-in scalar data types:

In a SYCL device compiler, the device definition of all standard C++ fundamental types from Table 6.1 must match the host definition of those types, in both size and alignment. A device compiler may have this preconfigured so that it can match them based on the definitions of those types on the platform, or there may be a necessity for a device compiler command-line option to ensure the types are the same.

Would it be better then to capture sizes of fundamental C++ types on host and compare that they are the same on device side?

hierarchical_implicit_reduce test is disabled due to return at the very first line

SYCL-CTS/tests/hierarchical/hierarchical_implicit_reduce.cpp

Lines 150 to 154 in 806294d

	*/
	void run(util::logger &log) override {
	return;
	try {
	cts_selector sel;

error: DisableFTZ needs an implentation

when build,error:

error: ForceFTZ needs an implentation

error: DisableFTZ needs an implentatio

nerror: RestoreFPState needs an implementation

Why is it?

Build error on enabling accessor implicit conversion tests

Below message is at the top of accessor_implicit_conversion_core.cpp and a number of other implicit conversion files.

// FIXME: re-enable when sycl::accessor is implemented
// Issue link https://github.com/intel/llvm/issues/8298

The Issue 8298 is already addressed. An attempt to enable the tests by modifying file as below:

* !defined(__SYCL_COMPILER_VERSION) -> defined(__SYCL_COMPILER_VERSION)
* DISABLED_FOR_TEST_CASE(hipSYCL, ComputeCpp, DPCPP) -> DISABLED_FOR_TEST_CASE(hipSYCL, ComputeCpp) // line 29

showed two main build errors (there are other ones which seem to be fixed once the below two are addressed):

• accessor_implicit_conversions.h:81:5: error: no matching constructor for initialization of 'Catch::SectionInfo' SECTION(
• accessor_implicit_conversions.h:90:30: error: unknown type name 'DataT', using SrcDataT = const DataT;

Using `sycl::half` in functions like `std::floor` is ambiguous

In some places, std functions that have overloads for both float and double are called with sycl::half arguments. In OpenSYCL, we provide conversion operators for half -> float and half -> double which then leads to errors like error: call to 'floor' is ambiguous.

The SYCL spec is a bit vague w.r.t. the half class, but I think implementing conversion operators for both float and double is valid, so maybe explicit casts should be added when calling std::floor, std::fmin etc. with half arguments. What do you think?

Test that CGF is invoked synchronously within same thread as call to `sycl::queue`

This was just clarified in KhronosGroup/SYCL-Docs#354.

Something along the lines of

std::thread::id cgf_tid;
queue.submit([&](sycl::handler& cgh) {
	cgf_tid = std::this_thread::get_id();
	cgh.host_task([] {});
});
CHECK(cgf_tid == std::this_thread::get_id());

Provide prebuild binaries

I tried to compile code from this repository several times, but each time I found new problems and I have neither the time nor the will to fix it.
Latest error is

/home/rafal/test/SYCL-CTS/util/../tests/common/common.h:25:10: fatal error: 'sycl/sycl.hpp' file not found
#include <sycl/sycl.hpp>
         ^~~~~~~~~~~~~~~
1 error generated.
gmake[2]: *** [util/CMakeFiles/util.dir/build.make:76: util/CMakeFiles/util.dir/aspect_set.cpp.o] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:1733: util/CMakeFiles/util.dir/all] Error 2
gmake: *** [Makefile:146: all] Error 2

With prebuild binaries I would not have such problems.

I see that already CI produces build times, but also could upload produced binaries.

Bump hipSYCL version and regenerate filters

We haven't updated the hipSYCL version used in CI for over a year (3d8b1cd is from January 2022).

We then should regenerate the CI filters for hipSYCL as well. Although one problem we have here is that presumably most of the tests are compile-time disabled for hipSYCL, and we currently don't have a good way of figuring out which ones we can re-enable...

Add support for reduced feature sets.

A number of SYCL-CTS tests require "full" feature set. For instance, multi_ptr test requires implementation to support generic address space and id test requires implementation to support unnamed SYCL kernel function feature.

Is `platform()` forced to return a host platform?

Hi,

In SYCL2020, the default constructor of the platform returns an instance that is a copy of the platform which contains the device returned by default_selector_v. (https://www.khronos.org/registry/SYCL/specs/sycl-2020/html/sycl-2020.html#_platform_interface)

Hence I think we should change this tests in the CTS? Or maybe the cts hijack default_selector_v to always be a host device.

I can try to make my first PR to CTS if you agree that tests need to be updated.

Regards,
Thomas

test_base_opencl framework do not respect SYCL device selector choice

Test base class for OpenCL interoperability uses first platform and first device for running OpenCL calls.

This approach doesn't work if we have two platforms:

• first platform has no devices with image support (e.g. FPGA)
• second platform has devices with image support (e.g. GPU)

If we run opencl_interop test with GPU device selector, check for image support will pass, but attempt to create OpenCL sampler object will fail as OpenCL always uses first platform unconditionally (i.e. context with FPGA device only in our example).

The same issue exists in constructors part of the test, where SYCL creates objects from OpenCL handlers which might contradict to platform/device set for the test.

We are going to fix this by passing OpenCL handles obtained from the SYCL objects created using cts_selector.

Any other ideas/proposals/comments?

Add check for static constexpr dimensions member to all range/id-like types

Since now KhronosGroup/SYCL-Docs#351 has been merged, we need to test for this feature.