dw <limegreenso...@yahoo.com> writes:
>> asm ("" : "=m" (*x), "=r" (y));
>>
>> you have to assume that the address in %0 might use the same register as %1
>
> Ok, now I'm getting there. It helps that I've compiled some examples
> and can see what is happening. This one is subtle. I'm going to have
> to go back and review my code to see if I've ever done this.
>
> So, the existing text (which only talks about overlaps with input
> parameters) reads:
>
> "Unless an output operand has the '&' constraint modifier (see
> Modifiers), GCC may allocate it in the same register as an unrelated
> input operand, on the assumption that the assembler code will consume
> its inputs before producing outputs. This assumption may be false if the
> assembler code actually consists of more than one instruction. In this
> case, use '&' for each output operand that must not overlap an input."
>
> I'm thinking about adding something like this after it:
>
> "The same problem can occur if one of the output parameters allows a
> register constraint and contains an address. In this case, GCC may use
maybe "...and another output parameter contains..."? Filtering that
through:
> the same register for this parameter as it does for other output
> parameters that allow a memory constraint. This can produce
> inconsistent results if the register address is updated before updating
> the memory address. Combining the '&' constraint with the register
> constraint prevents this overlap and resolves the inconsistency."
>
> That's as clear as I can come up with. Better?
how about:
The same problem can occur if one output parameter @var{a} allows a register
constraint and another output parameter @var{b} allows a memory constraint.
The memory address in @var{b} may contain registers and GCC treats those
registers as inputs to the asm. As above, GCC assumes that such input
registers are consumed before any outputs are written. If in fact the
asm writes to @var{a} before @var{b}, it may inadvertently change the
address used for @var{b}. Combining the '&' constraint with the register
constraint prevents this overlap and ensures that @var{a} and @var{b}
can be written in either order.
Not sure that's much good though, sorry.
Thanks,
Richard
