This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: statement expressions and extended asm bug?


On Mon, Mar 15, 2004 at 11:46:30AM +0000, Nathan Sidwell wrote:
> 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.

  That would explain the behaviour. Are you sure that your interpretation
  is right? The documenation says:

    "...allows you to use loops, switches, and local variables within an
     expression."

  This seems to imply your rewrite is wrong.

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

  Thats correct. If I assign the register variable to a non-register
  variable inside the expression, the generated code works as expected.
  However, if I understand you correctly that might be an accident
  nonetheless. Consider the maxint example from the documentation about
  statement expression. Using it twice in a function call should then
  also violate the sequence point constraints of C, shouldn't it?

  Gunther


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]