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
