On 2026-01-16 15:12, Christian Kastner wrote:
Hi Trupti,
On 2026-01-16 10:17, Trupti wrote:
I tested a targeted workaround on ppc64el by disabling HIP client
tests,
while keeping the core rocfft library unchanged. With this change,
rocfft builds and installs successfully on ppc64el.
Given this, would it be acceptable to apply a targeted workaround that
disables HIP client tests on ppc64el, instead of removing the ppc64el
binaries at this stage?
It depends. For example, it's fairly typical to temporarily disable
individual tests, pending upstream resolution.
Could this be an option here? Is the internal compiler error triggered
only on some code paths that could be temporarily be disabled with a
patch, or is this an issue closer to the core?
Disabling all tests would need a good justification, but I'm not sure
it's present here. If the package's own tests fail to build, then I
don't see what good keeping the library would do, as anyone else
building their own code against it would (presumably) run into the same
error.
Another approach could be to force the use of an older LLVM. Cory's
comments on #1118435 [1] seem to suggest that this is possible, by
adding the older LLVM to Build-Depends and adapting d/rules to it.
Though a bit of work, that might actually be the simplest solution to
keeping ppc64el rocblas, hipblas and rocfft.
Best,
Christian
[1]: https://bugs.debian.org/1118435
Hello Christian,
Thank you for the suggestion, and apologies for the delayed response.
I went through Debian bug #1118435, and as suggested, I tried building
rocfft with an older LLVM version (LLVM 19).
With clang-19, the current segmentation fault no longer occurs; however,
it results in the following error:
6.4.3/library/src/device/generator/../kernels/../../../../shared/rocfft_complex.h:34:9:
error: _Float16 is not supported on this target 34 | typedef _Float16
rocfft_fp16; | ^ 1 error generated.
I tried to disable the code that triggers this error but I think I am
missing something
Thanks,
Trupti
