================
----------------
AaronBallman wrote:
My thinking is because "The evaluations of the operands are unsequenced." means
there's an unsequenced access there, regardless of address computation or not.
Volatile accesses can do *anything*, including writing new values to that
location. Consider a situation where reading the volatile value causes the
system to change the value to zero after the read.
On such a system, the value computations being unsequenced could be an
observable issue. A code example of this might be:
```
extern volatile int v;
extern int *func(int *ip, volatile int value);
int main() {
int i;
*func(&i, v) = v;
}
```
Let's say `v` starts out with value `12` and `func()` returns its first
argument. If the value computation of the LHS happens before RHS, then the read
of `v` will pass the value `12` to `func()` before resetting the value of `v`
to zero, and then `i` will be `0` because of that reset. But if the value
computation of the RHS happens before LHS, then `func` will be passed `0` and
`i` will be `12`.
That said, I think this might be more off in the weeds. I don't insist on a
change here as part of this PR; this is probably better debated in a separate
PR because it's pretty esoteric compared to the other changes in the PR which
are more clearly helpful.
https://github.com/llvm/llvm-project/pull/180955
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
