On Fri, Mar 03, 2023 at 10:53:02AM +1100, Michael Ellerman wrote: > Nathan Chancellor <nat...@kernel.org> writes: > > Hi Michael, > > > > Thanks for the workaround and sorry this has come to bite us :/ > > > > On Fri, Mar 03, 2023 at 12:16:56AM +1100, Michael Ellerman wrote: > >> For the -mtune option clang doesn't accept power10/9/8, instead it > >> accepts pwr10/9/8. That will be fixed in future versions of clang, but > >> the kernel must support the clang versions in the wild. > >> > >> So add support for the "pwr" spelling if clang is in use. > >> > >> Reported-by: Nathan Chancellor <nat...@kernel.org> > > > > I think that should actually be > > > > Reported-by: Nick Desaulniers <ndesaulni...@google.com> > > I guess yeah. > > >> BugLink: https://github.com/ClangBuiltLinux/linux/issues/1799 > >> Signed-off-by: Michael Ellerman <m...@ellerman.id.au> > > > > Reviewed-by: Nathan Chancellor <nat...@kernel.org> > > Thanks. > > >> --- > >> arch/powerpc/platforms/Kconfig.cputype | 4 ++++ > >> 1 file changed, 4 insertions(+) > >> > >> Need to confirm the clang <= 16 statement is correct. > > > > Currently, this is indeed the case. It is possible that Nemanja's patch > > will get applied to release/16.x before 16.0.0 final but it might not. > > > > We can always update it later. I think we do want to push to get that > > patch applied because I forgot that it is only in 16.0.0 that '-mtune' > > starts to do something on PowerPC: > > > > https://github.com/llvm/llvm-project/commit/1dc26b80b872a94c581549a21943756a8c3448a3 > > > > Prior to that change, '-mtune' was accepted but did nothing. It is only > > once it was hooked up to the backend that we got the spew of warnings. I > > think that warrants us trying to get Nemanja's patch into 16.0.0, which > > may allow us to drop this workaround altogether... > > Aha OK, I missed that the warning was new in 16. > > I'll sit on this for now then until we know if that change will make it > into clang 16.
It was merged into release/16.x a few hours ago: https://github.com/llvm/llvm-project/issues/61128 https://github.com/llvm/llvm-project/commit/9b2e09e9fb1aa3bbe3668d7cc585188a3014d1b9 So I think this particular workaround is no longer needed :) Cheers, Nathan