You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[clang][Sema] Fix type of an statement expression ending with an atomic type (#119711)
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 <[email protected]>
typeof(({counter;})) y=""; // expected-error-re {{incompatible pointer to integer conversion initializing 'typeof (({{{.*}}}))' (aka 'char') with an expression of type 'char[1]'}}
0 commit comments