ROCm 6.3.2 does not like my patch for reasons that I do not understand;
https://gcc.gnu.org/pipermail/gcc-patches/2025-February/675200.html

Until that's sorted, I decided to split off two obvious fixes;
I might suggest some further changes, but the full patch has to
wait until generic really works.

* * *

The attached patch adds '...' to the device macro to avoid touching
this when adding new fields.

And it fixes an issue with gfx906, which shows up when compiling,
e.g. as
  gcc -g -fopenmp -foffload-options=amdgcn-amdhsa=-march=gfx906 file.c
(with offloading code in file.c).

The reason is that '-g' causes mkoffload.cc to create a .o file with
debugging symbols - and that .o file is linked with the GCN device
files. While that file does not contain executable code, the ELF
header still needs to match the GCN .o files as otherwise the linker
complains that there is a mismatch. For the line above, it complains
about: "ld: error: incompatible sramecc: /tmp/ccLhwZle.o".

And in line with the GCC 14 code in mkoffload.cc and with the entries
in https://llvm.org/docs/AMDGPUUsage.html#amdgpu-processor-table for
gfx906 + the llvm-mc / lld implementation, that means that the sramecc
type is 'any' and not unsupported.

OK for mainline?

Tobias
[gcn] Fix gfx906's sramecc setting

When compiling with -g, mkoffload.cc creates a device object file itself;
however, in order that the linker dos not complain, the ELF flags must
match what the compiler / linker does. For gfx906, the assembler defaults
to sramecc = any, but gcn-devices.def contained unsupported, which is not
the same - causing link errors. That's a regression caused by commit
r15-4540-ga6b26e5ea09779 - which can be best seen by looking at the
changes to mkoffload.cc.

Additionally, this commit adds '...' to the GCN_DEVICE #define in gcn.cc
to make it agnostic to the addition of fields.

 gcc/config/gcn/gcn-devices.def | 2 +-
 gcc/config/gcn/gcn.cc          | 3 ++-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/gcc/config/gcn/gcn-devices.def b/gcc/config/gcn/gcn-devices.def
index 7d47a7b495d..a8b21a358b4 100644
--- a/gcc/config/gcn/gcn-devices.def
+++ b/gcc/config/gcn/gcn-devices.def
@@ -91,7 +91,7 @@ GCN_DEVICE(gfx900, GFX900, 0x2c, ISA_GCN5,
 
 GCN_DEVICE(gfx906, GFX906, 0x2f, ISA_GCN5,
 	   /* XNACK default */ HSACO_ATTR_OFF,
-	   /* SRAM_ECC default */ HSACO_ATTR_UNSUPPORTED,
+	   /* SRAM_ECC default */ HSACO_ATTR_ANY,
 	   /* WAVE64 mode */ HSACO_ATTR_UNSUPPORTED,
 	   /* CU mode */ HSACO_ATTR_UNSUPPORTED,
 	   /* Max ISA VGPRs */ 256,
diff --git a/gcc/config/gcn/gcn.cc b/gcc/config/gcn/gcn.cc
index 4200cfaf006..82fc6ff1e41 100644
--- a/gcc/config/gcn/gcn.cc
+++ b/gcc/config/gcn/gcn.cc
@@ -101,7 +101,8 @@ static hash_map<tree, int> lds_allocs;
 /* Import all the data from gcn-devices.def.
    The PROCESSOR_GFXnnn should be indices for this table.  */
 const struct gcn_device_def gcn_devices[] = {
-#define GCN_DEVICE(name, NAME, ELF, ISA, XNACK, SRAMECC, WAVE64, CU, VGPRS, GEN_VER,ARCH_FAM) \
+#define GCN_DEVICE(name, NAME, ELF, ISA, XNACK, SRAMECC, WAVE64, CU, VGPRS, \
+		   GEN_VER, ARCH_FAM, ...) \
     {PROCESSOR_ ## NAME, #name, #NAME, ISA, XNACK, SRAMECC, WAVE64, CU, VGPRS, \
      GEN_VER, #ARCH_FAM},
 #include "gcn-devices.def"

Reply via email to