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 <c...@slerp.xyz> 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;
