Bug#1070446: rocm-hipamd: arm64 FTBFS with glibc 2.38
Hi, On 2024-07-18 11:45, Aurelien Jarno wrote: > With glibc 2.39, the revert is not possible anymore, therefore I > rocm-hipamd FTBFS again. I have therefore upgraded the severity to > serious. > > Emanuele Rocca is working on a solution on the upstream LLVM side. In > the meantime we might have to remove the rocm-hipamd arm64 binaries to > let glibc and future rocm-hipamd migrate to testing. The fix made its way into the upstream repo, and I sent it to the llvm-toolchain-17 maintainers for consideration: https://bugs.debian.org/1076578
Bug#1070446: rocm-hipamd: arm64 FTBFS with glibc 2.38
Hi, On 2024-05-06 23:14, Aurelien Jarno wrote: > Dear maintainers, > > glibc 2.38 introduced changes to the bits/math-vector.h file on arm64 in > order to support math vector functions. This unfortunately caused the > FTBFS of your packages. > > The change has been temporarily reverted in version 2.38-8 until a fix > is found, and I have opened #1070668 on the glibc side to track the > issue, with a Cc: to the arm64 porters. > > I am therefore downgrading the bugs to severity important. However this > should not prevent working on a solution to the problem with the arm64 > porters, and depending on the case either at the package level, or at > the upstream glibc/gcc/llvm level. With glibc 2.39, the revert is not possible anymore, therefore I rocm-hipamd FTBFS again. I have therefore upgraded the severity to serious. Emanuele Rocca is working on a solution on the upstream LLVM side. In the meantime we might have to remove the rocm-hipamd arm64 binaries to let glibc and future rocm-hipamd migrate to testing. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
Bug#1070446: rocm-hipamd: arm64 FTBFS with glibc 2.38
On 2024-05-05 15:02, Cordell Bloor wrote: 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. I reached out to the HIP language compiler team and Sam Liu indicated that this is an LLVM responsibility. Quoting Sam, Since HIP is single source program, device compilation is supposed to be able to compile both host and device functions (parse, not necessarily codegen). As such, clang should know builtin types for both device and host target in either device or host compilation. Therefore a proper solution is to let clang define host-specific builtin types for device target so that they can be parsed, but restriction may be added for emitting them in IR. For this specific case, HasAArch64SVETypes may be moved from TargetInfo to TransferrableTargetInfo, so that it is copied from aux target info to target info in device compilation, then those builtin types will be enabled for device target. Sincerely, Cory Bloor
Bug#1070446: rocm-hipamd: arm64 FTBFS with glibc 2.38
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;
Bug#1070446: rocm-hipamd: arm64 FTBFS with glibc 2.38
Source: rocm-hipamd Version: 5.7.1-3 Severity: serious Tags: ftbfs Hi Maintainer 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. Regards Graham [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; | ^ 3 errors generated when compiling for . CMake Error at hipamd/src/CMakeLists.txt:182 (message): Failed to embed PCH
