When a statement expression's last statement is an atomic variable, GCC
and Clang disagree on the type of the expression. This can be made
apparent using `typeof` and forcing a diagnostic message:
```cpp
_Atomic int a = 0;
typeof(({a;})) x = "0";
```
* GCC complains about initializing `int` with `char*`
* Clang complains about initializing `_Atomic(int)` with a `char[2]`
Due to the type of the statement expression being deduced to be atomic,
we end with three implicit casts inside the `StmtExpr` on the AST:
* `LValueToRValue` -> `AtomicToNonAtomic` -> `NonAtomicToAtomic`
In some situations, this can end on an assertion inside
`IntExprEvaluator`, as reported in #106576.
With this patch, we now have two implicit casts, since the type of the
statement expression is deduced to be non-atomic:
* `LValueToRValue` -> `AtomicToNonAtomic`
This is consistent with the C standard (6.7.2.4, p4)
> The properties associated with atomic types are meaningful only for
expressions that are lvalues.
But a statement expression is an rvalue.
`IntExprEvaluator` assumptions are now satisfied and there is no
assertion error.
Additionally, the `typeof` trick mentioned above shows that the type is
consistently deduced between GCC and Clang.
Fixes#106576
---------
Co-authored-by: John McCall <rjmccall@gmail.com>