sync.stdatomic breaks under -cc tcc

[nepinhum]

Describe the bug

sync.stdatomic breaks under -cc tcc

Redundant #include <stdatomic.h> in 1.declarations.c.v reintroduces the exact problem its own tcc compat header guards against

vlib/sync/stdatomic/1.declarations.c.v inserts a bundled, tcc safe header (thirdparty/stdatomic/nix/atomic.h) that correctly guards against needing the real system <stdatomic.h> under tcc:

#ifndef __TINYC__
#include <stdatomic.h>
#endif
But immediately after inserting that header, 1.declarations.c.v itself does a second, unguarded real include for tcc builds (lines ~21-22):
$if tinyc {
    #include <stdatomic.h>
    $if linux {
        #insert "@VEXEROOT/vlib/sync/stdatomic/tcc_compat_linux_fence.h"
    }
}

This second include is redundant, everything needed was already declared by the compat header above and it reintroduces exactly the failure the guard was written to prevent. tcc can't reliably compile GCC's real <stdatomic.h>

tcc -E -dM - < /dev/null predefines zero _ATOMIC* macros (GCC's header needs __ATOMIC_RELAXED, __ATOMIC_SEQ_CST, etc.)

Reproduction Steps

test.v:

module main

import sync.stdatomic

fn main() {
     mut a := stdatomic.new_atomic(i64(0))
     a.store(1)
     println(a.load())
}

v -cc tcc -no-retry-compilation run test.v:
builder error: 'stdatomic.h' not found

Expected Behavior

Compiles and runs under tcc, since the bundled compat header already declares everything sync.stdatomic needs without touching the real system header.

Current Behavior

builder error: 'stdatomic.h' not found
tcc can't locate GCC's private header directory. On a system where tcc can locate that header, the failure instead becomes error: '__ATOMIC_RELAXED' undeclared

Possible Solution

Remove the redundant #include <stdatomic.h> (and the tcc_compat_linux_fence.h insert that depends on it) from the $if tinyc block in 1.declarations.c.v
The preceding #insert "@VEXEROOT/thirdparty/stdatomic/nix/atomic.h" already declares everything for tcc. If tcc_compat_linux_fence.h's fence symbol direction fix is still needed without that real include present, it should be rederived against the bundled compat header instead of against the real system header.

Additional Information/Context

Found while investigating why a project using sync.stdatomic for lock free counters always silently falls back from tcc to cc under v run, with no indication why.

V version

V 0.5.2 76f77e3.5fc71b2

Environment details (OS name and version, etc.)

V full version	V 0.5.2 76f77e3.5fc71b2
OS	linux, "EndeavourOS Linux"
Processor	8 cpus, 64bit, little endian, Intel(R) Core(TM) i5-10300H CPU @ 2.50GHz
Memory	0.6GB/7.62GB
V executable	/home/scher/v/v
V last modified time	2026-08-04 11:52:06
V home dir	OK, value: /home/scher/v
VMODULES	OK, value: /home/scher/.vmodules
VTMP	OK, value: /tmp/v_1000
Current working dir	OK, value: /home/scher/projects/vlang/netherrack/vedrock
Git version	git version 2.55.0
V git status	0.5.2-211-g5fc71b2d
.git/config present	true
cc version	cc (GCC) 16.1.1 20260728
gcc version	gcc (GCC) 16.1.1 20260728
clang version	clang version 22.1.8
tcc version	tcc version 0.9.27 (x86_64 Linux)
tcc git status	HEAD c29a7c89
emcc version	N/A
glibc version	ldd (GNU libc) 2.44

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.

[xRookieFight]

Can confirm, and I think the diagnosis here is exactly right.

I hit the same thing a while back and spent way too long assuming it was my setup. What makes it confusing is that the failure looks like a missing-header problem on your machine, so the first instinct is to go hunting for tcc include paths, which is a dead end. The bundled thirdparty/stdatomic/nix/atomic.h is already doing the right thing with its #ifndef __TINYC__ guard - that guard exists precisely because tcc cannot be expected to consume GCC's <stdatomic.h>. Then the $if tinyc block a few lines below immediately undoes it with an unguarded include of the same header. So the one compiler the guard was written for is the only one that ends up pulling in the header it was guarding against.

The __ATOMIC_* point is the part worth emphasizing, because it means "just fix the include path" is not a fix. tcc -E -dM - < /dev/null predefines none of them, and GCC's <stdatomic.h> is written on the assumption that the compiler provides __ATOMIC_RELAXED, __ATOMIC_SEQ_CST and friends as builtins. So there are two distinct failure modes depending on the machine:

• tcc cannot find GCC's private header dir -> builder error: 'stdatomic.h' not found
• tcc can find it (multilib layout, or someone added the path) -> '__ATOMIC_RELAXED' undeclared

Same root cause, and the second one is arguably worse because it looks like a completely different bug. I got the second variant on a Debian box and the first one on Arch, which cost me a good hour of thinking the two were unrelated.

Minimal repro, same as OP's:

import sync.stdatomic

fn main() {
	mut a := stdatomic.new_atomic(i64(0))
	a.store(1)
	println(a.load())
}

v -cc tcc -no-retry-compilation run x.v

The -no-retry-compilation flag is doing a lot of heavy lifting there. Without it the whole thing is invisible: V quietly retries with cc, the program runs fine, and you walk away believing tcc works. That is how OP describes finding it and it matches my experience. Anyone using sync.stdatomic in a project has effectively lost tcc as a backend without ever being told. For a compiler whose main selling point is fast iteration builds, silently falling back to gcc on every run is a real cost, and it is the kind of thing you only notice when you happen to time a build and wonder why it is slow.

On the proposed fix: dropping the redundant #include <stdatomic.h> from the $if tinyc branch looks correct to me. Everything sync.stdatomic actually references is already declared by the compat header - that is the entire reason the compat header exists. The only piece that needs care is tcc_compat_linux_fence.h, since it was written against the real header's symbols. If the fence direction fix is still needed, it should be rederived against the bundled declarations rather than kept alive by dragging the system header back in. Keeping the system include just to satisfy that one insert is the tail wagging the dog.

Two things I would suggest on top of the fix itself:

1. A CI job that builds a sync.stdatomic sample with -cc tcc -no-retry-compilation. Without -no-retry-compilation a regression here is invisible to CI for the same reason it is invisible to users. This class of bug can survive indefinitely otherwise.
2. Separately from this issue, the silent cc fallback deserves at least a note under -v. "tcc failed, retrying with cc" would have turned both my hour and OP's investigation into about ten seconds. Right now the fallback hides the very information you need to report the bug.

Happy to test a patch on Arch + tcc 0.9.27 if someone puts one up.