[intro.execution] p11 Do evaluations of argument expressions occur within the function invocation?

[xmh0511]

Full name of submitter (unless configured in github; will be published with the issue): Jim X

Consider this example:

int f(int i){
    return i;
}
int main(){
    int i = 0;
    auto r = f(i++) + i;
}

GCC reports no warning about unsequenced while Clang does. [intro.execution] p11 says:

When invoking a function f (whether or not the function is inline), every argument expression and the postfix expression designating f are sequenced before every precondition assertion of the function call ([expr.call]), which in turn are sequenced before every expression or statement in the body of f, which in turn are sequenced before every postcondition assertion of the function call.

This wording sounds like the evaluations of argument expressions occur within the function invocation, so their evaluation cannot interleave with those evaluations that don't occur within the function invocation. IIUC, the evaluation of i++ should be indeterminately sequenced with the value computation of the right operand i. However, there is an implementation divergence here.

Suggested Resolution:

[frederick-vs-ja]

GCC reports no warning about unsequenced while Clang does.

There's no real implementation divergence (between GCC and Clang) IIUC. The "actual" divergence is that GCC doesn't enable the warning by default while Clang does. Whether there's a function call doesn't affect this.

• https://godbolt.org/z/qW79Th9bc
• https://godbolt.org/z/jKeqYhh88

[xmh0511]

GCC reports no warning about unsequenced while Clang does.

There's no real implementation divergence (between GCC and Clang) IIUC. The "actual" divergence is that GCC doesn't enable the warning by default while Clang does. Whether there's a function call doesn't affect this.

* https://godbolt.org/z/qW79Th9bc

* https://godbolt.org/z/jKeqYhh88

IIUC, the evaluation of the argument and the evaluation of the right operand i shouldn't be unsequenced according to the current wording.

[safocl]

This effect is described in the provisions of [intro.execution#10].
(Not related to [[intro.execution] p11])

[jensmaurer]

I'm not seeing a rule that would add a sequencing edge between the side effect of "i++" and the read of "i" (for the second occurrence of "i"). The quoted paragraph doesn't do that; it only establishes sequencing edges between the arguments and the stuff inside the called function.

[xmh0511]

I'm not seeing a rule that would add a sequencing edge between the side effect of "i++" and the read of "i" (for the second occurrence of "i"). The quoted paragraph doesn't do that; it only establishes sequencing edges between the arguments and the stuff inside the called function.

The following paragraph(i.e., [intro.execution] p12) says

For each

• function invocation,

F, each evaluation that does not occur within F but is evaluated on the same thread and as part of the same signal handler (if any) is either sequenced before all evaluations that occur within F or sequenced after all evaluations that occur within F;

(emphasize mine)

IIUC, [intro.execution] p11 mentions argument expression, and i++ is that argument expression; therefore, the valuation of i++ should occur within the invocation function f. The right operand i doesn't occur within the invocation function f, hence i++ and i is indeterminately sequenced rather than unsequenced, IIUC.

[safocl]

The following paragraph(i.e., [intro.execution] p12) says

This rule ensures that no evaluation inside a called function can interleave with evaluations that are outside that called function within the same thread of execution.

[xmh0511]

The following paragraph(i.e., [intro.execution] p12) says

This rule ensures that no evaluation inside a called function can interleave with evaluations that are outside that called function within the same thread of execution.

So, do you think i++ is not inside the called function, or do you think f(i++) and i happen in different threads?

[safocl]

So, do you think i++ is not inside the called function, or do you think f(i++) and i happen in different threads?

The evaluation of subexpressions f(i++) and i is performed in an unpredictable order, since they are operands of the "+" operator, the order of evaluation of whose operands is unspecified.

[xmh0511]

So, do you think i++ is not inside the called function, or do you think f(i++) and i happen in different threads?

The evaluation of subexpressions f(i++) and i is performed in an unpredictable order, since they are operands of the "+" operator, the order of evaluation of whose operands is unspecified.

However, [intro.execution] p12 guarantees that all evaluations that occur within the function invocation cannot interleave with other evaluations that do not occur within the function invocation. You can see how this works in #739

[safocl]

However, [intro.execution] p12 guarantees that all evaluations that occur within the function invocation cannot interleave with other evaluations that do not occur within the function invocation. You can see how this works in #739

???

[xmh0511]

However, [intro.execution] p12 guarantees that all evaluations that occur within the function invocation cannot interleave with other evaluations that do not occur within the function invocation. You can see how this works in #739

???

I don't know what the problem is with you? I cited both intro.execution p11 and intro.execution p12 in this issue, and emphasize the wording. Reading all your comments, they are completely irrelevant. In other words, you didn't object to the argument that the evaluations of the argument expressions occur within the function invocation by citing a relevant formal rule, nor did you clarify what these evaluations that occur within a function invocation are.

[safocl]

@xmh0511

I don't know what the problem is with you? I cited both intro.execution p11 and intro.execution p12 in this issue, and emphasize the wording. Reading all your comments, they are completely irrelevant. In other words, you didn't object to the argument that the evaluations of the argument expressions occur within the function invocation by citing a relevant formal rule, nor did you clarify what these evaluations that occur within a function invocation are.

chronology:
my post

The following paragraph(i.e., [intro.execution] p12) says

This rule ensures that no evaluation inside a called function can interleave with evaluations that are outside that called function within the same thread of execution.

you post

So, do you think i++ is not inside the called function, or do you think f(i++) and i happen in different threads?

my post

The evaluation of subexpressions f(i++) and i is performed in an unpredictable order, since they are operands of the "+" operator, the order of evaluation of whose operands is unspecified.

you post

However, [intro.execution] p12 guarantees that all evaluations that occur within the function invocation cannot interleave with other evaluations that do not occur within the function invocation. You can see how this works in #739

[xmh0511]

According to intro.execution p11, I said i++ occurs within the function invocation, and the read of i in the right operand of + does not occur within the function invocation; hence, according to intro.execution p12, they are not unsequenced but indeterminately sequenced. These are my arguments. You didn't prove these arguments false according to the relevant rules.

[safocl]

I assumed, as I see it, that you perceive unspecified subexpression ordering as only possible across different execution threads, since you yourself asked about this when I mentioned the unpredictability of the evaluation order of the "+" operator's operands. Therefore, I stated that the rule you cited from "[intro.execution] p12" means that evaluations within a called function cannot be interrupted by evaluations outside that function.