* [PATCH kvm-unit-tests] arm64: Fix compiling with ancient compiler
@ 2022-02-01 19:01 Andrew Jones
2022-02-02 5:19 ` Thomas Huth
0 siblings, 1 reply; 3+ messages in thread
From: Andrew Jones @ 2022-02-01 19:01 UTC (permalink / raw)
To: kvm; +Cc: pbonzini, thuth
When compiling with an ancient compiler (gcc-4.8.5-36.el7_6.2.aarch64)
the build fails with
lib/libcflat.a(alloc.o): In function `mult_overflow':
/home/drjones/kvm-unit-tests/lib/alloc.c:19: undefined reference to `__multi3'
According to kernel commit fb8722735f50 ("arm64: support __int128 on
gcc 5+") GCC5+ will not emit __multi3 for __int128 multiplication,
so let's just fallback to the non-__int128 overflow check when we
use gcc versions older than 5.
Signed-off-by: Andrew Jones <drjones@redhat.com>
---
lib/alloc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/lib/alloc.c b/lib/alloc.c
index f4266f5d064e..70228aa32c6c 100644
--- a/lib/alloc.c
+++ b/lib/alloc.c
@@ -1,6 +1,7 @@
#include "alloc.h"
#include "asm/page.h"
#include "bitops.h"
+#include <linux/compiler.h>
void *malloc(size_t size)
{
@@ -13,7 +14,7 @@ static bool mult_overflow(size_t a, size_t b)
/* 32 bit system, easy case: just use u64 */
return (u64)a * (u64)b >= (1ULL << 32);
#else
-#ifdef __SIZEOF_INT128__
+#if defined(__SIZEOF_INT128__) && (!defined(__aarch64__) || GCC_VERSION >= 50000)
/* if __int128 is available use it (like the u64 case above) */
unsigned __int128 res = a;
res *= b;
--
2.34.1
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH kvm-unit-tests] arm64: Fix compiling with ancient compiler
2022-02-01 19:01 [PATCH kvm-unit-tests] arm64: Fix compiling with ancient compiler Andrew Jones
@ 2022-02-02 5:19 ` Thomas Huth
2022-02-02 8:06 ` Andrew Jones
0 siblings, 1 reply; 3+ messages in thread
From: Thomas Huth @ 2022-02-02 5:19 UTC (permalink / raw)
To: Andrew Jones, kvm; +Cc: pbonzini
On 01/02/2022 20.01, Andrew Jones wrote:
> When compiling with an ancient compiler (gcc-4.8.5-36.el7_6.2.aarch64)
> the build fails with
>
> lib/libcflat.a(alloc.o): In function `mult_overflow':
> /home/drjones/kvm-unit-tests/lib/alloc.c:19: undefined reference to `__multi3'
>
> According to kernel commit fb8722735f50 ("arm64: support __int128 on
> gcc 5+") GCC5+ will not emit __multi3 for __int128 multiplication,
> so let's just fallback to the non-__int128 overflow check when we
> use gcc versions older than 5.
>
> Signed-off-by: Andrew Jones <drjones@redhat.com>
> ---
> lib/alloc.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/lib/alloc.c b/lib/alloc.c
> index f4266f5d064e..70228aa32c6c 100644
> --- a/lib/alloc.c
> +++ b/lib/alloc.c
> @@ -1,6 +1,7 @@
> #include "alloc.h"
> #include "asm/page.h"
> #include "bitops.h"
> +#include <linux/compiler.h>
>
> void *malloc(size_t size)
> {
> @@ -13,7 +14,7 @@ static bool mult_overflow(size_t a, size_t b)
> /* 32 bit system, easy case: just use u64 */
> return (u64)a * (u64)b >= (1ULL << 32);
> #else
> -#ifdef __SIZEOF_INT128__
> +#if defined(__SIZEOF_INT128__) && (!defined(__aarch64__) || GCC_VERSION >= 50000)
> /* if __int128 is available use it (like the u64 case above) */
> unsigned __int128 res = a;
> res *= b;
I'd also be OK if we'd simply declare GCC compiler versions < 5 as
unsupported ... but since it's an easy fix:
Acked-by: Thomas Huth <thuth@redhat.com>
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH kvm-unit-tests] arm64: Fix compiling with ancient compiler
2022-02-02 5:19 ` Thomas Huth
@ 2022-02-02 8:06 ` Andrew Jones
0 siblings, 0 replies; 3+ messages in thread
From: Andrew Jones @ 2022-02-02 8:06 UTC (permalink / raw)
To: Thomas Huth; +Cc: kvm, pbonzini
On Wed, Feb 02, 2022 at 06:19:46AM +0100, Thomas Huth wrote:
> On 01/02/2022 20.01, Andrew Jones wrote:
> > When compiling with an ancient compiler (gcc-4.8.5-36.el7_6.2.aarch64)
> > the build fails with
> >
> > lib/libcflat.a(alloc.o): In function `mult_overflow':
> > /home/drjones/kvm-unit-tests/lib/alloc.c:19: undefined reference to `__multi3'
> >
> > According to kernel commit fb8722735f50 ("arm64: support __int128 on
> > gcc 5+") GCC5+ will not emit __multi3 for __int128 multiplication,
> > so let's just fallback to the non-__int128 overflow check when we
> > use gcc versions older than 5.
> >
> > Signed-off-by: Andrew Jones <drjones@redhat.com>
> > ---
> > lib/alloc.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/lib/alloc.c b/lib/alloc.c
> > index f4266f5d064e..70228aa32c6c 100644
> > --- a/lib/alloc.c
> > +++ b/lib/alloc.c
> > @@ -1,6 +1,7 @@
> > #include "alloc.h"
> > #include "asm/page.h"
> > #include "bitops.h"
> > +#include <linux/compiler.h>
> > void *malloc(size_t size)
> > {
> > @@ -13,7 +14,7 @@ static bool mult_overflow(size_t a, size_t b)
> > /* 32 bit system, easy case: just use u64 */
> > return (u64)a * (u64)b >= (1ULL << 32);
> > #else
> > -#ifdef __SIZEOF_INT128__
> > +#if defined(__SIZEOF_INT128__) && (!defined(__aarch64__) || GCC_VERSION >= 50000)
> > /* if __int128 is available use it (like the u64 case above) */
> > unsigned __int128 res = a;
> > res *= b;
>
> I'd also be OK if we'd simply declare GCC compiler versions < 5 as
> unsupported ... but since it's an easy fix:
I'd like to continue supporting this particular old compiler, because I
only have one machine where I can run the unit tests with KVM AArch32,
and on that machine I still have an old RHEL (RHEL7-Alt) installed. If
it gets too difficult to support, then I'll try upgrading that machine's
RHEL version or at least its compiler version.
>
> Acked-by: Thomas Huth <thuth@redhat.com>
>
Thanks, but I need a v2 since I just remembered clang. For v2, I see two
options:
1) Just change the line as below and hope we don't need to worry about
clang versions
#if defined(__SIZEOF_INT128__) && (!defined(__aarch64__) || defined(__clang__) || GCC_VERSION >= 50000)
2) Replace lib/alloc.c's mult_overflow() with lib/linux/compiler.h's
check_mul_overflow()
(2) seems like the better choice except for the fact that it lazily
doesn't implement a fallback for compilers which don't support the
builtins (and that's older than GCC7.1). Do we care? Of course I
could combine the two implementations if we really want that fallback
and the cleanup.
Thanks,
drew
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2022-02-02 8:06 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-02-01 19:01 [PATCH kvm-unit-tests] arm64: Fix compiling with ancient compiler Andrew Jones
2022-02-02 5:19 ` Thomas Huth
2022-02-02 8:06 ` Andrew Jones
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.