[SYCL] Align `range` to SYCL 2020 specs by Robertkq · Pull Request #22889 · intel/llvm

Robertkq · 2026-08-06T12:40:24Z

This PR introduces an explicit line for range destructor (Rule of 5 or 0 is mandatory) and a missing overload for operator op, alongside multiple missing noexcept keywords for functions

Robertkq · 2026-08-06T13:03:03Z

This PR introduces an explicit line for range destructor (Rule of 5 or 0 is mandatory) and a missing overload for operator op, alongside multiple missing noexcept keywords for functions

Robertkq · 2026-08-06T13:05:31Z

 #define __SYCL_GEN_OPT(op)                                                     \
  __SYCL_GEN_OPT_BASE(op)                                                      \
  friend range<Dimensions> operator op(const range<Dimensions> &lhs,           \
                                       const size_t &rhs) {                    \


This overload is not in SYCL 2020 latest documentation, not adding noexcept

Robertkq · 2026-08-06T13:05:36Z

    return result;                                                             \
  }                                                                            \
  friend range<Dimensions> operator op(const size_t &lhs,                      \
                                       const range<Dimensions> &rhs) {         \


This overload is not in SYCL 2020 latest documentation, not adding noexcept

Robertkq · 2026-08-06T13:06:05Z

    return lhs;                                                                \
  }                                                                            \
  friend range<Dimensions> &operator op(range<Dimensions> &lhs,                \
                                        const size_t &rhs) {                   \


This overload is not in SYCL 2020 latest documentation, not adding noexcept. Also it is not guarded by __SYCL_DISABLE_ID_TO_INT_CONV__ like the previous ones

I guess that's why you've also skipped some operators on lines 112 & 120 (upd. oh sorry you've already mentioned this above)? I'm not sure why we need these, I need to check the spec.

I believe this should also have noexcept. It's an #else branch of #ifndef __SYCL_DISABLE_ID_TO_INT_CONV__, although I don't know yet why we need this.
Anyways, std::is_integral_v<size_t> equals to true.
UPD looks like previously in SYCL 2020 were only operators with size_t args, but DPC++ supported all integer types. Seems like then it became part of the standard, see #4538 (comment)

@KseniyaTikhomirova do you know what is the purpose of __SYCL_DISABLE_ID_TO_INT_CONV__? At least here it looks like it does nothing as the code in both branches of this macro is same.

function body is same but function signature is different. Depending on this macro id<> to size_t convertion is enabled and operator can accept more types. Although I don't really know the reason why it is worth disabling and it is not a default option, I assume it may be done to enable some compiler optimization. @sergey-semenov do you know anything about it?

@sergey-semenov should we just get rid of this and unify the code?

As it stands, this is an undocumented feature that we support, but at least we provide a way to turn it off. I think this should be formalized as a proper extension (assuming we want to keep supporting this) and then we can get rid of the macro.

@sergey-semenov why is it not a part of spec?

https://github.com/intel/llvm/blob/sycl/sycl/include/sycl/id.hpp#L106

class id declaration in SYCl2020 contains:

// only available if Dimensions == 1 operator std::size_t() const noexcept;

Whoops, I somehow overlooked that. Then yeah, we should just get rid of the macro.

@Robertkq feel free to remove this or just skip this so we'll remove this later.

Robertkq · 2026-08-06T13:07:34Z

-range(size_t, size_t, size_t)->range<3>;
+range(size_t) -> range<1>;
+range(size_t, size_t) -> range<2>;
+range(size_t, size_t, size_t) -> range<3>;


automatic change from my clang-format, I think it adheres to coding style rules of the repository

That's ok, let's update this. In general try to use git clang-format HEAD~ after you've created a commit. It'll only format your changes then.

Yeah this is my first time running into this kind of issue, maybe I don't know exactly how to fix it but I ran: python3 clang/tools/clang-format/git-clang-format HEAD~ which also with use of AI, I think should format correctly, but it left the files unmodified. Can you please tell me if with your clang-format version it really doesnt do this change?

I have this:

clang-format version 22.1.8 (Fedora 22.1.8-4.fc44)

Anyways, I can always just save without formatting and remove this, but I'd like to confirm / learn something new from this if possible :D

See https://github.com/intel/llvm/blob/sycl/clang/tools/clang-format/git-clang-format
You need to put it to your PATH. Then call git clang-format *commit* where *commit* is the commit to compare current changes with, in general it's the previous commit.

Robertkq · 2026-08-06T13:08:36Z

@KornevNikita @KseniyaTikhomirova can you take a look over the PR? Thanks!

Robertkq · 2026-08-06T13:34:49Z

Also, I wasn't able to find an existing test file to add a case for the new overload. If it exists and it can be provided to me, I'll happily add tests, otherwise I think the PR can continue?

KornevNikita · 2026-08-06T13:43:52Z

This PR introduces an explicit line for range destructor (Rule of 5 or 0 is mandatory) and a missing overload for operator op, alongside multiple missing noexcept keywords for functions

could you please add this to the description

KornevNikita · 2026-08-06T15:15:04Z


  range(const range<Dimensions> &rhs) = default;
-  range(range<Dimensions> &&rhs) = default;
+  range(range<Dimensions> &&rhs) noexcept = default;


IIUC SYCL 2020 doesn't require these functions (for by-value semantics) to be noexcept.

That's right.. I thought that I should apply good practice here to add noexcept for move functions so they could benefit from moves. standard library usually moves types only if they have noexcept move constructor / operator, but now I properly understand that this type is designed to be passed by value and as such this noexcept should bring little to no improvement, so I will most likely remove it from here

KornevNikita · 2026-08-06T15:22:39Z

    return lhs;                                                                \
  }                                                                            \
  friend range<Dimensions> &operator op(range<Dimensions> &lhs,                \
                                        const size_t &rhs) {                   \


I guess that's why you've also skipped some operators on lines 112 & 120 (upd. oh sorry you've already mentioned this above)? I'm not sure why we need these, I need to check the spec.

KornevNikita · 2026-08-06T15:24:10Z

-range(size_t, size_t, size_t)->range<3>;
+range(size_t) -> range<1>;
+range(size_t, size_t) -> range<2>;
+range(size_t, size_t, size_t) -> range<3>;


That's ok, let's update this. In general try to use git clang-format HEAD~ after you've created a commit. It'll only format your changes then.

Add missing functions & noexcept keyword

0062520

Robertkq changed the title ~~Add missing functions & noexcept keyword~~ [SYCL] Add missing functions & noexcept keyword Aug 6, 2026

Robertkq changed the title ~~[SYCL] Add missing functions & noexcept keyword~~ [SYCL] Align range to SYCL 2020 specs Aug 6, 2026

Robertkq commented Aug 6, 2026

View reviewed changes

remove comments

83ded7a

Robertkq commented Aug 6, 2026

View reviewed changes

Robertkq marked this pull request as ready for review August 6, 2026 13:08

Robertkq requested a review from a team as a code owner August 6, 2026 13:08

Robertkq requested a review from KseniyaTikhomirova August 6, 2026 13:08

add noexcept to detail::array

e267437

KornevNikita reviewed Aug 6, 2026

View reviewed changes

Uh oh!

Conversation

Robertkq commented Aug 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Robertkq commented Aug 6, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

KornevNikita Aug 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

KornevNikita Aug 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

KseniyaTikhomirova Aug 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Robertkq commented Aug 6, 2026

Uh oh!

Robertkq commented Aug 6, 2026

Uh oh!

KornevNikita commented Aug 6, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

KornevNikita Aug 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Robertkq commented Aug 6, 2026 •

edited

Loading

KornevNikita Aug 6, 2026 •

edited

Loading

KornevNikita Aug 6, 2026 •

edited

Loading

KseniyaTikhomirova Aug 7, 2026 •

edited

Loading

KornevNikita Aug 6, 2026 •

edited

Loading