mac: `v self` not working with `tcc`

[rilaaax]

Describe the bug

v self fails to build with tcc (which is the default)

Reproduction Steps

v self

Expected Behavior

success

Current Behavior

V self compiling (-cc tcc -gc none -o v2)...
warning: tcc compilation failed, falling back to cc
V built successfully as executable "v".

Possible Solution

No response

Additional Information/Context

No response

V version

0.5.2 a5a89d5

Environment details (OS name and version, etc.)

V full version	V 0.5.2 76f77e3.a5a89d5
OS	macos, macOS, 27.0, 26A5388g
V git status	0.5.2-210-ga5a89d56
cc version	Apple clang version 21.0.0 (clang-2100.1.1.101)
gcc version	Apple clang version 21.0.0 (clang-2100.1.1.101)
clang version	Apple clang version 21.0.0 (clang-2100.1.1.101)
tcc version	tcc version 0.9.28rc 2026-07-24 HEAD@85ba3ae8 (AArch64 Darwin)
tcc git status	thirdparty-macos-arm64 274abd24
emcc version	N/A
glibc version	N/A

Note

You can use the 👍 reaction to increase the issue's priority for developers.

Please note that only the 👍 reaction to the issue itself counts as a vote.
Other reactions and those to comments will not be taken into account.

[quaesitor-scientiam]

Confirmed

This comes from consts_and_globals.v:605, which emits _Thread_local for g_memory_block whenever pref.prealloc is on. And default.v:298-306 auto-enables prealloc for any building_v build on macOS with no real GC selected — which is exactly what a plain v self (with its implicit -gc none) does every time. The bundled tcc doesn't implement the C11 _Thread_local keyword, so it always fails on this line, and the builder's existing retry logic silently falls back to cc and rebuilds from scratch.

fix coming shortly

[quaesitor-scientiam]

Update, for tracking:

• The immediate symptom here (v self falling back from tcc to cc with a warning) is fixed by vself: do not default to tcc on macOS arm64 when it would just fail #28024, already merged: v self no longer asks for tcc in the one situation where it's guaranteed to fail (a plain, no-explicit--gc self-build, which forces -prealloc and thus a _Thread_local global tcc couldn't compile). That fix applies to v self on any macOS version, Apple Silicon (arm64) specifically — it's about which compiler gets picked, not an OS-version constraint.

• The actual root cause — the bundled ARM64 tcc never implemented Mach-O thread-local storage at all (not just a missing _Thread_local keyword, __thread failed identically) — has been diagnosed, fixed, and submitted upstream to TinyCC. Tracked at vlang/tccbin#86, with full details and verification there.

Versions this covers, to be precise:

• The upstream patch only takes effect for the ARM64 Mach-O backend (Apple Silicon). It does not touch the x86_64 Mach-O (Intel Mac) backend at all — that path was already unaffected by this specific bug (Intel tcc doesn't hit this _Thread_local/prealloc issue), and I did not investigate whether it has its own TLS gaps.
• As part of the fix, the patch also corrects a stale minos 10.6 (macOS Snow Leopard) that TinyCC's Mach-O linker was hardcoding into every ARM64 binary it produces — bumped to 11.0 (Big Sur), since that's the oldest macOS Apple Silicon can run at all. dyld gates TLV descriptor patching on this field, so the old value silently broke thread-locals independent of anything else. This has no practical compatibility cost: there is no Apple Silicon Mac running macOS below 11.0 for that minOS bump to exclude.
• Net effect once/if the patch lands upstream and vlang/tccbin's thirdparty-macos-arm64 gets rebuilt against a newer commit: _Thread_local/__thread will work correctly with tcc on any Apple Silicon Mac (macOS 11.0+, i.e. effectively all of them), for code that defines and uses the TLS variable within a single compiled file — which is exactly how V invokes tcc (v self and -cc tcc builds always compile to one big generated .c file per executable).

Until that lands, #28024 already means the default v self path is unaffected either way.