[Bug inline-asm/93944] New: Undocumented side effect in operand evaluations

[frederic.recoules@univ-grenoble-alpes.fr]

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.recoules@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?