I know that in some operators, the order of calculation is not defined. Most probably this is the case. So I think, that there is no reversed order, but in this particular case compiler makes the order like this. But if you change code and make for example not two function calls, but 3 , 4 or 5. The order will be others.

Order of evaluation

From cppreference :- Order of evaluation of the operands of almost all C++ operators (including the order of evaluation of function arguments in a function-call expression and the order of evaluation of the subexpressions within any expression) is unspecified. The compiler can evaluate operands in any order, and may choose another order when the same expression is evaluated again.

You should avoid using C++ operators to write an expression whose result depends on the order in which its operands are evaluated.

You can alway use the semicolon statement terminator or the comma operator to specify the order in which a sequence of computational tasks are performed so that no race situation takes place among related operands when the order of evaluation may change the result of an expression or the program behavior in general due to interpdendence.

For example, your code can be rewritten as:

int main() 
{
    int x = 0, x1 = add1( x ), x2 = add2( x );

    cout << x1 << " " << x2 << endl;
	
    return 0;
}

The comma operator in the variable declaration statement instructs the compiler to generate an object code that initializes the sequence of variables x, x1 and x2 in the same order they are declared in the source code, i.e. the generated object code should execute the following ordered sequence of computational tasks:

1. Initialize x to 0.

2. Call add1( x ), and initialize x1 to the return value of such function call.

3. Call add2( x ), and initialize x2 to the return value of such function call.

Finally, the cout << x1 << " " << x2 << endl statement written in terms of the overloaded binary operator << is translated to a sequence of function calls to produce the desired program output functional behavior. In this case, the program output is race free.

The following is the expected result. Further information about race condition in shared-memory applications is available in Wikipedia