Skip to content

[SYCL] Warning if use sycl without dynamic C++ RT on Windows #2501

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

Merged

Conversation

v-klochkov
Copy link
Contributor

@v-klochkov v-klochkov commented Sep 21, 2020

With -fsycl switch the dynamic runtime is used.
The patches (#2478, #2480, #2497 implemented that with -fsycl.

Applications using sycl headers and linked with sycl[d].dll must be linked
with dynamic C++ runtime on Windows even if compiled without -fsycl.
This patch adds a compile time warning emitted when wrong C++ runtime is used.

Signed-off-by: Vyacheslav N Klochkov [email protected]

alexbatashev
alexbatashev previously approved these changes Sep 21, 2020
@romanovvlad
Copy link
Contributor

/summary:run

@@ -1,5 +1,3 @@
// RUN: %clangxx %s -o %t1.out -lsycl -I %sycl_include
Copy link
Contributor

Choose a reason for hiding this comment

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

Did we prohibit use of the compile to build C++ code? Otherwise we do not need to remove this code.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This command compiles a test with static C++ RT on Windows, which causes an assert in stl.hpp
(the assert is added in this PR).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Vladimir, Do you have good ideas on how to allow such compilation on Linux (where default C++ RT is dynamic) and not allow on Windows without -fsycl (where default C++ RT is static)?

Copy link
Contributor

Choose a reason for hiding this comment

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

We have OS specific placehoders for OpenCL CPU: https://github.com/intel/llvm/blob/sycl/sycl/test/lit.cfg.py#L144
You can have some general LINUX placeholder to run the compilation only on Linux.

But it is not perfect solution so I will not insist on implementing it.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I did not find any good way to detect if the compilation runs with -fsyntax-only or without it.

@@ -1,4 +1,4 @@
// RUN: %clangxx -fsyntax-only -Xclang -verify %s -I %sycl_include -Xclang -verify-ignore-unexpected=note,warning
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we really need to change this test as it is compile-time check?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The new static_assert at stl.hpp is emitted on Windows when a) user does not use -fsycl and b) when such compilation would potentially lead to linking with static RT.
I will check if there is any difference in compilation macros with/with -fsyntax-only and if that difference usable in stl.hpp to not give an error with -fsyntax-only.

alexbatashev
alexbatashev previously approved these changes Sep 22, 2020
@bader
Copy link
Contributor

bader commented Feb 12, 2021

@v-klochkov, could you resolve merge conflicts and address comments from @romanovvlad, please?

@v-klochkov v-klochkov force-pushed the public_vklochkov_md_stl_static_assert branch from f875ed0 to a132f41 Compare March 26, 2021 18:51
…t -fsycl

With -fsycl switch the dynamic runtime is used.
The patches (intel#2478, intel#2480, intel#2497 implemented that with -fsycl.

This patch adds check that dynamic runtime is used when -fsycl is
not used. That is done by a static_assert in sycl/stl.hpp.

Also, lots of LIT tests had to be changed to comply with the new
requirement (apps must use dynamic C++ RT with use SYCL).

Signed-off-by: Vyacheslav N Klochkov <[email protected]>
@v-klochkov v-klochkov force-pushed the public_vklochkov_md_stl_static_assert branch from a132f41 to 47e9ed2 Compare March 26, 2021 22:20
// which is not guaranteed to work and considered not safe in general.
// Only using same dynamic C++ runtime library for sycl[d].dll and for
// the application using sycl[d].dll is guaranteed to work properly.
inline constexpr bool isMSVCDynamicCXXRuntime() {
Copy link
Contributor

Choose a reason for hiding this comment

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

constexpr implies inline

Suggested change
inline constexpr bool isMSVCDynamicCXXRuntime() {
constexpr bool isMSVCDynamicCXXRuntime() {

kbobrovs
kbobrovs previously approved these changes Mar 29, 2021
Copy link
Contributor

@kbobrovs kbobrovs left a comment

Choose a reason for hiding this comment

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

sycl/test/esimd/vadd.cpp LGTM.

@v-klochkov
Copy link
Contributor Author

3 or 4 failed tests from the Jenkins/Precommit use separate compilation, e.g.:
https://github.com/intel/llvm-test-suite/blob/intel/SYCL/Config/kernel_from_file.cpp
https://github.com/intel/llvm-test-suite/blob/intel/SYCL/DeviceLib/separate_compile_test.cpp

Such usage model caused the hit of the new static_assert (added in this PR).
It might be useful to add "-fsycl-host-only" option (similar to existing "-fsycl-device-only") in long terms if DPC++ keeps supporting separate device/host compilation.

In short terms it makes sense replacing "static_assert()" with '#pragma message()".

@v-klochkov v-klochkov changed the title [SYCL] Check that apps using sycl also use dynamic C++ RT even withou… [SYCL] Warning if use sycl without dynamic C++ RT on Windows Mar 31, 2021
Copy link
Contributor

@alexbatashev alexbatashev left a comment

Choose a reason for hiding this comment

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

LGTM

Copy link
Contributor

@DenisBakhvalov DenisBakhvalov left a comment

Choose a reason for hiding this comment

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

Changes in sycl/test/esimd/vadd.cpp LGTM

@v-klochkov v-klochkov merged commit d4180f4 into intel:sycl Mar 31, 2021
@v-klochkov v-klochkov deleted the public_vklochkov_md_stl_static_assert branch March 31, 2021 17:58
@@ -1,5 +1,4 @@
// TODO ESIMD enable host device under -fsycl
// RUN: %clangxx -I %sycl_include %s -o %t.out -lsycl
// RUN: %clangxx -fsycl %s -o %t.out
Copy link
Contributor

Choose a reason for hiding this comment

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

Sorry for not catching it, but there is a regression for this test. BTW, I'm not sure how it slipped through the CI.
This test fails with:

InvalidFunctionCall: Unexpected llvm intrinsic:
 llvm.genx.local.id.v3i32 [Src: /iusers/dbakhval/github/llvm/llvm-spirv/lib/SPIRV/SPIRVWriter.cpp:2782 false ]

As of today, we still require -fsycl-explicit-simd flag for ESIMD code. I submitted #3457 to fix this.

Copy link
Contributor

Choose a reason for hiding this comment

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

BTW, I'm not sure how it slipped through the CI.

This casts shadow on CI validation and ESIMD feature validation in particular. @DenisBakhvalov, could you investigate why this regression happened, please? Could it be a conflict between commits?

kbenzie pushed a commit to kbenzie/intel-llvm that referenced this pull request Feb 17, 2025
…-patch

[L0] Fixes potential overwrite in ZeEventPoolDesc.pNext
Chenyang-L pushed a commit that referenced this pull request Feb 18, 2025
[L0] Fixes potential overwrite in ZeEventPoolDesc.pNext
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.

7 participants