>>>> 	../include/LiDIA/kernel/udigit_interface.h:75: warning: ANSI C++ forbids cast to non-reference type used as lvalue
>>> Wow. g++ is totally confused. There's no kind of (C or C++) lvalue
>>> on that line.  It really oughtn't even be doing checks for casting
>>> and such in asm code.
>
>>>> 	__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.)

since you put it that way, i'm not exactly sure what effect the casts
on the "lvalues" is supposed to have...maybe some sort of correctness
of sign extension?

>And sure enough, they're being cast.

so it would seem.

>I think the compiler is exactly right.  What am I missing?

...that the compiler is applying c++ syntax rules to assembly code?

-- 
|-----< "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."