On 26/01/2024 07:29, Richard Biener wrote:
On Fri, Jan 26, 2024 at 12:04 AM Tobias Burnus <tbur...@baylibre.com> wrote:When targeting AMD GPUs, the LLVM assembler (and linker) are used. Two days ago LLVM changed the default for the AMDHSA code object version (COV) from 4 to 5. In principle, we do not care which COV is used as long as it works; unfortunately, "mkoffload.cc" also generates an object file directly, bypassing the AMD GPU compiler as it copies debugging data to that file. That object file must have the same COV version (ELF ABI version) as compiler + llvm-mc assembler generated files. In order to ensure those are the same, this patch forces the use of COV 4 instead of using the default. Once GCC requires LLVM >= 14 instead of LLVM >= 13.0.1 we could change it. (Assuming that COV 5 is sufficiently stable in LLVM 14.) - But for now COV 4 will do. If you wonder how this LLVM issue shows up, simply compile any OpenMP or OpenACC program with AMD GPU offloading and enable debugging ("-g"), e.g. gcc -fopenmp -g test.f90 -foffload=amdgcn-amdhsa -foffload-options=-march=gfx908 With LLVM main (to become LLVM 18), you will then get the error: ld: error: incompatible ABI version: /tmp/ccAKx5cz.mkoffload.dbg.o OK for mainline?If you link against prebuilt objects with COV 5 it seems there's no way to override the COV version GCC uses? That is, do we want to add a -mcode-object-version=... option to allow the user to override this (and ABI_VERSION_SPEC honoring that, if specified and of course mkoffload following suit)? Otherwise looks OK in the meantime.
We don't have a stable ABI, so trying to link against foreign binaries is already a problem. Most recently, the SIMD clone implementation required a change to the procedure calling ABI, the reverse-offload changes reimplemented the stack setup, and the low-latency memory patches changed the way we use local memories and needed more info passed into the device runtime. I expect more of this in future.
Compatibility across GCC versions doesn't really exist, and compatibility with LLVM-binaries is a non-starter.
Andrew
