Re: statement expressions and extended asm bug?

[Gunther Nikl <gni at gecko dot de>]

On Thu, Mar 18, 2004 at 08:22:14AM -0500, Hans-Peter Nilsson wrote:
> On Thu, 18 Mar 2004, Gunther Nikl wrote:
> > On Wed, Mar 17, 2004 at 12:32:32PM -0500, Hans-Peter Nilsson wrote:
> > > On Wed, 17 Mar 2004, Gunther Nikl wrote:
> > > > On Wed, Mar 17, 2004 at 10:29:54AM -0500, Hans-Peter Nilsson wrote:
> > > > > On Tue, 16 Mar 2004, Kai Henningsen wrote:
> > > > > > #define f1() \
> > > > > > ({ register int _d0 __asm("d0"); \
> > > > > >    __asm volatile ("moveq #11,d0" : "=r" (_d0) : /**/ : "fp0", "fp1", "cc",
> > > > > > "memory"); \    _d0 + 0; })
> > > > > That *should work*.  It it doesn't, it's a bug.
> > > >   It doesn't change anything with either 3.3[.3], 3.4 and 3.5.
> > > Please file a bug report if you haven't already done so.
> >
> >   There is no PR yet. I can file one but I need to know why the above
> >   (ret + 0) not changing anything is a bug. Its not obvious for me why
> >   this is a bug.
> 
> If there's a sequence point between the uses of that expression,
> then it's a bug.  It there isn't, I'd agree with Nathan(?) that
> it's like an assignment to the same variable in the "parallel"
> paths.

  I think that the discussion concluded that there is no sequence
  point, but see below.

> I forgot now, but didn't you have an example that used two asms
> as above where there was a sequence point, yet the asm in one
> expression spilled over into the other?

  Yes, my example used two macros both having a s-e and an extended
  asm which returned a value in an explicit hardreg. According to
  http://gcc.gnu.org/ml/gcc/2004-03/msg00740.html the example has a
  sequence point violation but it shouldn't have one since s-e are
  intended for use in macros function-like macros.

> It's no stranger than "func (a++, a++)" being undefined.

  I know that this has undefined behavoiur.

> >   FYI, I tried a non-zero add just as test and then it did work.
> >
> >   BTW, what about this?
> >
> >     if (f1() == f2())
> 
> That's not a sequence point, right?

  IMHO, if that is a sequence point violation depends also on how s-e
  should behave.

  Gunther