This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: statement expressions and extended asm bug?
Gunther Nikl wrote:
On Mon, Mar 15, 2004 at 03:54:43PM +0000, Nathan Sidwell wrote:
Gunther Nikl wrote:
On Mon, Mar 15, 2004 at 03:20:08PM +0000, Nathan Sidwell wrote:
If you are asking whether
({int i; int j __asm__("d0"); volatile asm ("..." : "=r"(j)...); i = j;
i;})
will DTRT, the answer is no.
I was considering writing it like this:
({ int i = \
({int j __asm__("d0"); volatile asm ("..." : "=r"(j)...); j;}); \
i; \
})
This seems to work with 3.3+.
that is equivalent to my example, the code still looks like it is undefined.
Argh! :-( In that case it "works" now by chanceonly, right?
see below
Why must you assign j to register d0?
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. (in g++, statement expressions always produce a result
'as-if' by 'return').
Perhaps your rewriting of the asm is effectively making the
same change. Your example is IMHO another case of why
statement-exprs should return rvalues!
nathan
--
Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery LLC
nathan@codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk