Re: statement expressions and extended asm bug?

[Nathan Sidwell <nathan at codesourcery dot com>]

Gunther Nikl wrote:
> Hello!
>
> The following sample testcase using statement expressions and extended
> asm is treated differently with GCC 2.95.2 and GCC 3.3:
>
> -- cut --
> void foo(int,int);
>
> #define f1() \
> ({ register int _d0 __asm("d0"); \
>    __asm volatile ("moveq #11,d0" : "=r" (_d0) : /**/ : "fp0", "fp1", "cc", "memory"); \
>    _d0; })
>
> #define f2() \
> ({ register int _d0 __asm("d0"); \
>    __asm volatile ("moveq #12,d0" : "=r" (_d0) : /**/ : "fp0", "fp1", "cc", "memory"); \
>    _d0;})
>
> void bar(void) {
>   foo(f1(),f2());
> }
> -- cut --
>
> GCC 2.95.2 generated with -O this:
>
> _bar:	moveq #12,d0
> 	movel d0,sp@-
> 	moveq #11,d0
> 	movel d0,sp@-
> 	jbsr _foo
> 	addql #8,sp
>
> but 3.3 this:
>
> _bar:	moveq #12,d0
> 	moveq #11,d0
> 	movel d0,sp@-
> 	movel d0,sp@-
> 	jbsr _foo
> 	addql #8,sp
>
> GCC 3.3 moves the statement expressions for f1/f2 out of the function call.
> This clobbers the return value of the statement expression. Is that because
> f1/f2 are wrong or because of a GCC bug?
Your code is ill formed.  Ignoring the asm and statement expression syntax for
the moment, it is equivalent to,
  int v;
  foo ((v = 11, v), (v = 12, v));
this violates the sequence point constraints of C.

I suspect if you did not allocate variable _d0 to an explicit register, then
things would behave.

nathan

--
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
nathan@codesourcery.com    ::     http://www.planetfall.pwp.blueyonder.co.uk