Closed kloczek closed 8 months ago
gentle ping .. 🤔
Sorry I missed this earlier. We'll take a look.
This could happen with mismatched compiler and device libs versions. The 16-bit target feature was applied to all the half functions, which would just break any non-legal half targets. The current device libs is free of the 16-bit features and should work on all subtargets. This should work if you use the latest device libs
OK so what exactly it means?
cmake messed something?🤔
OK so what exactly it means? cmake messed something?thinking
This was fixed by 439adec40dbddbe8b0c13c022ffc4eeb12e81b54 (which depended on quite a lot of patches in the library and compiler to avoid dependence on the 16-bit feature)
Do you have any plans to make new release as looks like last one has some issues?
BTW is it possible to change tagging convention from rocm-<version>
to just <version>
? 🤔
Tar ball automatically generated from git tag base directory is assembled from
Do you have any plans to make new release as looks like last one has some issues?
Eventually there will be a new release. You can safely ignore these tests, they're incomplete and currently not run as part of any CI. I've only recently been trying to get the infrastructure for this type of testing going. The point of this test was to show the failure you see does fail, so really it should have been XFAIL to begin with.
BTW is it possible to change tagging convention from
rocm-<version>
to just<version>
? thinking Tar ball automatically generated from git tag base directory is assembled from -`.
Not sure, I would hope this would be consistent across all rocm projects
Eventually there will be a new release. You can safely ignore these tests, they're incomplete and currently not run as part of any CI. I've only recently been trying to get the infrastructure for this type of testing going. The point of this test was to show the failure you see does fail, so really it should have been XFAIL to begin with.
So this issue affects only test suite and not actual generated bytecode? 🤔
Not sure, I would hope this would be consistent across all rocm projects
I understand.
Eventually there will be a new release. You can safely ignore these tests, they're incomplete and currently not run as part of any CI. I've only recently been trying to get the infrastructure for this type of testing going. The point of this test was to show the failure you see does fail, so really it should have been XFAIL to begin with.
So this issue affects only test suite and not actual generated bytecode? thinking
It shows half was broken on antique targets which don't have native half support. For OpenCL clang wouldn't report the half extension as available, so an ordinary use wouldn't run into this
FWIW, every compiled device code uses at least some of the library byte code. The release can't happen without it working properly.
Just tested 5.7.0 and looks like now test suite is failing in 3 units
BTW: why .bc files are installed in $(prefix)/amdgcn/bitcode/
directory?
Are you sure that this is correct location? (is it should not be somewhere under $(libdir)? 🤔
Just tested 5.7.1 an test suite still fails in the same 3 units. Any update about install path of .bc files? 🤔
.bc files are installed into clang resource dir (
I'd suggest checking device-libs tests in 6.0, when it becomes available publicly.
Just checked 6.0.0 and all .bc files are still installed in the same path. Test suite fails in the same 3 units as well.
Just tested 5.7.1 an test suite still fails in the same 3 units. Any update about install path of .bc files? 🤔
All tests should now pass as of https://github.com/ROCm/llvm-project/commit/794ebeffcafbf6f4d86cb1bfd7a5a0d1d30f1fc7
BTW: why .bc files are installed in
$(prefix)/amdgcn/bitcode/
directory? Are you sure that this is correct location? (is it should not be somewhere under $(libdir)? 🤔
This has been an endless source of debate; they should be moving to the clang resource directory
Closing since the tests should now be passing, and this repository is closed and should be archived. The new location is under ROCm/llvm-project
Looks like something is wrong and test suite is failing in two units
I'm using LLVM 16.0.6. I'm not sure what more I should provide as details about my build env.