> [T]hen 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?

It's a GNU extension.  Note that the message says that ANSI forbids it,
not that it won't work.

I suspect it "works" because the cast-to type is, at the machine level,
the same as the original type (eg, ints and pointers on most ILP32
machines), so the gcc jiggery-pokery described below ends up being a
no-op.

extend.texi says, of casts applied to lvalues,

| A cast is a valid lvalue if its operand is an lvalue.  A simple
| assignment whose left-hand side is a cast works by converting the
| right-hand side first to the specified type, then to the type of the
| inner left-hand side expression.  After this is stored, the value is
| converted back to the specified type to become the value of the
| assignment.

Presumably something similar happens to extended asm output operands.
The extend.texi node "Extended Asm" does say

| If the output expression cannot be directly addressed (for example,
| it is a bit field), your constraint must allow a register.  In that
| case, GNU CC will use the register as the output of the @code{asm},
| and then store that register into the output.

though I don't find any explicit statement of what happens if lvalue
casts are used for output operands.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B