On Wed, Jan 04, 2023 at 11:36:18AM +0000, Mark Rutland wrote:
On Tue, Jan 03, 2023 at 05:50:00PM +0100, Arnd Bergmann wrote:
quoted
On Tue, Jan 3, 2023, at 17:19, Mark Rutland wrote:
quoted
On Tue, Jan 03, 2023 at 02:03:37PM +0000, Mark Rutland wrote:
quoted
On Tue, Jan 03, 2023 at 01:25:35PM +0000, Mark Rutland wrote:
quoted
On Tue, Dec 20, 2022 at 12:08:16PM +0100, Peter Zijlstra wrote:
quoted
quoted
... makes GCC much happier:
quoted
... I'll go check whether clang is happy with that, and how far back that can
go, otherwise we'll need to blat the high half with a separate constaint that
(ideally) doesn't end up allocating a pointless address register.
Hmm... from the commit history it looks like GCC prior to 5.1 might not be
happy with that, but that *might* just be if we actually do arithmetic on the
value, and we might be ok just using it for memroy effects. I can't currently
get such an old GCC to run on my machines so I haven't been able to check.
gcc-5.1 is the oldest (barely) supported compiler, the minimum was
last raised from gcc-4.9 in linux-5.15. If only gcc-4.9 and older are
affected, we're good on mainline but may still want a fix for stable
kernels.
Yup; I just wanted something that would easily backport to stable, at least as
far as linux-4.9.y (where I couldn't find the minimum GCC version when I looked
yesterday).
I'd missed that we backported commit:
dca5244d2f5b94f1 ("compiler.h: Raise minimum version of GCC to 5.1 for arm64")
... all the way back to v4.4.y, so we can assume v5.1 even in stable.
The earliest toolchain I could get running was GCC 4.8.5, and that was happy
with the __uint128_t cast for the asm,
Looking back through the history, the reason for the GCC 5.1 check was that
prior to GCC 5.1 GCC would output library calls for arithmetic on 128-bit
types, as noted in commit:
fb8722735f50cd51 ("arm64: support __int128 on gcc 5+")
... but since we're not doing any actual manipulation of the value, that should
be fine.
I'll go write a commit message and send that out as a fix.
quoted
I checked that the cross-compiler binaries from [1] still work, but I noticed
that this version is missing the native aarch64-to-aarch64 compiler (x86 to
aarch64 and vice versa are there), and you need to install libmpfr4 [2]
as a dependency. The newer compilers (6.5.0 and up) don't have these problems.
I was trying the old kernel.org crosstool binaries, but I was either missing a
library (or I have an incompatible version) on my x86_64 host. I'll have
another look today -- thanks for the pointers!
It turns out I'd just missed that at some point the prefix used by the
kernel.org cross compilers changed from:
aarch64-linux-gnu-
to:
aarch64-linux-
... and I'd become so used to the latter that I was trying to invoke a binary
that didn't exist. With the older prefix I could use the kernel.org GCC 4.8.5
without issue.
Thanks,
Mark.