https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93944
Bug ID: 93944
Summary: Undocumented side effect in operand evaluations
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
Assignee: unassigned at gcc dot gnu.org
Reporter: frederic.recou...@univ-grenoble-alpes.fr
Target Milestone: ---
I would have said that I read somewhere that concurrent side effect in the
operands is an undefined behavior, but, I read the documentation
(Extended-Asm.html) again and I did not see any mention of this.
Here is a simple motivation example, it is the worst I can produce:
int *f (int *v, const char m[])
{
puts(m);
return v;
}
int main (int argc, char * argv[])
{
__asm__ ("leal 1(%2), %0" "\n\t"
"leal 2(%3), %1"
: "=&r" (*f(&argc, "0")),
"=r" (*f(&argc, "1"))
: "r" (*f(&argc, "2")),
"r" (*f(&argc, "3")));
return argc;
}
Here is what I could think for stdout:
- the behavior is totally undefined and the compiler will make demon fly out of
my nose
- inputs are evaluated before outputs (it could make sense) such 2 and 3 always
appear before 0 and 1 but the rest is undefined
- evaluation order is well defined and leads to "0123", the actual result with
gcc 9.2 (but I don't like it)
But also, lvalue argc takes "supposedly" the value of %0 and %1. I would think
it is an undefined behavior that will depend on compiler final register
allocation, it is?
