>> >>> 	__asm__ ("addl %5,%1\n\tadcl %3,%0" :
>> >>> 	"=r" ((USItype)( new_carry )), "=&r" ((USItype)( sum )) :
>> 
>> There are two lvalues there: new_carry and sum.  Note that they are
>> *output* operands from the asm.  As extend.texi says, "Output operand
>> expressions must be lvalues".  (The = operand constraint character is
>> not an assignment operator, though likely it was chosen for its
>> similarity to one.  But output operands to extended asm statements
>> function like assignment LHSes even though there is no explicit
>> assignment operator present.)
>> 
>> And sure enough, they're being cast.
>> 
>> I think the compiler is exactly right.  What am I missing?
>
>Um, while I certainly can't argue with that (far more
>knowledgeable) explanation, then does this code work (which it
>apparently does) because:
>
>1. The cast doesn't work and we just get lucky.
>
>OR
>
>2. The cast actually does work, so why worry.
>
>If 2, then why's g++ bitching?

correct.  either way, it seems fine.  at someone else's
recommendation, i turned the macro into a small static inline function
and it seemed to work just as well.  of course...it's not as if i have
an extended test suite for deterministically proving anything of the
sort...

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
andrew@crossbar.com       * "information is power -- share the wealth."