66f4a1399d
When implementing thread_local as a keyword in C23, we accidentally started using C++11 thread_local semantics when using that keyword instead of using C11 _Thread_local semantics. This oversight is fixed by pretending the user wrote _Thread_local instead. This doesn't have the best behavior in terms of diagnostics, but it does correct the semantic behavior. Fixes https://github.com/llvm/llvm-project/issues/70068 Fixes https://github.com/llvm/llvm-project/issues/69167
20 lines
756 B
C
20 lines
756 B
C
// RUN: %clang_cc1 -fsyntax-only -std=c23 %s -verify
|
|
|
|
// Ensure that thread_local and _Thread_local are synonyms in C23 and both
|
|
// restrict local variables to be explicitly static or extern.
|
|
void func(void) {
|
|
// FIXME: it would be nice if the diagnostic said 'thread_local' in this case.
|
|
thread_local int i = 12; // expected-error {{'_Thread_local' variables must have global storage}}
|
|
_Thread_local int j = 13; // expected-error {{'_Thread_local' variables must have global storage}}
|
|
|
|
static thread_local int k = 14;
|
|
static _Thread_local int l = 15;
|
|
|
|
extern thread_local int m;
|
|
extern thread_local int n;
|
|
}
|
|
|
|
// This would previously fail because the tls models were different.
|
|
extern thread_local unsigned a;
|
|
_Thread_local unsigned a = 0;
|