This commit adds GCC-compatible atomic builtins to stdatomic.h for
better compatibility with code relying on GCC's atomic primitives.
1. **New Macros**:
- `__atomic_compare_exchange_n`.
- `__atomic_load_n`.
- `__atomic_store_n`.
2. **Motivation**:
- Improves compatibility with codebases using GCC's atomic builtins
directly.
- Simplifies atomic operations by allowing direct value passing
(instead of pointers), enhancing code readability.
- Aligns TCC's atomic support closer to GCC/Clang for cross-compiler
projects.
3. **Testing**:
- Verified with basic test cases (integer CAS, load/store) on x86.
- Confirmed no regressions in existing atomic operations.
- This change does not affect existing C11 `atomic_*` APIs.
- Struct types are intentionally unsupported in `_n` variants due to
complexity.
cleanup libtcc.c:tcc_set_linker()
cleanup tccelf.c:tcc_load_ldscript()
Also
- tccrun.c, tccelf.c:relocate_syms():
with tcc -run -nostdlib, do resolve but only from explicitly
on the command-line given libraries.
- tccgen.c: optimize UMOD x % c -> x & (c-1) for c = 2^n
- tcc-doc.texi: cleanup
- tcc.h, tccpp.c, libtcc.c: add 'size' arg to pstrncpy()
Also reorder functions in libtcc.c a bit.
9 files changed, 556 insertions(+), 617 deletions(-)
Aka 'intmax_t', as recommended by newer standards.
For example
if (-0x80000000 < 0) is false,
but
#if (-0x80000000 < 0) is true
because in C, 0x80000000 is an unsigned int, Whereas in
a preprocessor expression, it is a signed long long, even
without LL suffix.
Oviously what the patch wants is... on Windows, with
"tcc c:/dir/xyz.dll -run file"... pass the absolute
path of the dll to LoadLibrary() which can make sense
in situations.
Other changes in the patch to other platfurms seem to
have no effect. This reverts 52a9a541b0
except 2 lines in tccpe.c.
Also revert _Float16 patch a06c608625
As long as tcc does not really handle _Float16, we can just define
it in tccdefs.h.
Also move uint128_t to tccdefs.h for same reason.
Update github action (might fix random arm64 crashes)
arm-asm.c: add forward branches & some ops
lib/armeabi.c: faster i/udivmod (asm)
arm-gen.c: use movw/movt to load constants for CPUVER >= 70
configure: use dwarf-4 debug sections on android, detect idiv
lib/Makefile: always add -I$(TOP) for access to config.h
tcdbg.c: add a "code mapping symbol" to help out llvm-objdump
tccelf.c: don't load SHT_ARM_EXIDX, modify ARM.attributes
tccpp.c: accept '@' for arm asm comments
libtcc.c:
- free 'elfint' string
- acceot -O and -Os
- accept -gstabs (to override dwarf when default)
- better -Wp,...
tccpp.c:
- #line cleanup
also warn with "extra tokens after directive"
tccgen.c & xxx_gen.c:
- force CPU flags to register earlier
tccelf.c:
- tcc_load_object: align size only for code sections
data/bss objects are always put with their specfic type align
(in decl_initializer_alloc())
x86/64 doesn't need aligned code
from c6afdff7ab
tccpe.c:
- enable dllimport for "_imp__<sym>" also from assembler
x86_64-gen.c & lib/libtcc1.c:
- simpler fneg without libtcc1 reference
tests2/134_double_to_signed.c:
- a tcc compiled by msvc won't pass this test
TCC treats -nostdlib and -Wl,-nostdlib as equivalent, but on other compilers
which call a discrete linker, -nostdlib behaves as on tcc (not adding
startfiles/libc/endfiles) by modifying the ld command line, but -Wl,-nostdlib
adds -nostdlib to the ld cmdline, which stops the linker searching the default
directories for libraries.
Noticed this when the crt1.o file on an updated riscv had a
text section where the size is not multiple of align.
This file is loaded first and when the c code is then compiled
the code is not aligned any more.
This results in:
alignment of code section not multiple of 4
in riscv64-gen.c
In x86_64-gen.c/i386-gen.c, gfunc_call will generate structure store
for bt == VT_STRUCT. Before generating any code, it is needed fetch
cpu flag.
As #ifdef TCC_TARGET_PE, gfunc_call() forgot to do this.
when there are no other errors then exit tcc with the exit cude
from tcc_run() (messed up in dd2e5f8b06)
Also in tccrun.c, use a more exotic random value to replace zero
with 'exit(0)' in user code (because lonhjmp(jb, c) needs c != 0)
There was a duplicate definition of LDBL_MAX_EXP, which this commit
removes.
There was a missing definition for LDBL_MAX_10_EXP, which this
commit adds.
I've confirmed the value of LDBL_MAX_10_EXP using gcc on an AARM64
Debian system (gcc 8.3.0). I've only indirectly confirmed the value
on RISCV (using "#if ... #error" on godbolt.org). I'm reasonably
sure this update is correct, but someone should confirm it before
merging to "mob".
Commit a522213 ("tccpe.c: never assume static...") removed the global
-I$(TOP) for cleaner lib build, and ensured that it is added for
bcheck.c as it now includes config.h, but forgot that bt-exe.c also
needs config.h, as it includes ../tccrun.c which includes it.
Also, the explicit tccrun.c prerequisite for bt-exe.c is not required,
as all *.o lib files depend on $(TCC), which depends on libtcc, which
depends on tccrun.c .
Also, at win32/built-tcc.bat, while bcheck.c needs -I.. for config.h,
bt-exe.c doesn't, as ../tccrun.c does find it where it expects it.
just clear s1->static_link before loading msvcrt etc.
Also:
- configure: get cc_version/name when making a cross compiler too
- configure: fix android triplets
- Makefile: remove CONFIG_TCC_CROSS, check TCC_TARGET_xxx instead
- libtcc.c: parse some linker option arguments more correctly
- tccelf.c: fix a versym problem with clang on android
- lib/Makefile, build-tcc.bat: bcheck.c now includes config.h
Elsewhere at configure the value of $mingw32 is expected to be
exactly either yes or no (not empty, not caps, etc), and while it
complies internally, it also accepts arbitrary override value.
Clarify acceptable values, and simplify the parsing.
Add very few missing quotes where IFS/globs were applied to arbitrary
user input (commands, arguments, but not assignments or case $var in.
In fn_makelink $dn/$2/$f don't have IFS/globs).
While configure now handles it correctly, there are 2 issues:
- eval opt=\"$opt\" coalesces IFS chars (--prefix="$HOME/x y").
- Even with the eval removed, (gnu) make still fails to find it.
I made few quick experiments with quoting these values in config.mak,
but that had no impact, and make -d was not helpful. Was worth a try.
So no spaces in paths, but at least configure can handle the src path.
$confvars is not supposed to hold the same key more than once, and
spaces in values won't be parsed correctly. Additionally, it's later
iterated using shell IFS-split - which will also apply globs.
We now abort if the value IFS-splits badly (spaces/glob/empty).
We now warn on duplicates, but still accept them like before.
Example duplicate: --enable-static --disable-static
Example spaces: --config-foo="bar baz"
Example glob: --config-foo=" * "
Note that globs currently already expand at eval opt=\"$opt\"
before we get a chance to test it (but we still detect the spaces).
See commit message of 21272067 (boilerplate var=..) about removing it.
These tests are also performed on values which configure itself adds,
but currently there are no issues with those.
Also, default_conf() now uses confvars_has, which fixes the following:
- False-positive if the key is a substring of existing key or value.
- Incorrect test if the value contains '=' or sh pattern chars *?[] .
No-op, because current default_conf calls don't have such issues.
Trivial, but less noisy when reading, and nicer for new code.
The code still adds the value[s] unconditionaly without checking for
duplicates or spaces in values - both are bad, but next commit will.
Add and use "assign_opt" instead of copy-pasting subshell assignment.
Slightly faster, and fixes option values with consecutive spaces,
for instance --libdir='/foo bar' where previously `echo $opt | ...`
coalesced IFS chars because $opt was unquoted. (this is still very
likely to break, but at least now not at the options parsing).
Unrelated note:
The code does eval opt=\"$opt\" for every argument, to "reproduce
autotools behavior" (commit 2e7a1af, 2012-06-12, Thomas Preud'homme).
This is questionable, and not fun (try: --config-x='"; echo "PWNED').
I emailed the author for more info, but didn't get a reply aftre few
days, and without real-world use cases, I think it should be removed.
The vast majority of shells do support "local", but not all, notably
AT&T ksh (default sh in illumos-based distros and Solaris), but also
some other POSIX-compliant shells, so remove "local".
print_str(), print_num() are modified trivially.
default() now uses standard "Assign Default Value" - same semantics,
and works in all shells (and POSIX).
default_conf() is identical to before, but it had and still has few
minor issues, which will be addressed in a future commit.
Shells do support those, and typically simple forms do work, but
these were removed in POSIX 2024 because they are notoriously hard
to parse correctly, and shells don't always agree on the result.
Instead, use standard forms which all shells support identically.
Extreme high level overview of quotes in POSIX shell:
- WORDs without $... or glob don't need quotes (echo, =, no, x86, ...).
- a= b=foo c=$... and case $d in ... all don't need quotes.
- IFS/glob affect command and arguments (not assignments or case..in):
- IFS only splits direct result of $..., quotes will prevent that.
- Glob then splits/matches *?[] and quotes will prevent that.
POSIX "test" (see Application Usage), and shell language (quotes):
https://pubs.opengroup.org/onlinepubs/9799919799/utilities/test.htmlhttps://pubs.opengroup.org/onlinepubs/9799919799/utilities/V3_chap02.html
My own quick guide:
https://gist.github.com/avih/6752ad1e20b334b56fef120cd09c766e
Commit 729918e ("make: make shorter command lines", 2024-11-21) added
"-static" when $cc_name is gcc to statically link with the mingw gcc
runtime, so that tcc.exe won't depend on additional non-system dlls.
However, $cc_name is still the default value at this time - gcc,
so "-static" was unconditional, and it failed if $cc is tcc (msvcrt).
This commit instead checks the already known $cc, and restores the
ability to build tcc using tcc (if "$cc" doesn't contain "gcc").
Put former NATIVE_DEFINES into config.h. Such tcc can be run
and tested directly from source more easily, like for example:
tcc -run tcc.c -B. -run test.c
Also:
- tccelf.c: cleanup
- tccpp.c: avoid stupid clang warning
- configure: reduce -Wno- switches
- tcc.h: inline wait/post_sem()
- tccpe.c: simplify import (assume STT_NOTYPE is function)
This is a very stripped down version[1], with only CommandLineToArgvW
(typically used with GetCommandLineW() - which we already have),
ShellExecute and FindExecutable, which don't require any new structs,
and where used constants already exist at our winuser.h .
Pretty cheap, and hopefully covers some meaningful new use cases[2].
Requires linking with -lshell32 .
[1] original full version:
http://download.savannah.nongnu.org/releases/tinycc/winapi-full-for-0.9.27.zip
[2] Can now build "less" for windows - https://github.com/gwsw/less/ .
Add -luser32 to LIBS at Makefile.wng (mingw makefile), then (gnu make):
make -f Makefile.wng CC=tcc less.exe
The previous code had few issues:
- Didn't quote an empty string.
- Didn't quote if the string contains tabs.
- Didn't take into account existing backslashes at the string.
E.g. previously broken (in POSIX sh, like cygwin or busybox-w32):
- tcc -m 32 test.c -D 'CSTR="foo'$'\t''bar"' (wrongly rejected by tcc).
- tcc -m 32 test.c -D 'CSTR="foo\"bar"' (incorrect CSTR at test.c).
Both issues are fixed with the new code, and presumably any others.
The empty/tabs issues could be fixed within the current code, but the
backslashes issue is not worth shoehorning it, so this is a rewrite.
I happened to bump into thsese, but I didn't try to review the file,
and there may be other places which could be similarly improved.
This is originally my suboptimal code from commit 100f94be
(tiny_libmaker: more robust arguments interpretation), so, a bit late,
but let's improve it anyway.
Before VC2005, the time macros (time, time_t, localtime, etc) were
32 bit on 32 bit platforms, but they became 64 in VC2005.
This works even on XP 32 (_time64 etc do exist in XP32 - and in tcc).
However, tv_sec in struct timeval (which for msvc is in winsock2.h)
remains 32 bit to this day on 32 bit platforms, and dlls which were
not recompiled remain with time 32, possibly at the API boundary.
Due to these, and maybe more, mingw w64 decided to keep the time
macros 32 bit on 32 bit platforms, with __MINGW_USE_VC2005_COMPAT
override (which does nothing in mingw w64 except time -> time64).
It's not perfect, but it allows some existing code to easily switch
to 64 bit time without redefining time etc, e.g. used by libressl:
https://github.com/libressl/portable/blob/master/README.mingw.md
Before, it was impossible to enable the 64 bit time macros in tcc 32.
This commit adds support for __MINGW_USE_VC2005_COMPAT in tcc as well,
which, like in mingw w64, affects only the 32->64 time macros, and is
a cheap way to get 64 bit time in existing code in some 32 bit apps.
The additional #ifndef _USE_32BIT_TIME_T is unrelated to the override,
and avoids a warning (and nothing else) when the code explicitly
defines it - which is allowed in MSVC, and also guarded in mingw w64.
Relevant current quote from the libressl link above:
------- >8 ---------
Why the -D__MINGW_USE_VC2005_COMPAT flag on 32-bit systems?
An ABI change introduced with Microsoft Visual C++ 2005 (also known as
Visual C++ 8.0) switched time_t from 32-bit to 64-bit. It is important
to build LibreSSL with 64-bit time_t whenever possible, because 32-bit
time_t is unable to represent times past 2038 (this is commonly known
as the Y2K38 problem).
If LibreSSL is built with 32-bit time_t, when verifying a certificate
whose expiry date is set past 19 January 2038, it will be unable to
tell if the certificate has expired or not, and thus take the safe
stance and reject it.
In order to avoid this, you need to build LibreSSL (and everything
that links with it) with the -D__MINGW_USE_VC2005_COMPAT flag. This
tells MinGW-w64 to use the new ABI.
64-bit systems always have a 64-bit time_t and are not affected by
this problem.
with -Wl,-oformat=binary, executable code should come first.
(for linux kernel image for example)
Also:
- simplify RELRO sections: create them as readonly, but add
SHF_WRITE flag later when needed (i.e. relocations do exist)
- tcc.h etc: exclude eh_frames on non-elf platforms
- tccelf.c:tcc_load_object_file(): don't load debug sections when
linking without -g (special dwarf case in relocate_section()
wont work when dwlo/hi were not initialized).
- tcc.c: avoid loop if something fails (ret < 0) without message
(while failing without message should not happen either)
- tccelf.c:tcc_load_alacarte: give message
- tccpp.c: treat '# 123xyz' in asm file as comment
- lib/Makefile: cleanup
- libtcc.c: tcc_add_library(): fallback to try filename as is
(also remove tcc_add_library_err())
