On 06/02/2025 22:09, Tobias Burnus wrote:
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?
OK.
Andrew
