macos-arm64: _Thread_local not implemented

[quaesitor-scientiam]

Describe the bug

The thirdparty-macos-arm64 tcc build rejects the C11 _Thread_local storage-class specifier with error: _Thread_local is not implemented, even though it's valid ISO C11 and other tcc targets (and every other C compiler V supports) accept it.

This currently breaks v self on Apple Silicon macOS in the main V repo, since V's -prealloc allocator emits a _Thread_local global — see vlang/v#28023 and the fix in vlang/v#28024 (which works around it on the V side by avoiding tcc whenever _Thread_local would be emitted, but the underlying tcc limitation remains).

Reproduction Steps

// repro.c
_Thread_local int g_x;

int main(void) {
    g_x = 1;
    return g_x - 1;
}

$ ./tcc.exe -o repro repro.c
repro.c:1: error: _Thread_local is not implemented

Expected Behavior

_Thread_local (and ideally the C11 thread_local alias) compiles successfully, consistent with tcc's support for __thread on other platforms.

Current Behavior

error: _Thread_local is not implemented

Environment details

tcc version	tcc version 0.9.28rc 2026-07-24 HEAD@85ba3ae8 (AArch64 Darwin)
tccbin branch/commit	thirdparty-macos-arm64 @ 274abd2
built via	TCC_COMMIT=85ba3ae8f1e22044255d54c28be04e5fc3e88ae0 TCC_FOLDER=thirdparty/tcc bash thirdparty/build_scripts/thirdparty-macos-arm64_tcc.sh
host OS	macOS 26 (arm64)

Additional Information/Context

Given tcc already supports __thread as a GNU-style extension on other Mach-O/ELF targets, a minimal fix may be to alias _Thread_local/thread_local to the same codegen path used for __thread on this target, rather than a full generic TLS implementation.

[quaesitor-scientiam]

Dug into this further — scope is bigger than the title suggests, and the fix doesn't belong in this repo.

It's not just _Thread_local. Tested the GNU-style __thread fallback on the same build:

__thread int g_x;
int main(void) { g_x = 1; return g_x - 1; }

$ ./tcc.exe -o t t.c
t.c:1: warning: type defaults to int
t.c:1: error: ';' expected (got 'int')

__thread isn't even recognized as a keyword here. So this isn't a missing keyword/alias — TinyCC's macOS/ARM64 (Mach-O) backend has no thread-local-storage implementation at all: no codegen for TLS variable access, no Mach-O TLV descriptor/relocation support.

This repo doesn't carry a patched TinyCC. build.sh just does git clone git://repo.or.cz/tinycc.git, checks out a pinned commit, and builds it unmodified — there's no patch-application step. So a real fix has to land in upstream TinyCC's arm64-gen.c codegen and Mach-O object writer, not here. Upstream TinyCC (the mob tree at repo.or.cz) also isn't GitHub/PR-based — it's mailing-list-patch driven, so this repo has no direct path to fix it either, beyond pinning to a future upstream commit that adds Mach-O ARM64 TLS support (if/when one exists).

Leaving this open for tracking/visibility, but reclassifying: it's a missing feature in upstream TinyCC, not a thirdparty-macos-arm64 build misconfiguration. On the V side, vlang/v#28024 works around it by avoiding tcc whenever V's -prealloc allocator (which needs a thread-local global) would be active.

[quaesitor-scientiam]

Update: a working fix has been implemented and submitted upstream to the TinyCC mailing list (tinycc-devel@nongnu.org), since that's where this actually needs to land — as noted above, this repo just builds vanilla upstream TinyCC unmodified, so there's no local patch mechanism here to carry a fix in the meantime.

What the patch does: implements the Mach-O ARM64 TLV (thread-local variable) mechanism that TinyCC's ARM64 backend never had — a per-variable descriptor {thunk, reserved, offset} that dyld patches at load time, accessed by calling through the thunk rather than the ELF-style TPIDR_EL0-relative addressing TinyCC was emitting (which doesn't apply on Mach-O and reads/writes garbage). Confirms and extends the earlier finding here: __thread isn't just unrecognized as a keyword, the whole TLS access path was ELF-only.

Verification before submitting:

• TinyCC's own make test suite passes in full (73_arm64, 124_atomic_counter, 125_atomic_misc, 136_atomic_gcc_style, 138/139/140/152_arm64_*, btest, memtest, dlltest, cross-test) — no regressions.
• A 4-thread pthread stress test confirms genuine per-thread isolation (independent storage, correct independent counters under concurrent access), not just "doesn't crash."
• A targeted test for a register-clobbering risk the fix has to guard against (TLS store immediately from a function-call result, live locals interleaved, pointer-chasing through TLS storage) passes.
• Rebuilt V's actual self-hosted compiler (cmd/v) with this patched tcc as -cc tcc: the _Thread_local failure from this issue is gone. That did surface one separate, pre-existing gap — bundled tcc also lacks the __sync_add_and_fetch/__sync_bool_compare_and_swap/__sync_lock_test_and_set GCC atomic builtins that V's -prealloc allocator uses, previously masked because compilation never got past the _Thread_local error to reach it. Confirmed unrelated to this fix (same failure with unpatched tcc once _Thread_local is avoided via a different GC mode). Not addressed by this patch.

Scope is deliberately limited to what's needed and verified: TLS variables defined in the same translation unit they're used in (matches how V invokes tcc — one big generated .c file, direct compile-to-executable). extern _Thread_local resolved from a separate object file or dylib isn't covered.

Once/if this lands upstream, a thirdparty-macos-arm64 rebuild against a newer tinycc commit would pick it up. Leaving this open until then.

[quaesitor-scientiam]

looking unlikely the upstream tcc developers will add my patch anytime soon. Do we want to adapt a patch system for tcc?