On 22 January 2014 15:03, Johannes Pfau <nos...@example.com> wrote: > Am Wed, 22 Jan 2014 00:28:32 +0000 > schrieb "Mike" <n...@none.com>: > >> >> "So what's the question, Mike?" I hear you say: >> 1. Is this just one of the consequences of using -O2/-O3, and I >> should just suck it up and deal with it? >> 2. Is this potentially a bug in the GCC backend? >> 3. Is this potentially a bug in GDC or the DMD frontend? >> >> Thanks for the help, >> Mike > > I can only guess, but this looks like another 'volatile' problem. You'd > have to post the ASM of the optimized version somewhere, and probably > the output of -fdump-tree-optimized for the optimized version. > > But anyway, I guess it inlines 'SendCommand' and then thinks you're not > using the message and probably completely optimizes the call away. Then > it sees you're never using message and removes the rest of your code. > If SendCommand was written in D you'd have to mark the target of the > copy volatile (or shared). > > But I'm not sure how this applies to the inline asm though. In C you > have asm volatile, but I never used that. This answer seems to state > that you have to use asm volatile: > http://stackoverflow.com/a/5057270/471401 > > > > So the questions for Iain: > * should we mark all inline ASM blocks as volatile? > * shared can't replace volatile in this case as `shared asm{...}` > isn't valid > * Should we add some GDC specific way to mark extended ASM blocks as > volatile? As DMD doesn't optimize ASM blocks at all there's probably > no need for a standard solution?
We already do (ExtAsmStatement::toIR -> ASM_VOLATILE_P (exp) = 1;) Regards Iain