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.
>
