Hello,
On Thu, 29 Jun 2023, Julian Waters via Gcc wrote:
> int main() {
> asm ("nop" "\n"
> "\t" "nop" "\n"
> "\t" "nop");
>
> asm volatile ("nop" "\n"
> "\t" "nop" "\n"
> "\t" "nop");
> }
>
> objdump --disassemble-all -M intel -M intel-mnemonic a.exe > disassembly.txt
>
> 00000001400028c0 <main>:
> 1400028c0: 48 83 ec 28 sub rsp,0x28
> 1400028c4: e8 37 ec ff ff call 140001500 <__main>
> 1400028c9: 90 nop
> 1400028ca: 90 nop
> 1400028cb: 90 nop
> 1400028cc: 31 c0 xor eax,eax
> 1400028cd: 48 83 c4 28 add rsp,0x28
> 1400028ce: c3 ret
>
> Note how there are only 3 nops above when there should be 6, as the first 3
> have been deleted by the compiler. With the patch, the correct 6 nops
> instead of 3 are compiled into the final code.
>
> Of course, the above was compiled with the most extreme optimizations
> available to stress test the possible bug, -O3, -ffunction-sections
> -fdata-sections -Wl,--gc-sections -flto=auto. Compiled as C++17 and intel
> assembly syntax
Works just fine here:
% cat xx.c
int main() {
asm ("nop" "\n"
"\t" "nop" "\n"
"\t" "nop");
asm volatile ("nop" "\n"
"\t" "nop" "\n"
"\t" "nop");
}
% g++ -v
...
gcc version 12.2.1 20230124 [revision
193f7e62815b4089dfaed4c2bd34fd4f10209e27] (SUSE Linux)
% g++ -std=c++17 -flto=auto -O3 -ffunction-sections -fdata-sections xx.c
% objdump --disassemble-all -M intel -M intel-mnemonic a.out
...
0000000000401020 <main>:
401020: 90 nop
401021: 90 nop
401022: 90 nop
401023: 90 nop
401024: 90 nop
401025: 90 nop
401026: 31 c0 xor eax,eax
401028: c3 ret
401029: 0f 1f 80 00 00 00 00 nop DWORD PTR [rax+0x0]
...
Testing with recent trunk works as well with no differences in output.
This is for x86_64-linux.
So, as suspected, something else is broken for you. Which compiler
version are you using? (And we need to check if it's something in the
mingw target)
Ciao,
Michael.
