IntelPython / dpnp / 42529225061

84%

push

github

Drop `__LIBSYCL_MAJOR_VERSION` checks dead with the 2026.0 minimum compiler (#3174)

DPC++ 2026.0 is the minimum compiler (the conda recipes reject anything
older), and every 2026.x release ships libsycl 9
(`__LIBSYCL_MAJOR_VERSION 9`). Two `__LIBSYCL_MAJOR_VERSION` checks in
the libtensor headers therefore always take the same branch.

This PR:
- drops the `__LIBSYCL_MAJOR_VERSION < 7` term from `needs_workaround`
in `kernels/reductions.hpp`, which kept `sycl::logical_or<bool>` off
reduce-over-group for older compilers. The term is always false; the
`int64`/`uint64` `sycl::multiplies` exclusion stays.
- removes `USE_GROUP_LOAD_STORE` from `utils/sycl_utils.hpp`, so
`sub_group_load` and `sub_group_store` always use
`group_load`/`group_store` from `sycl_ext_oneapi_group_load_store`. The
`__LIBSYCL_MAJOR_VERSION >= 8u` check already set the macro to 1 (DPC++
2026.0 doesn't define the `SYCL_EXT_ONEAPI_GROUP_LOAD_STORE`
feature-test macro the check looked at first). Setting it to 0 by hand
doesn't work either: the fallback calls the `sycl::sub_group` member
`load`/`store`, and icpx 2026.0 fails with `no member named 'load' in
'sycl::sub_group'`. The macro is defined in a header shipped with dpnp,
hence the changelog entry.

The default build compiles the same code as before. With icpx 2026.2, a
syntax-only compile of both headers passes without warnings, and static
asserts confirm that `needs_workaround` and `can_use_reduce_over_group`
keep their values for `logical_or<bool>` and for the `int64`/`uint64`
`multiplies`.

1792 of 2998 branches covered (59.77%)

Branch coverage included in aggregate %.

29619 of 34217 relevant lines covered (86.56%)

39108.68 hits per line