Tags: patch
Hi Graham,
On 2024-05-05 07:31, Graham Inggs wrote:
As can be seen in reproducible builds [1], rocm-hipamd FTBFS on arm64
with glibc 2.38. I've copied what I hope is the relevant part of the
log below.
A bug was filed against glibc [2], but it seems glibc upstream do not
consider it a bug in glibc.
There is nothing that can be done in rocm-hipamd to address this bug,
aside from removing arm64 from the rocm-hipamd architecture list. The
incompatibility is not with the HIP runtime, but with the HIP language.
This is a disagreement that glibc and llvm will need to resolve between
themselves.
[1]https://tests.reproducible-builds.org/debian/rb-pkg/rocm-hipamd.html
[2]https://sourceware.org/bugzilla/show_bug.cgi?id=30909
In file included from /tmp/hip_pch.724714/hip_pch.h:1:
In file included from
/build/reproducible-path/rocm-hipamd-5.7.1/hip/include/hip/hip_runtime.h:62:
In file included from
/build/reproducible-path/rocm-hipamd-5.7.1/hipamd/include/hip/amd_detail/amd_hip_runtime.h:76:
In file included from
/usr/lib/gcc/aarch64-linux-gnu/13/../../../../include/c++/13/cmath:47:
In file included from /usr/include/math.h:40:
/usr/include/aarch64-linux-gnu/bits/math-vector.h:40:9: error: unknown
type name '__SVFloat32_t'
40 | typedef __SVFloat32_t __sv_f32_t;
| ^
/usr/include/aarch64-linux-gnu/bits/math-vector.h:41:9: error: unknown
type name '__SVFloat64_t'
41 | typedef __SVFloat64_t __sv_f64_t;
| ^
/usr/include/aarch64-linux-gnu/bits/math-vector.h:42:9: error: unknown
type name '__SVBool_t'
42 | typedef __SVBool_t __sv_bool_t;
| ^
This compilation error is when building device code when the host
architecture is aarch64. LLVM only defines __SVFloat32_t, __SVFloat64_t
and __SVBool_t when building host code, but not when building device
code. To me this seems reasonable because GPUs do not support SVE
instructions.
However, the math.h header (on aarch64 at least) is not aware of the
concept of the distinction between host code and device code. As such,
it fails when compiling device code. The glibc argument is that GCC
always supports these types, but I'm not convinced. I'm curious how GCC
handles the math headers for OpenMP GPU offloading [3].
In any case, I've attached a patch for glibc that would fix this bug.
Perhaps my suggestion would be more palatable to upstream than the
previously rejected patch. If not, it's up to glibc or LLVM to find a
solution. If they cannot, then we will have to drop arm64 support for
the HIP language.
Sincerely,
Cory Bloor
[3]: https://gcc.gnu.org/wiki/Offloading
From: Cordell Bloor
Date: Wed, 10 Apr 2024 16:49:24 -0600
Subject: [PATCH] arm64/math-vec.h: drop SVE vector types in device code
These headers get included when building HIP libraries on the aarch64
platform. The headers are used when building both CPU code and GPU
code, but the SVE vector types are not supported on the GPU.
The clang compiler sets __HIP_DEVICE_COMPILE__ when it is building
code for the GPU, so disable __SVE_VEC_MATH_SUPPORTED when that macro
is detected.
Bug-Debian: https://bugs.debian.org/1070446
Bug-Ubuntu: https://bugs.launchpad.net/glibc/+bug/2032624
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30909
Forwarded: No
Index: glibc/sysdeps/aarch64/fpu/bits/math-vector.h
===
--- glibc.orig/sysdeps/aarch64/fpu/bits/math-vector.h
+++ glibc/sysdeps/aarch64/fpu/bits/math-vector.h
@@ -101,7 +101,8 @@ typedef __attribute__ ((__neon_vector_ty
typedef __attribute__ ((__neon_vector_type__ (2))) double __f64x2_t;
#endif
-#if __GNUC_PREREQ(10, 0) || __glibc_clang_prereq(11, 0)
+#if (__GNUC_PREREQ(10, 0) || __glibc_clang_prereq(11, 0)) \
+ && !defined(__HIP_DEVICE_COMPILE__)
# define __SVE_VEC_MATH_SUPPORTED
typedef __SVFloat32_t __sv_f32_t;
typedef __SVFloat64_t __sv_f64_t;
