handler_mem_op.cpp and buffer_dev_to_dev.cpp tests fail sporadically on cuda #1508
Assignees
Labels
cuda
CUDA back-end
Comments
bader
added a commit
to bader/llvm
that referenced
this issue
Apr 15, 2020
The issue is tracked here: intel#1508 Signed-off-by: Alexey Bader <alexey.bader@intel.com>
bader
added a commit
that referenced
this issue
Apr 15, 2020
The issue is tracked here: #1508 Signed-off-by: Alexey Bader <alexey.bader@intel.com>
|
sycl/test/basic_tests/buffer/buffer_dev_to_dev.cpp is disabled by #1526. |
bader
added a commit
to bader/llvm
that referenced
this issue
Apr 16, 2020
The issue is tracked here: intel#1508 Signed-off-by: Alexey Bader <alexey.bader@intel.com>
|
sycl/test/basic_tests/handler/handler_mem_op.cpp is disabled by #1533 |
bader
added a commit
that referenced
this issue
Apr 17, 2020
The issue is tracked here: #1508 Signed-off-by: Alexey Bader <alexey.bader@intel.com>
|
Unchecked yet, but I suspect the following PR (fixing a racecondition when creating buffers before accessing them on device) addresses this issue: #1798 |
|
Should we enable them back and check? |
|
I am currently running and rerunning these tests but am not seeing any fails on my local machine. Enabling them seems to be save or will then fail on other machines so it is clear that more investigation is necessary. I will create PR to re-enable the tests. |
|
PR to re-enable these LIT tests for CUDA: #1843 |
iclsrc
pushed a commit
that referenced
this issue
Jun 6, 2024
Some of the upstream PRs are getting backported to the llvm_release_* branches, but those changes are never released. That prevents them from distributing as precompiled packages in various distributions like conda-forge and others. This PR targets this issue by creating automated workflow that is triggered once a month and generates automated releases for each such branch if there were changes since last release. This PR Adds workflow to generate releases every month from llvm_release_* branches in the format %llvm_major%.%llvm_minor%.%latest patch version +1%. For example: v18.1.1 v17.0.2 v17.0.1 v14.0.1 etc Release description matches as close as possible to current releases. The only difference is that llvm versions is represented by two numbers, instead of three, because it is impossible to recover exact version. You can check out example of generated versions here (there are few releases from the original proposal): https://github.com/ZzEeKkAa/SPIRV-LLVM-Translator/releases Workflow is set to be triggered once a month. It is also possible to trigger it manually from github actions UI. Merge process Merge the PR to main Trigger workflow manually Note There is no need to backport changes to all branches, since workflow dispatch on schedule basis can be performed only from main branch. Fixes: #1898 Fixes: #1508 Original commit: KhronosGroup/SPIRV-LLVM-Translator@63e89a9a268e5c2
jsji
pushed a commit
that referenced
this issue
Jun 27, 2024
Some of the upstream PRs are getting backported to the llvm_release_* branches, but those changes are never released. That prevents them from distributing as precompiled packages in various distributions like conda-forge and others. This PR targets this issue by creating automated workflow that is triggered once a month and generates automated releases for each such branch if there were changes since last release. This PR Adds workflow to generate releases every month from llvm_release_* branches in the format %llvm_major%.%llvm_minor%.%latest patch version +1%. For example: v18.1.1 v17.0.2 v17.0.1 v14.0.1 etc Release description matches as close as possible to current releases. The only difference is that llvm versions is represented by two numbers, instead of three, because it is impossible to recover exact version. You can check out example of generated versions here (there are few releases from the original proposal): https://github.com/ZzEeKkAa/SPIRV-LLVM-Translator/releases Workflow is set to be triggered once a month. It is also possible to trigger it manually from github actions UI. Merge process Merge the PR to main Trigger workflow manually Note There is no need to backport changes to all branches, since workflow dispatch on schedule basis can be performed only from main branch. Fixes: #1898 Fixes: #1508 Original commit: KhronosGroup/SPIRV-LLVM-Translator@63e89a9a268e5c2
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
sycl/test/basic_tests/handler/handler_mem_op.cpp and sycl/test/basic_tests/buffer/buffer_dev_to_dev.cpp tests fail sporadically on cuda.
Signed-off-by: Aleksander Fadeev aleksander.fadeev@intel.com
The text was updated successfully, but these errors were encountered: