Skip to content

[SYCL][E2E] Fix -Werror failures in implicitly SPIR only DeviceLib tests #18995

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 5 commits into
base: sycl
Choose a base branch
from

Conversation

Maetveis
Copy link
Contributor

The -fsycl-device-lib-jit-link only has an effect in SPIR compilation so these tests would fail with -Werror for non SPIR targets.

This basically the same as #18985, but also apply it to tests that have UNSUPPORTED: target-amd || target-nvidia. These tests could be enabled for future non-SPIR targets; we should not be assuming that !target-amd && !target-nvidia implies SPIR.

The `-fsycl-device-lib-jit-link` only has an effect in SPIR compilation
so these tests would fail with `-Werror` for non SPIR targets.

This basically the same as intel#18985, but also apply it to tests that have
`UNSUPPORTED: target-amd || target-nvidia`. These tests could be enabled
for future non-SPIR targets we should not be assuming that
`!target-amd && !target-nvidia` implies SPIR.
@Maetveis Maetveis requested a review from a team as a code owner June 16, 2025 14:51
@Maetveis Maetveis requested a review from steffenlarsen June 16, 2025 14:51
@bader
Copy link
Contributor

bader commented Jun 16, 2025

This basically the same as #18985, but also apply it to tests that have UNSUPPORTED: target-amd || target-nvidia. These tests could be enabled for future non-SPIR targets; we should not be assuming that !target-amd && !target-nvidia implies SPIR.

We have REQUIRES: target-spir. Can we use it instead?

@aelovikov-intel
Copy link
Contributor

We have REQUIRES: target-spir. Can we use it instead?

Are you asking me or @Maetveis ?

@bader
Copy link
Contributor

bader commented Jun 16, 2025

We have REQUIRES: target-spir. Can we use it instead?

Are you asking me or @Maetveis ?

The author of the text from the PR description quoted in my comment.

Maetveis added 2 commits June 17, 2025 04:34
…k` appears

Use `%if target-spir` to either conditionally enable the entire run-line
(when the run-line only only differs by adding `-fsycl-device-lib-jit-link`),
or to conditionally enable the `-fsycl-device-lib-jit-link` flag itself
(when there are other differences).
@Maetveis
Copy link
Contributor Author

This basically the same as #18985, but also apply it to tests that have UNSUPPORTED: target-amd || target-nvidia. These tests could be enabled for future non-SPIR targets; we should not be assuming that !target-amd && !target-nvidia implies SPIR.

We have REQUIRES: target-spir. Can we use it instead?

I'd rather not. These tests are not SPIR specific IMO, only -fsycl-device-lib-jit-link is.

@Maetveis
Copy link
Contributor Author

Maetveis commented Jun 17, 2025

%if target-spir works, so I updated the PR to use that in 60ec587


// RUN: %clangxx -fsycl -fsycl-device-lib-jit-link %{mathflags} %s -o %t.out
// RUN: %if !gpu %{ %{run} %t.out %}
// RUN: %if target-spir %{ %{build} -fsycl-device-lib-jit-link %{mathflags} %s -o %t2.out %}
Copy link
Contributor Author

Choose a reason for hiding this comment

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

There's a drive-by fix here: %clangxx -fsycl depends on the default of -fsycl-targets being spir64. %{build} is the same as %clangxx -fsycl %{sycl-target-options %} which is what we want.
Also the two executables were named the same, so in separate build and run mode the second run line one would override the first, so that would be run twice when starting the test run.

Copy link
Contributor

@bader bader left a comment

Choose a reason for hiding this comment

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

Thanks.
This version looks better.
Hopefully we can fix CI issues still applying the approach with conditional run commands.

Co-authored-by: Alexey Bader <[email protected]>
The expansion of `%{build}` already contains the file name of the test
(`%s`), repeating it leads to duplicate symbol errors.
@Maetveis
Copy link
Contributor Author

Maetveis commented Jun 18, 2025

I believe the CI failures are not related to these changes. I see similar failures in other PRs; I opened: #19034

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.

4 participants