https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121394
--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> --- GCN is (sadly) using LLVM as as and ld. That said, this is a GCC bug (at least if it emits the above mentioned assembly). https://refspecs.linuxbase.org/elf/gabi4+/ch4.sheader.html SHF_MERGE The data in the section may be merged to eliminate duplication. Unless the SHF_STRINGS flag is also set, the data elements in the section are of a uniform size. The size of each element is specified in the section header's sh_entsize field. If the SHF_STRINGS flag is also set, the data elements consist of null-terminated character strings. The size of each character is specified in the section header's sh_entsize field. Each element in the section is compared against other elements in sections with the same name, type and flags. Elements that would have identical values at program run-time may be merged. Relocations referencing elements of such sections must be resolved to the merged locations of the referenced values. Note that any relocatable values, including values that would result in run-time relocations, must be analyzed to determine whether the run-time values would actually be identical. An ABI-conforming object file may not depend on specific elements being merged, and an ABI-conforming link editor may choose not to merge specific elements. In non-SHF_STRINGS section, it is essentially an array of sh_entsize sized elements. If it is .section .rodata.cst32,"aM",@progbits,32 with size 56, then it is invalid, it contains one full element (32 bytes long) and 3/4 of another one. If it had size 64 bytes and sh_entsize 32, the linker could very well reorder it, keep a relocation point to the first 32 bytes and then place there any other 32 bytes (from offsets divisible by 32) from the same section.
