Skip to content

[SYCL] Align range with SYCL 2020 - #22889

Open
Robertkq wants to merge 6 commits into
intel:syclfrom
Robertkq:Robertkq/22736
Open

[SYCL] Align range with SYCL 2020#22889
Robertkq wants to merge 6 commits into
intel:syclfrom
Robertkq:Robertkq/22736

Conversation

@Robertkq

@Robertkq Robertkq commented Aug 6, 2026

Copy link
Copy Markdown
Contributor

fixes #22736

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 Robertkq changed the title Add missing functions & noexcept keyword [SYCL] Add missing functions & noexcept keyword Aug 6, 2026
@Robertkq Robertkq changed the title [SYCL] Add missing functions & noexcept keyword [SYCL] Align range to SYCL 2020 specs Aug 6, 2026
@Robertkq

Robertkq commented Aug 6, 2026

Copy link
Copy Markdown
Contributor Author

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

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

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe the idea is that all operators for range class should be noexcept. So I vote for adding this specificator if we keep these operators.
could you please dig into commit history and check if there are any clues why these operators were introduced?

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

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Comment thread sycl/include/sycl/range.hpp Outdated

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@KornevNikita KornevNikita Aug 6, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 KornevNikita Aug 6, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@KseniyaTikhomirova KseniyaTikhomirova Aug 7, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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;

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

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>;

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CI uses clang-format-20 Ubuntu package.

From the log:

Setting up clang-format-20 (1:20.1.8~++20250804090239+87f0227cb601-1exp120250804210352.139) ...

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please just revert this code change

@Robertkq
Robertkq marked this pull request as ready for review August 6, 2026 13:08
@Robertkq
Robertkq requested a review from a team as a code owner August 6, 2026 13:08
@Robertkq

Robertkq commented Aug 6, 2026

Copy link
Copy Markdown
Contributor Author

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

@Robertkq

Robertkq commented Aug 6, 2026

Copy link
Copy Markdown
Contributor Author

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

Copy link
Copy Markdown
Contributor

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

Comment thread sycl/include/sycl/range.hpp Outdated

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

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Comment thread sycl/include/sycl/range.hpp Outdated

@KornevNikita KornevNikita Aug 6, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

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>;

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@Robertkq

Copy link
Copy Markdown
Contributor Author

@KornevNikita Hello, sorry for the delay. I was not able to figure out the clang-format at all and from the test failiure, it is not only the last part of the file that does not adhere to the rules. Locally, everything I've tried indicates that the files are formatted correctly. I'm unsure what the next steps would be if the test fails again.

Anyways -- please take a look over the PR. I removed the undocumented and unguarded feature for size_t but I didn't remove the one that is guarded by the macro, can you please confirm if that should be removed or not? Thanks!

@KornevNikita KornevNikita left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can you please confirm if that should be removed or not? Thanks!

According to Sergey's comment above we can remove the #else branch of the __SYCL_DISABLE_ID_TO_INT_CONV__ macro and keep the code under the macro as default.

UPD. probably let's not do it for now, I need to investigate a bit.

Comment thread sycl/include/sycl/range.hpp Outdated
@@ -68,10 +69,12 @@ template <int Dimensions = 1> class range : public detail::array<Dimensions> {
range<Dimensions> &operator=(range<Dimensions> &&rhs) = default;
range() = default;

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
range() = default;
range() noexcept = default;

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

added

@Robertkq

Copy link
Copy Markdown
Contributor Author

@KornevNikita Is there any chance you can checkout my branch and apply the necessary formatting chances and push a commit? I can't get it to work at all..

Also, on a sidenote, is there a certain reason why CI would use clang-format version 20.x.x? It's quite a bit old and I'm pretty sure we compile clang-format or could compile format from LLVM?

Anyways -- would really appreciate if you or anyone else with some free time could apply the formatting changes to me and push to this branch, thanks!

@KornevNikita

KornevNikita commented Aug 17, 2026

Copy link
Copy Markdown
Contributor

@KornevNikita Is there any chance you can checkout my branch and apply the necessary formatting chances and push a commit? I can't get it to work at all..

Done. Actually you can just check the workflow output and apply it manually.
Anyway, all I did was - put https://github.com/intel/llvm/blob/sycl/clang/tools/clang-format/git-clang-format to PATH (I'm using ubuntu, so it might be different for win). Ran:

git clang-format d87afb86a0c6ba414e4f6c994df93249504831ce

it's the commit in your branch before your first commit.

Also, on a sidenote, is there a certain reason why CI would use clang-format version 20.x.x? It's quite a bit old and I'm pretty sure we compile clang-format or could compile format from LLVM?

IIUC https://github.com/aminya/setup-cpp is used to install clang-format. I see that https://github.com/llvm/llvm-project/blob/main/.github/workflows/pr-code-format.yml is different, likely we don't sync our workflow with llvm-project, I'll check that.

@Robertkq

Copy link
Copy Markdown
Contributor Author

@KornevNikita Thank you for the commit with format-clang changes, I will keep trying to solve the issue on my side as well.

Can I get workflow approval and reviews on the PR, I believe it is close if not in merge-able state.
@KseniyaTikhomirova kind ping for review as code owner

Also, related to noexpects, I've opened this issue for SYCL-Docs

Thanks!

@Robertkq

Copy link
Copy Markdown
Contributor Author

2 failiures in:
SYCL Pre Commit on Windows / run_prebuilt_e2e_tests (Intel Arc Graphics with Level Zero, ["Windows","arc"]) / Intel Arc Graphics with Level Zero (pull_request)

Basic/alloc_pinned_host_memory.cpp:
#22287 -- Issue is opened for BMG, it passes on BMG but fails on arc, could it be that arc also is affected by sporadic fails on this?

Basic/fill_accessor.cpp:
#19586 -- Same, opened for BMG.

Worth nothing, issues are opened for BMG while jobs fail on arc, also tests make use of range which is modified, but I doubt it's not sporadic fail

If it's suspected that it's not sporadic, can I get a re-run of the jobs? I don't have such hardware or setup to run myself

@KornevNikita KornevNikita left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. @KseniyaTikhomirova could you please take a look? thanks.

@KornevNikita KornevNikita changed the title [SYCL] Align range to SYCL 2020 specs [SYCL] Align range with SYCL 2020 Aug 18, 2026
}

size_t get(int dimension) const {
size_t get(int dimension) const noexcept {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

check_dimension throws exception https://github.com/Robertkq/llvm/blob/fce97a96106612800cf50c2d50db736ab964d259/sycl/include/sycl/detail/array.hpp#L111
that means that it is incorrect just to mark functions calling it as noexcept with the current impl of check_dimension.

return result; \
}
#else
// RFC: remove these as well?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks like comment which should be removed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Align range with SYCL 2020

5 participants