statement expressions and extended asm bug?

[Gunther Nikl]

On Mon, Mar 15, 2004 at 05:50:36PM +0000, Nathan Sidwell wrote:
> Gunther Nikl wrote:
> >  I tried to give a simplified asm() example. The real asm code has a call
> >  instruction and the called function expects their arguments in certain
> >  registers and returns its result in "d0". To avoid the use of a stub
> >  function, a statement expression+extended asm is used.
> Ideally you want a register class that only contains d0, but I suspect
> there isn't one. Perhaps the following will do what you want,
> 
> inline int foo (int arg_)
> {
>   int result __asm("d0");
>   int arg __asm("d1"); // for sake of argument
> 
>   arg = arg_;
>   asm ("call whereever": "=r(result)" :"r(arg)" : ...);
> 
>   return result;
> }
> 
> This is subtly different from the statement expression form, because
> the result of a C statement expression can be an lvalue, whereas here
> it is an rvalue.

  Initially, inline functions similiar to the above were used. Later there
  was the switch to s-e because parsing many inline functions was slow
  and the parsed functions occupy memory. In contrast when using s-e, the
  "functions" are constructed on demand. This used to be faster and less
  memory hungry than inline functions. Another advantage was that one
  required implict parameter which had to be global before, could now be
  a function local, structure element or function parameter. If possible
  I would like to keep the s-e usage.

> (in g++, statement expressions always produce a result 'as-if' by
> 'return').

  Does that mean with g++ it should work? I just tried with 3.3 and it
  doesn't.

> Perhaps your rewriting of the asm is effectively making the same change.

  AFAICT from the discussion so far, even if it works with the nested
  s-e's, its still wrong.

> Your example is IMHO another case of why statement-exprs should return
> rvalues!

  And then I could use s-e as a function argument as I did?

On Tue, Mar 16, 2004 at 09:12:15AM +0000, Nathan Sidwell wrote:
> Having statement expressions silently extend the lifetime of an lvalue
> declared within is a great way to trip users up.

  Is that "my" problem?

  Gunther