Debian Bug report logs - #1070446
rocm-hipamd: arm64 FTBFS with glibc 2.38

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Graham Inggs <ginggs@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: rocm-hipamd: arm64 FTBFS with glibc 2.38

Date: Sun, 5 May 2024 13:31:16 +0000

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

Message #10 received at 1070446@bugs.debian.org (full text, mbox, reply):

From: Cordell Bloor <cgmb@slerp.xyz>

To: Graham Inggs <ginggs@debian.org>, 1070446@bugs.debian.org

Cc: debian-glibc@lists.debian.org, pkg-llvm-team@alioth-lists.debian.net

Subject: Re: Bug#1070446: rocm-hipamd: arm64 FTBFS with glibc 2.38

Date: Sun, 5 May 2024 15:02:47 -0600

[Message part 1 (text/plain, inline)]

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

[Message part 2 (text/html, inline)]

[arm64-hip-math-vec.patch (text/x-patch, attachment)]

Message #19 received at 1070446@bugs.debian.org (full text, mbox, reply):

From: Aurelien Jarno <aurel32@debian.org>

To: 1070441@bugs.debian.org, 1070443@bugs.debian.org, 1070444@bugs.debian.org, 1070446@bugs.debian.org

Cc: debian-glibc@lists.debian.org

Subject: FTBFS due to /usr/include/aarch64-linux-gnu/bits/math-vector.h

Date: Mon, 6 May 2024 23:14:51 +0200

control: severity 1070441 important
control: block 1070668 by 1070441
control: severity 1070443 important
control: block 1070668 by 1070443
control: severity 1070444 important
control: block 1070668 by 1070444
control: severity 1070446 important
control: block 1070668 by 1070446


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.

Regards
Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                     http://aurel32.net

Message #24 received at 1070446@bugs.debian.org (full text, mbox, reply):

From: Cordell Bloor <cgmb@slerp.xyz>

To: Graham Inggs <ginggs@debian.org>, 1070446@bugs.debian.org

Cc: debian-glibc@lists.debian.org, pkg-llvm-team@alioth-lists.debian.net

Subject: Re: Bug#1070446: rocm-hipamd: arm64 FTBFS with glibc 2.38

Date: Wed, 15 May 2024 12:56:45 -0600

[Message part 1 (text/plain, inline)]

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

[Message part 2 (text/html, inline)]

Message #31 received at 1070446@bugs.debian.org (full text, mbox, reply):

From: Aurelien Jarno <aurel32@debian.org>

To: 1070446@bugs.debian.org

Subject: rocm-hipamd: arm64 FTBFS with glibc 2.38

Date: Thu, 18 Jul 2024 23:45:02 +0200

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
aurelien@aurel32.net                     http://aurel32.net

Message #36 received at 1070446@bugs.debian.org (full text, mbox, reply):

From: Emanuele Rocca <ema@debian.org>

To: Aurelien Jarno <aurel32@debian.org>, 1070446@bugs.debian.org

Subject: Re: Bug#1070446: rocm-hipamd: arm64 FTBFS with glibc 2.38

Date: Fri, 19 Jul 2024 12:20:43 +0200

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

Send a report that this bug log contains spam.