Hi Andrew, Here is a simpler testcase, with the resulting assembly attached below
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 best regards, Julian On Thu, Jun 29, 2023 at 2:46 AM Andrew Pinski <pins...@gmail.com> wrote: > On Wed, Jun 28, 2023 at 8:04 AM Michael Matz <m...@suse.de> wrote: > > > > Hello, > > > > On Wed, 28 Jun 2023, Julian Waters via Gcc wrote: > > > > > On the contrary, code compiled with gcc with or without the applied > patch > > > operates very differently, with only gcc with the applied patch > producing a > > > fully correctly operating program as expected. Even if the above inline > > > assembly blocks never worked due to other optimizations however, the > > > failure mode of the program would be very different from how it fails > now: > > > It should fail noisily with an access violation exception due to > > > the malformed assembly, but instead all the assembly which installs an > > > exception handler never makes it into the final program because with > > > anything higher than -O1 gcc deletes all of it (I have verified this > with > > > objdump too), > > > > Can you please provide a _full_ compilable testcase (preprocessed). What > > Andrew says is (supposed to be) correct: ignoring the other > > problems you're going to see with your asms (even if you make them > > volatile) GCC should not remove any of the asm statements of them. > > > > If something changes when you add 'volatile' by hand then we have another > > problem lurking somewhere, and adding the parser patch might not fully > > solve it (even if it changes behaviour for you). > > By the way I just testcase: > ``` > void f(void) > { > asm("#should be volatile"); > } > ``` > > The produced gimple (via -fdump-tree-gimple=/dev/stdout) is: > ``` > void f () > { > __asm__ __volatile__("#should be volatile"); > } > ``` > > Which is 100% volatile. and I tested all the way back to GCC 4.8.0 and > it was volatile back then too. > So as both Michael and myself have mentioned, we need a full > (compilable) testcase, even if it is for mingw or cygwin, we can > handle those just fine too. > > Thanks, > Andrew > > > > > > > Ciao, > > Michael. >