Some 64bit architectures do not advertise __SIZEOF_INT128__ on all
supported compiler versions. Notably the HPPA64 only started doing
with GCC-11.
Since the per-cpu ops are universally availably, and
this_cpu_{,try_}cmpxchg128() is expected to be available on all 64bit
architectures a wee bodge is in order.
Sadly, while C reverts to memcpy() for assignment of POD types, it does
not revert to memcmp() for for equality. Therefore frob that manually.
Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
---
include/asm-generic/percpu.h | 56 +++++++++++++++++++++++++++++++++++++++++++
include/linux/types.h | 7 +++++
2 files changed, 63 insertions(+)
--- a/include/asm-generic/percpu.h
+++ b/include/asm-generic/percpu.h
@@ -313,6 +313,35 @@ do { \
#define raw_cpu_xchg_8(pcp, nval) raw_cpu_generic_xchg(pcp, nval)
#endif
+#ifndef __SIZEOF_INT128__
+#define raw_cpu_generic_try_cmpxchg_memcmp(pcp, ovalp, nval) \
+({ \
+ typeof(pcp) *__p = raw_cpu_ptr(&(pcp)); \
+ typeof(pcp) __val = *__p, __old = *(ovalp); \
+ bool __ret; \
+ if (!__builtin_memcmp(&__val, &__old, sizeof(pcp))) { \
+ *__p = nval; \
+ __ret = true; \
+ } else { \
+ *(ovalp) = __val; \
+ __ret = false; \
+ } \
+ __ret; \
+})
+
+#define raw_cpu_generic_cmpxchg_memcmp(pcp, oval, nval) \
+({ \
+ typeof(pcp) __old = (oval); \
+ raw_cpu_generic_try_cmpxchg_memcpy(pcp, &__old, nval); \
+ __old; \
+})
+
+#define raw_cpu_cmpxchg128(pcp, oval, nval) \
+ raw_cpu_generic_cmpxchg_memcmp(pcp, oval, nval)
+#define raw_cpu_try_cmpxchg128(pcp, ovalp, nval) \
+ raw_cpu_generic_try_cmpxchg_memcmp(pcp, ovalp, nval)
+#endif
+
#ifndef raw_cpu_try_cmpxchg_1
#ifdef raw_cpu_cmpxchg_1
#define raw_cpu_try_cmpxchg_1(pcp, ovalp, nval) \
@@ -503,6 +532,33 @@ do { \
#define this_cpu_xchg_8(pcp, nval) this_cpu_generic_xchg(pcp, nval)
#endif
+#ifndef __SIZEOF_INT128__
+#define this_cpu_generic_try_cmpxchg_memcmp(pcp, ovalp, nval) \
+({ \
+ bool __ret; \
+ unsigned long __flags; \
+ raw_local_irq_save(__flags); \
+ __ret = raw_cpu_generic_try_cmpxchg_memcmp(pcp, ovalp, nval); \
+ raw_local_irq_restore(__flags); \
+ __ret; \
+})
+
+#define this_cpu_generic_cmpxchg_memcmp(pcp, oval, nval) \
+({ \
+ typeof(pcp) __ret; \
+ unsigned long __flags; \
+ raw_local_irq_save(__flags); \
+ __ret = raw_cpu_generic_cmpxchg_memcmp(pcp, oval, nval); \
+ raw_local_irq_restore(__flags); \
+ __ret; \
+})
+
+#define this_cpu_cmpxchg128(pcp, oval, nval) \
+ this_cpu_generic_cmpxchg_memcmp(pcp, oval, nval)
+#define this_cpu_try_cmpxchg128(pcp, ovalp, nval) \
+ this_cpu_generic_try_cmpxchg_memcmp(pcp, ovalp, nval)
+#endif
+
#ifndef this_cpu_try_cmpxchg_1
#ifdef this_cpu_cmpxchg_1
#define this_cpu_try_cmpxchg_1(pcp, ovalp, nval) \
--- a/include/linux/types.h
+++ b/include/linux/types.h
@@ -13,6 +13,13 @@
#ifdef __SIZEOF_INT128__
typedef __s128 s128;
typedef __u128 u128;
+#else
+#ifdef CONFIG_64BIT
+/* hack for this_cpu_cmpxchg128 */
+typedef struct {
+ u64 a, b;
+} u128 __attribute__((aligned(16)));
+#endif
#endif
typedef u32 __kernel_dev_t;
On Wed, May 31, 2023, at 15:08, Peter Zijlstra wrote:
> Some 64bit architectures do not advertise __SIZEOF_INT128__ on all
> supported compiler versions. Notably the HPPA64 only started doing
> with GCC-11.
I checked the other compilers to be sure that anything else
we support (gcc-5.1 and up) across all 64-bit architectures
does support int128.
It would be nice to have the hack more localized to parisc
and guarded with a CONFIG_GCC_VERSION check so we can kill
it off in the future, once we drop either gcc-10 or parisc
support.
> +#ifndef __SIZEOF_INT128__
> +#define raw_cpu_generic_try_cmpxchg_memcmp(pcp, ovalp, nval) \
> +({ \
> + typeof(pcp) *__p = raw_cpu_ptr(&(pcp)); \
> + typeof(pcp) __val = *__p, __old = *(ovalp); \
> + bool __ret; \
> + if (!__builtin_memcmp(&__val, &__old, sizeof(pcp))) { \
> + *__p = nval; \
> + __ret = true; \
> + } else { \
> + *(ovalp) = __val; \
> + __ret = false; \
> + } \
> + __ret; \
> +})
> +
> +#define raw_cpu_generic_cmpxchg_memcmp(pcp, oval, nval) \
> +({ \
> + typeof(pcp) __old = (oval); \
> + raw_cpu_generic_try_cmpxchg_memcpy(pcp, &__old, nval); \
> + __old; \
> +})
Instead of having this in include/asm-generic under
!__SIZEOF_INT128__, could you just move this into the parisc
files with a compiler version check?
Arnd
On Wed, May 31, 2023 at 04:21:22PM +0200, Arnd Bergmann wrote:
> On Wed, May 31, 2023, at 15:08, Peter Zijlstra wrote:
> > Some 64bit architectures do not advertise __SIZEOF_INT128__ on all
> > supported compiler versions. Notably the HPPA64 only started doing
> > with GCC-11.
>
> I checked the other compilers to be sure that anything else
> we support (gcc-5.1 and up) across all 64-bit architectures
> does support int128.
Oh excellent -- I didn't have sufficient old cross compilers to verify,
hence me not doing what you suggest below.
If HPPA64 really is the only one so affected, then yes, I can move this
hack into arch/parisc.
On Wed, May 31, 2023 at 04:21:22PM +0200, Arnd Bergmann wrote:
> It would be nice to have the hack more localized to parisc
> and guarded with a CONFIG_GCC_VERSION check so we can kill
> it off in the future, once we drop either gcc-10 or parisc
> support.
I vote for dropping parisc -- it's the only 64bit arch that doesn't have
sane atomics.
Anyway, the below seems to work -- build tested with GCC-10.1
---
Subject: parisc/percpu: Work around the lack of __SIZEOF_INT128__
From: Peter Zijlstra <[email protected]>
Date: Tue May 30 22:27:40 CEST 2023
HPPA64 is unique in not providing __SIZEOF_INT128__ across all
supported compilers, specifically it only started doing this with
GCC-11.
Since the per-cpu ops are universally availably, and
this_cpu_{,try_}cmpxchg128() is expected to be available on all 64bit
architectures a wee bodge is in order.
Sadly, while C reverts to memcpy() for assignment of POD types, it does
not revert to memcmp() for for equality. Therefore frob that manually.
Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
---
arch/parisc/include/asm/percpu.h | 77 +++++++++++++++++++++++++++++++++++++++
1 file changed, 77 insertions(+)
--- /dev/null
+++ b/arch/parisc/include/asm/percpu.h
@@ -0,0 +1,77 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ASM_PARISC_PERCPU_H
+#define _ASM_PARISC_PERCPU_H
+
+#include <linux/types.h>
+
+#if defined(CONFIG_64BIT) && CONFIG_GCC_VERSION < 1100000
+
+/*
+ * GCC prior to 11 does not provide __SIZEOF_INT128__ on HPPA64
+ * as such we need to provide an alternative implementation of
+ * {raw,this}_cpu_{,try_}cmpxchg128().
+ *
+ * This obviously doesn't function as u128 should, but for the purpose
+ * of per-cpu cmpxchg128 it might just do.
+ */
+typedef struct {
+ u64 a, b;
+} u128 __attribute__((aligned(16)));
+
+#define raw_cpu_generic_try_cmpxchg_memcmp(pcp, ovalp, nval) \
+({ \
+ typeof(pcp) *__p = raw_cpu_ptr(&(pcp)); \
+ typeof(pcp) __val = *__p, __old = *(ovalp); \
+ bool __ret; \
+ if (!__builtin_memcmp(&__val, &__old, sizeof(pcp))) { \
+ *__p = nval; \
+ __ret = true; \
+ } else { \
+ *(ovalp) = __val; \
+ __ret = false; \
+ } \
+ __ret; \
+})
+
+#define raw_cpu_generic_cmpxchg_memcmp(pcp, oval, nval) \
+({ \
+ typeof(pcp) __old = (oval); \
+ raw_cpu_generic_try_cmpxchg_memcpy(pcp, &__old, nval); \
+ __old; \
+})
+
+#define raw_cpu_cmpxchg128(pcp, oval, nval) \
+ raw_cpu_generic_cmpxchg_memcmp(pcp, oval, nval)
+#define raw_cpu_try_cmpxchg128(pcp, ovalp, nval) \
+ raw_cpu_generic_try_cmpxchg_memcmp(pcp, ovalp, nval)
+
+#define this_cpu_generic_try_cmpxchg_memcmp(pcp, ovalp, nval) \
+({ \
+ bool __ret; \
+ unsigned long __flags; \
+ raw_local_irq_save(__flags); \
+ __ret = raw_cpu_generic_try_cmpxchg_memcmp(pcp, ovalp, nval); \
+ raw_local_irq_restore(__flags); \
+ __ret; \
+})
+
+#define this_cpu_generic_cmpxchg_memcmp(pcp, oval, nval) \
+({ \
+ typeof(pcp) __ret; \
+ unsigned long __flags; \
+ raw_local_irq_save(__flags); \
+ __ret = raw_cpu_generic_cmpxchg_memcmp(pcp, oval, nval); \
+ raw_local_irq_restore(__flags); \
+ __ret; \
+})
+
+#define this_cpu_cmpxchg128(pcp, oval, nval) \
+ this_cpu_generic_cmpxchg_memcmp(pcp, oval, nval)
+#define this_cpu_try_cmpxchg128(pcp, ovalp, nval) \
+ this_cpu_generic_try_cmpxchg_memcmp(pcp, ovalp, nval)
+
+#endif /* !__SIZEOF_INT128__ */
+
+#include <asm-generic/percpu.h>
+
+#endif /* _ASM_PARISC_PERCPU_H */
On 6/1/23 12:14, Peter Zijlstra wrote:
> On Wed, May 31, 2023 at 04:21:22PM +0200, Arnd Bergmann wrote:
>
>> It would be nice to have the hack more localized to parisc
>> and guarded with a CONFIG_GCC_VERSION check so we can kill
>> it off in the future, once we drop either gcc-10 or parisc
>> support.
>
> I vote for dropping parisc -- it's the only 64bit arch that doesn't have
> sane atomics.
Of course I'm against dropping parisc.
> Anyway, the below seems to work -- build tested with GCC-10.1
I don't think we need to care about gcc-10 on parisc.
Debian and Gentoo are the only supported distributions, while Debian
requires gcc-12 to build > 6.x kernels, and I assume Gentoo uses at least
gcc-12 as well.
So raising the gcc limit for parisc only (at least temporarily for now)
should be fine and your workaround below wouldn't be necessary, right?
Helge
> ---
> Subject: parisc/percpu: Work around the lack of __SIZEOF_INT128__
> From: Peter Zijlstra <[email protected]>
> Date: Tue May 30 22:27:40 CEST 2023
>
> HPPA64 is unique in not providing __SIZEOF_INT128__ across all
> supported compilers, specifically it only started doing this with
> GCC-11.
>
> Since the per-cpu ops are universally availably, and
> this_cpu_{,try_}cmpxchg128() is expected to be available on all 64bit
> architectures a wee bodge is in order.
>
> Sadly, while C reverts to memcpy() for assignment of POD types, it does
> not revert to memcmp() for for equality. Therefore frob that manually.
>
> Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
> ---
> arch/parisc/include/asm/percpu.h | 77 +++++++++++++++++++++++++++++++++++++++
> 1 file changed, 77 insertions(+)
>
> --- /dev/null
> +++ b/arch/parisc/include/asm/percpu.h
> @@ -0,0 +1,77 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _ASM_PARISC_PERCPU_H
> +#define _ASM_PARISC_PERCPU_H
> +
> +#include <linux/types.h>
> +
> +#if defined(CONFIG_64BIT) && CONFIG_GCC_VERSION < 1100000
> +
> +/*
> + * GCC prior to 11 does not provide __SIZEOF_INT128__ on HPPA64
> + * as such we need to provide an alternative implementation of
> + * {raw,this}_cpu_{,try_}cmpxchg128().
> + *
> + * This obviously doesn't function as u128 should, but for the purpose
> + * of per-cpu cmpxchg128 it might just do.
> + */
> +typedef struct {
> + u64 a, b;
> +} u128 __attribute__((aligned(16)));
> +
> +#define raw_cpu_generic_try_cmpxchg_memcmp(pcp, ovalp, nval) \
> +({ \
> + typeof(pcp) *__p = raw_cpu_ptr(&(pcp)); \
> + typeof(pcp) __val = *__p, __old = *(ovalp); \
> + bool __ret; \
> + if (!__builtin_memcmp(&__val, &__old, sizeof(pcp))) { \
> + *__p = nval; \
> + __ret = true; \
> + } else { \
> + *(ovalp) = __val; \
> + __ret = false; \
> + } \
> + __ret; \
> +})
> +
> +#define raw_cpu_generic_cmpxchg_memcmp(pcp, oval, nval) \
> +({ \
> + typeof(pcp) __old = (oval); \
> + raw_cpu_generic_try_cmpxchg_memcpy(pcp, &__old, nval); \
> + __old; \
> +})
> +
> +#define raw_cpu_cmpxchg128(pcp, oval, nval) \
> + raw_cpu_generic_cmpxchg_memcmp(pcp, oval, nval)
> +#define raw_cpu_try_cmpxchg128(pcp, ovalp, nval) \
> + raw_cpu_generic_try_cmpxchg_memcmp(pcp, ovalp, nval)
> +
> +#define this_cpu_generic_try_cmpxchg_memcmp(pcp, ovalp, nval) \
> +({ \
> + bool __ret; \
> + unsigned long __flags; \
> + raw_local_irq_save(__flags); \
> + __ret = raw_cpu_generic_try_cmpxchg_memcmp(pcp, ovalp, nval); \
> + raw_local_irq_restore(__flags); \
> + __ret; \
> +})
> +
> +#define this_cpu_generic_cmpxchg_memcmp(pcp, oval, nval) \
> +({ \
> + typeof(pcp) __ret; \
> + unsigned long __flags; \
> + raw_local_irq_save(__flags); \
> + __ret = raw_cpu_generic_cmpxchg_memcmp(pcp, oval, nval); \
> + raw_local_irq_restore(__flags); \
> + __ret; \
> +})
> +
> +#define this_cpu_cmpxchg128(pcp, oval, nval) \
> + this_cpu_generic_cmpxchg_memcmp(pcp, oval, nval)
> +#define this_cpu_try_cmpxchg128(pcp, ovalp, nval) \
> + this_cpu_generic_try_cmpxchg_memcmp(pcp, ovalp, nval)
> +
> +#endif /* !__SIZEOF_INT128__ */
> +
> +#include <asm-generic/percpu.h>
> +
> +#endif /* _ASM_PARISC_PERCPU_H */
On Thu, Jun 1, 2023 at 6:32 AM Helge Deller <[email protected]> wrote:
>
> I don't think we need to care about gcc-10 on parisc.
> Debian and Gentoo are the only supported distributions, while Debian
> requires gcc-12 to build > 6.x kernels, and I assume Gentoo uses at least
> gcc-12 as well.
>
> So raising the gcc limit for parisc only (at least temporarily for now)
> should be fine and your workaround below wouldn't be necessary, right?
This absolutely sounds like the right option. Let's simplify the
problem space by just saying that parisc needs the newer compiler.
Right now we have that "minimum gcc version" in a somewhat annoying
place: it's in the ./scripts/min-tool-version.sh file as a shell
script.
I wonder if we could move the gcc minimum version check into the
Kconfig file instead, and make it easier to let architectures override
the minimum version.
I don't quite know how to do that sanely, though. I don't think we
have a sane way to error out at Kconfig time (except by forcing some
syntax error inside an 'if' statement or something horrendously hacky
like that).
Added Masahiro to the (already overlong) participants list.
Linus
On Thu, Jun 1, 2023 at 10:29 PM Linus Torvalds
<[email protected]> wrote:
>
> On Thu, Jun 1, 2023 at 6:32 AM Helge Deller <[email protected]> wrote:
> >
> > I don't think we need to care about gcc-10 on parisc.
> > Debian and Gentoo are the only supported distributions, while Debian
> > requires gcc-12 to build > 6.x kernels, and I assume Gentoo uses at least
> > gcc-12 as well.
> >
> > So raising the gcc limit for parisc only (at least temporarily for now)
> > should be fine and your workaround below wouldn't be necessary, right?
>
> This absolutely sounds like the right option. Let's simplify the
> problem space by just saying that parisc needs the newer compiler.
>
> Right now we have that "minimum gcc version" in a somewhat annoying
> place: it's in the ./scripts/min-tool-version.sh file as a shell
> script.
>
> I wonder if we could move the gcc minimum version check into the
> Kconfig file instead, and make it easier to let architectures override
> the minimum version.
Currently, it is invoked in the Kconfig time,
but not directly in Kconfig files.
scripts/Kconfig.include
-> scripts/cc-version.sh
-> scripts/min-tool-version.sh
It would be ugly if we wrote the equivalent code
directly in Kconfig files.
>
> I don't quite know how to do that sanely, though. I don't think we
> have a sane way to error out at Kconfig time (except by forcing some
> syntax error inside an 'if' statement or something horrendously hacky
> like that).
The parse stage can fail by $(error-if ) macro, but
the evaluation stage never fails. I think it is a design.
I think checking the compiler version during the parse stage
makes sense given the current situation. The compiler version is
fixed when Kconfig starts. If the compiler is found to be too old,
there is no meaning to proceed.
You suggested to choose a compiler in the Kconfig time:
https://lore.kernel.org/lkml/CAHk-=whdrvCkSWh=BRrwZwNo3=yLBXXM88NGx8VEpP1VTgmkyQ@mail.gmail.com/
When we achieve that, moving the min version to Kconfig files will be
the right thing to do. Then, everything will be evaluated dynamically.
>
> Added Masahiro to the (already overlong) participants list.
>
> Linus
--
Best Regards
Masahiro Yamada
Peter Zijlstra <[email protected]> writes:
> On Thu, Jun 01, 2023 at 12:32:38PM +0200, Helge Deller wrote:
>> On 6/1/23 12:14, Peter Zijlstra wrote:
>> > On Wed, May 31, 2023 at 04:21:22PM +0200, Arnd Bergmann wrote:
>> >
>> > > It would be nice to have the hack more localized to parisc
>> > > and guarded with a CONFIG_GCC_VERSION check so we can kill
>> > > it off in the future, once we drop either gcc-10 or parisc
>> > > support.
>> >
>> > I vote for dropping parisc -- it's the only 64bit arch that doesn't have
>> > sane atomics.
>>
>> Of course I'm against dropping parisc.
>
> :-)
>
>> > Anyway, the below seems to work -- build tested with GCC-10.1
>>
>> I don't think we need to care about gcc-10 on parisc.
>> Debian and Gentoo are the only supported distributions, while Debian
>> requires gcc-12 to build > 6.x kernels, and I assume Gentoo uses at least
>> gcc-12 as well.
>>
>> So raising the gcc limit for parisc only (at least temporarily for now)
>> should be fine and your workaround below wouldn't be necessary, right?
>
> Correct, if you're willing to set minimum GCC version to 11 for parisc
> all is well and this patch can go play in the bit bucket.
It's fine for us in Gentoo, thanks!
On Thu, Jun 01, 2023 at 09:29:18AM -0400, Linus Torvalds wrote:
> Right now we have that "minimum gcc version" in a somewhat annoying
> place: it's in the ./scripts/min-tool-version.sh file as a shell
> script.
Something like so then?
---
Subject: parisc: Raise minimal GCC version
From: Peter Zijlstra <[email protected]>
Date: Fri Jun 2 16:33:54 CEST 2023
With 64bit builds depending on __SIZEOF_INT128__ raise the parisc
minimum compiler version to gcc-11.0.0.
All other 64bit architectures provide this from GCC-5.1.0 (and
probably before), except hppa64 which only started advertising this
with GCC-11.
Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
---
scripts/min-tool-version.sh | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/scripts/min-tool-version.sh
+++ b/scripts/min-tool-version.sh
@@ -17,7 +17,11 @@ binutils)
echo 2.25.0
;;
gcc)
- echo 5.1.0
+ if [ "$SRCARCH" = parisc ]; then
+ echo 11.0.0
+ else
+ echo 5.1.0
+ fi
;;
llvm)
if [ "$SRCARCH" = s390 ]; then
On Fri, Jun 02, 2023 at 04:39:12PM +0200, Peter Zijlstra wrote:
> On Thu, Jun 01, 2023 at 09:29:18AM -0400, Linus Torvalds wrote:
>
> > Right now we have that "minimum gcc version" in a somewhat annoying
> > place: it's in the ./scripts/min-tool-version.sh file as a shell
> > script.
>
> Something like so then?
>
> ---
> Subject: parisc: Raise minimal GCC version
> From: Peter Zijlstra <[email protected]>
> Date: Fri Jun 2 16:33:54 CEST 2023
>
> With 64bit builds depending on __SIZEOF_INT128__ raise the parisc
> minimum compiler version to gcc-11.0.0.
>
> All other 64bit architectures provide this from GCC-5.1.0 (and
> probably before), except hppa64 which only started advertising this
> with GCC-11.
>
> Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
> ---
> scripts/min-tool-version.sh | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> --- a/scripts/min-tool-version.sh
> +++ b/scripts/min-tool-version.sh
> @@ -17,7 +17,11 @@ binutils)
> echo 2.25.0
> ;;
> gcc)
> - echo 5.1.0
> + if [ "$SRCARCH" = parisc ]; then
> + echo 11.0.0
> + else
> + echo 5.1.0
> + fi
> ;;
> llvm)
> if [ "$SRCARCH" = s390 ]; then
I gave this a spin and it looks good to me:
[mark@lakrids:~/src/linux]% usekorg 10.3.0 make ARCH=arm64 CROSS_COMPILE=aarch64-linux- defconfig
HOSTCC scripts/basic/fixdep
HOSTCC scripts/kconfig/conf.o
HOSTCC scripts/kconfig/confdata.o
HOSTCC scripts/kconfig/expr.o
LEX scripts/kconfig/lexer.lex.c
YACC scripts/kconfig/parser.tab.[ch]
HOSTCC scripts/kconfig/lexer.lex.o
HOSTCC scripts/kconfig/menu.o
HOSTCC scripts/kconfig/parser.tab.o
HOSTCC scripts/kconfig/preprocess.o
HOSTCC scripts/kconfig/symbol.o
HOSTCC scripts/kconfig/util.o
HOSTLD scripts/kconfig/conf
*** Default configuration is based on 'defconfig'
#
# configuration written to .config
#
[mark@lakrids:~/src/linux]% usekorg 10.3.0 make ARCH=parisc CROSS_COMPILE=hppa64-linux- generic-64bit_defconfig
***
*** C compiler is too old.
*** Your GCC version: 10.3.0
*** Minimum GCC version: 11.0.0
***
scripts/Kconfig.include:44: Sorry, this C compiler is not supported.
make[1]: *** [scripts/kconfig/Makefile:94: generic-64bit_defconfig] Error 1
make: *** [Makefile:692: generic-64bit_defconfig] Error 2
[mark@lakrids:~/src/linux]% usekorg 11.3.0 make ARCH=parisc CROSS_COMPILE=hppa64-linux- generic-64bit_defconfig
#
# configuration written to .config
#
FWIW:
Tested-by: Mark Rutland <[email protected]>
Mark.
On Fri, Jun 2, 2023 at 10:40 AM Peter Zijlstra <[email protected]> wrote:
>
> Something like so then?
Ack. I think it would be much cleaner if we would have it as part of
the Kconfig file and architectures could just override some
GCC_MIN_VERSION value, but that's not the universe we currently have,
so your patch looks like the best thing to do.
Linus
On June 2, 2023 7:39:12 AM PDT, Peter Zijlstra <[email protected]> wrote:
>On Thu, Jun 01, 2023 at 09:29:18AM -0400, Linus Torvalds wrote:
>
>> Right now we have that "minimum gcc version" in a somewhat annoying
>> place: it's in the ./scripts/min-tool-version.sh file as a shell
>> script.
>
>Something like so then?
>
>---
>Subject: parisc: Raise minimal GCC version
>From: Peter Zijlstra <[email protected]>
>Date: Fri Jun 2 16:33:54 CEST 2023
>
>With 64bit builds depending on __SIZEOF_INT128__ raise the parisc
>minimum compiler version to gcc-11.0.0.
>
>All other 64bit architectures provide this from GCC-5.1.0 (and
>probably before), except hppa64 which only started advertising this
>with GCC-11.
>
>Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
>---
> scripts/min-tool-version.sh | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
>--- a/scripts/min-tool-version.sh
>+++ b/scripts/min-tool-version.sh
>@@ -17,7 +17,11 @@ binutils)
> echo 2.25.0
> ;;
> gcc)
>- echo 5.1.0
>+ if [ "$SRCARCH" = parisc ]; then
>+ echo 11.0.0
>+ else
>+ echo 5.1.0
>+ fi
> ;;
> llvm)
> if [ "$SRCARCH" = s390 ]; then
Dumb question: is this only about the cpp macro or is it about __int128 existing at all?
On Fri, Jun 02, 2023 at 10:00:17AM -0700, H. Peter Anvin wrote:
> Dumb question: is this only about the cpp macro or is it about __int128 existing at all?
It's mostly about __int128 being there, __SIZEOF_INT128__ is just the
way we go about detecting if it's there or not.
Ok. So the patch description needs to be fixed. Otherwise the solution would be far simpler :)
On Fri, Jun 02, 2023 at 12:20:05PM -0700, H. Peter Anvin wrote:
> Ok. So the patch description needs to be fixed. Otherwise the solution would be far simpler :)
"With 64bit builds depending on __SIZEOF_INT128__ to detect the
presence of __int128 raise the parisc minimum compiler version to
gcc-11.0.0."
better?
On Fri, Jun 2, 2023 at 3:40 PM Peter Zijlstra <[email protected]> wrote:
>
> "With 64bit builds depending on __SIZEOF_INT128__ to detect the
> presence of __int128 raise the parisc minimum compiler version to
> gcc-11.0.0."
>
> better?
I'd just say "64-bit targets need the __int128 type, which for pa-risc
means raising the minimum gcc version to 11".
The __SIZEOF_INT128__ part isn't the important part. That's just the symptom.
Linus
On 6/2/23 16:39, Peter Zijlstra wrote:
> On Thu, Jun 01, 2023 at 09:29:18AM -0400, Linus Torvalds wrote:
>
>> Right now we have that "minimum gcc version" in a somewhat annoying
>> place: it's in the ./scripts/min-tool-version.sh file as a shell
>> script.
>
> Something like so then?
>
> ---
> Subject: parisc: Raise minimal GCC version
> From: Peter Zijlstra <[email protected]>
> Date: Fri Jun 2 16:33:54 CEST 2023
>
> With 64bit builds depending on __SIZEOF_INT128__ raise the parisc
> minimum compiler version to gcc-11.0.0.
>
> All other 64bit architectures provide this from GCC-5.1.0 (and
> probably before), except hppa64 which only started advertising this
> with GCC-11.
>
> Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
The patch raises the compiler for 32- and 64-bit parisc builds, but that's OK.
So:
Acked-by: Helge Deller <[email protected]>
Thank you!
Helge
> ---
> scripts/min-tool-version.sh | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> --- a/scripts/min-tool-version.sh
> +++ b/scripts/min-tool-version.sh
> @@ -17,7 +17,11 @@ binutils)
> echo 2.25.0
> ;;
> gcc)
> - echo 5.1.0
> + if [ "$SRCARCH" = parisc ]; then
> + echo 11.0.0
> + else
> + echo 5.1.0
> + fi
> ;;
> llvm)
> if [ "$SRCARCH" = s390 ]; then