Hi Cory, Cordell Bloor, on 2022-07-02: > On 2022-06-29 00:09, Étienne Mollier wrote: > > M. Zhou, on 2022-06-28: > > > Shall we bump the version or stay at 5.1.0 for a while? > > > > To my knowledge, there is a slight mix of various versions, > > which may not be the recommended approach, but it seems to work > > okay. I suppose it would be worth at least aligning the > > upstream versions. There is also the compiler support that > > might need to be taken into consideration, but that something > > that will crop up as there will be attempts to build the > > software. > > I think it's fine either way. The mathlibs for ROCm N are often built and > tested with the compiler and runtime from ROCm N-1. The rocm-cmake package > is the only one that _needs_ to be updated to continue working our way up > the dependency tree. Of course, there's still more cleanup to do on > rocm-hipamd [1], and it might not hurt to bump the version while fixing up a > few of those issues. Okay, so I guess the strategy of upgrading from bottom to top is fair, in a similar order as the one packages are integrated into debian. > [1]: It's usable, but has sharp edges. The changes to HIP_COMPILER need to > be removed from 0005-clang-14.patch; changing HIP_CXX_COMPILER should be > sufficient. We also might want to patch --hip-version=<version> directly > into the HIPCFLAGS / HIPCXXFLAGS in hipcc until we can figure out how to get > that info to clang properly. I agree there is room for improvement. At the time of writing that patch, clang-14 was not the default and it was the only way I found to enable use of this particular version. If I only have clang-14 and corresponding toolset installed, then I don't have the unversionned compiler commands, i.e. clang, clang++, and llc, so the checks would fail if left unchanged. Have a nice day, :) -- Étienne Mollier <emollier@emlwks999.eu> Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da Sent from /dev/pts/2, please excuse my verbosity.
Attachment:
signature.asc
Description: PGP signature