Faulty behavior regarding const expressions in assembly

[xen0n]

Minimized reproducer:

foo:
andi $a0, $a0, (0+(((~((0)))-(((1))<<(0))+1)&(~((0))>>(64-1-(9)))))

This is typical code pattern expanded from Linux's GENMASK(h, l) macro generating bitfield constants.

This breaks with current binutils-gdb main branch:

$ loongarch64-unknown-linux-gnu-gcc -c -o foo.o foo.s
foo.s: Assembler messages:
foo.s:2: Fatal error: Immediate overflow.
format: u10:12
arg: (0+(((~((0)))-(((1))<<(0))+1)&(~((0))>>(64-1-(9)))))

While the LLVM integrated assembler works:

$ clang-16 --target=loongarch64 -fintegrated-as -c -o foo.o foo.s
$ loongarch64-unknown-linux-gnu-objdump -d foo.o

foo.o:     file format elf64-loongarch


Disassembly of section .text:

0000000000000000 <foo>:
   0:   034ffc84        andi            $a0, $a0, 0x3ff

[xen0n]

I've looked into this and unfortunately it seems a difficult one: the LoongArch expressions are evaluated with custom rules defined in gas/config/loongarch-parse.y, and >> is explicitly defined to arithmetically right shift. I tried to stick a plain my_getExpression inside loongarch_parse_expr's constant-value-result branch but it breaks a number of test cases; I'm not sure if any code in the wild is depending on the previous behavior, in which case this might be impossible to fix without breakage.

However, given LLVM has the intended behavior (hence users may already have to face behavioral differences), we may be able to break compatibility a little bit here in favor of doing things right. Opinions, folks?

[xry111]

The GAS manual says:

 ‘>>’
      “Shift Right”.  Same as the C operator ‘>>’.

But it's implementation-defined unspecified whether C operator '>>' should do signed extension or zero extension for signed integer types. Maybe we should add a new switch to control the behavior?