On Fri, 2024-02-09 at 00:02 +0800, chenglulu wrote: > > 在 2024/2/7 上午12:23, Xi Ruoyao 写道: > > Hi Lulu, > > > > I'm proposing to backport r14-4674 "LoongArch: Delete macro definition > > ASM_OUTPUT_ALIGN_WITH_NOP." to releases/gcc-12 and releases/gcc-13. The > > reasons: > > > > 1. Strictly speaking, the old ASM_OUTPUT_ALIGN_WITH_NOP macro may cause > > a correctness issue. For example, a developer may use -falign- > > functions=16 and then use the low 4 bits of a function pointer to encode > > some metainfo. Then ASM_OUTPUT_ALIGN_WITH_NOP causes the functions not > > really aligned to a 16 bytes boundary, causing some breakage. > > > > 2. With Binutils-2.42, ASM_OUTPUT_ALIGN_WITH_NOP can cause illegal > > opcodes. For example: > > > > .globl _start > > _start: > > .balign 32 > > nop > > nop > > nop > > addi.d $a0, $r0, 1 > > .balign 16,54525952,4 > > addi.d $a0, $a0, 1 > > > > is assembled and linked to: > > > > 0000000000000220 <_start>: > > 220: 03400000 nop > > 224: 03400000 nop > > 228: 03400000 nop > > 22c: 02c00404 li.d $a0, 1 > > 230: 00000000 .word 0x00000000 # <== OOPS! > > 234: 02c00484 addi.d $a0, $a0, 1 > > > > Arguably this is a bug in GAS (it should at least error out for the > > unsupported case where .balign 16,54525952,4 appears with -mrelax; I'd > > prefer it to support the 3-operand .align directive even -mrelax for > > reasons I've given in [1]). But we can at least work it around by > > removing ASM_OUTPUT_ALIGN_WITH_NOP to allow using GCC 13.3 with Binutils > > 2.42. > > > > 3. Without ASM_OUTPUT_ALIGN_WITH_NOP, GCC just outputs something like > > ".align 5" which works as expected since Binutils-2.38. > > > > 4. GCC < 14 does not have a default setting of -falign-*, so changing > > this won't affect anyone who do not specify -falign-* explicitly. > > > > [1]:https://github.com/loongson-community/discussions/issues/41#issuecomment-1925872603 > > > > Is it OK to backport r14-4674 into releases/gcc-12 and releases/gcc-13 > > then? > > > Ok, I agree with you. > > Thanks!
Oops, with Binutils-2.41 GAS will fail to assemble some conditional branches if we do this :(. Not sure what to do (maybe backporting both this and a simplified version of PR112330 fix?) Let's reconsider after the holiday... -- Xi Ruoyao <xry...@xry111.site> School of Aerospace Science and Technology, Xidian University
