sync.stdatomic: fix tcc builds when tcc has no stdatomic.h - #28027
Merged
medvednikov merged 1 commit intoAug 5, 2026
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #28026.
1.declarations.c.vunconditionally includes the real<stdatomic.h>for tcc builds, right after the bundled compat header has gone out of its way to avoid it. That include was added in #27740 to bring the standard API back for user and third-party headers, and it works fine with the tcc V bundles (0.9.28rc), because that one ships its own self containedstdatomic.h. It falls apart on anything older - tcc 0.9.27 has no such header, so the include either fails outright:or, on a system where tcc does end up finding GCC's copy, dies a bit later on
'__ATOMIC_RELAXED' undeclared, since GCC's header is written against builtins tcc does not provide.Because
v runsilently retries with cc, none of this is visible unless you pass-no-retry-compilation. Anyone importingsync.stdatomicjust quietly loses tcc as a backend.So instead of including the header blindly, check for it first and fall back to the compat header's own definitions when it is not there. The
#include <stdatomic.h>moves into a newtcc_compat_restore.h, guarded by__has_include. When tcc has the header nothing changes at all - same include, same order, same behaviour as today. When it does not, the fallback restores the handful of names the cleanup header stripped and that V itself needs:_Atomic,memory_order, thememory_order_*constants and the thread fence declarations, mirroring whatthirdparty/stdatomic/nix/atomic.halready does for tcc.Older tccs without
__has_includesupport take the fallback branch too, which is the right answer for them anyway.Testing
Reproduced by removing
stdatomic.hfrom the bundled tcc's include dir, which puts it in the same state as a 0.9.27 install. On master that gives the exact error from the issue; with this patch:v -cc tcc -no-retry-compilation runon the issue's repro - fails on master, prints1with the patchv -cc tcc -no-retry-compilation test vlib/sync/with the header removed - passesv -cc tcc -no-retry-compilation test vlib/sync/with the header in place - passes, unchangedv -cc gcc test vlib/sync/stdatomic/- passesv -cc tcc -no-retry-compilation -o v cmd/v- buildsOne note on the no-header case:
stdatomic_include_after_compat_nix_test.vstill fails there, but that is by design - the test itself does#include <stdatomic.h>, so it cannot pass on a compiler that has no such header. CI uses the bundled tcc, so it is unaffected.