* Segher Boessenkool:
>> I *assumed* that I would still get
>> the value of r0 (the register) from the associated extended asm in this
>> expression, even if it may now be a different register. Your comment
>> made me think that this is undefined.
>
> Please show full(er) examples, I think we are talking about something
> else?
No, I think we are in agreement here how things should behave under the
new model. But I have doubts whether that is implemented in GCC 9.
>> The GCC documentation has this warning:
>>
>> | _Warning:_ In the above example, be aware that a register (for
>> | example 'r0') can be call-clobbered by subsequent code, including
>> | function calls and library calls for arithmetic operators on other
>> | variables (for example the initialization of 'p2').
>
> Yes. This does not matter for the only supported use.
I'm not so sure. See below.
> This is why that *is* the only supported use. The documentation could
> use a touch-up, I think. Unless we still have problems here?
I really don't know. GCC still has *some* support for the old behavior,
though. For example, local register variables are treated as
initialized, and I think you can still use registers like global
variables. GCC does not perform copy propagation here:
int f1 (int);
int
f (void)
{
register int edi __asm__ ("edi");
int edi_copy = edi;
return f1 (1) + edi_copy;
}
And the case that we agreed should be defined in fact is not:
void f1 (int);
int
f (void)
{
register int edi __asm__ ("edi");
asm ("#" : "=r" (edi));
f1 (1);
return edi;
}
On x86-64, %edi is used to pass the first function parameter, so the
call clobbers %edi. It is simply ambiguous whether edi (the variable)
should retain the value prior to the call to f1 (which I think is what
should happen under the new model, where register variables are only
affect asm operands), or if edi (the variable) should have the value of
%edi (the register) after the call (the old model).
Should we move this to the gcc list?
Thanks,
Florian
