I think this is exactly why it would be valuable to finally bite the bullet and declare a 1.0 production release.
TCC 0.9.27 was released on December 17, 2017. That’s now more than eight and a half years ago. In all that time, TCC has continued to evolve, accumulate fixes and improvements, and move well beyond what that version number suggests.
As aptly put here, “TCC is way beyond 0.9.27 already, but apparently nobody has been brave enough to put an official tag on the latest HEAD.”
Perhaps that’s the real issue: at some point, the version number itself starts sending the wrong message. Someone discovering TCC today sees “0.9.27” and quite reasonably assumes they’re looking at an old, perpetually-beta compiler project. That’s unfortunate, because TCC is far more interesting and capable than that impression suggests.
A 1.0 designation doesn’t have to mean “perfect” or “finished forever.” It can simply mean: this is a mature, usable, supported production release that we are willing to stand behind.
After nearly nine years since 0.9.27, surely TCC has earned that distinction.
So, perhaps it’s finally time for someone to be “brave enough” to put the 1.0 tag on it. 🙂
I suspect that single act would do a lot to signal to the outside world that TCC is ready to be taken seriously as a production-quality lightweight C compiler.
—JM
On Aug 13, 2026, at 8:02 AM, Michael Ackermann via Tinycc-devel <[email protected]> wrote:
Thanks for the feedback.On 2026-08-13 12:12, [email protected] wrote:"i tend to think tinycc may not be the playground for it"
Is TCC a personal "playground" or a C compiler that could (should) be considered capable ?
tinycc already is a rather capable C compiler/toolchain to compile kernel, libc,and a huge userspace of ~500 ebuilds backported for linux-tcc/musl.I am only a little worried it's becoming de-stabilized and progress made alreadyat stake then.All I see is people saying that TCC feature set should (must) only cover what they need out of it ("it's good enough for me").
The C standard has been bastardized enough during its lifespan, why not selecting one version (c99, c11) and make it feature
complete once and for all ?
One major issue i recall was the trade-off between language-features relied upon_internally_ with tinycc and keeping it's latest mob/HEAD fully "bootstrappable"(Sorry to mention this again, but it's something i consider utmost important)Gladly there's been some other ground-breaking contribution to make 0.9.27compilable by pnut-cc compiler recently. I've just not been in the moodto re-base this onto mob/HEAD for testing with tiny-bootstrap.Together with a few musl-libc patching _Complex is a non-issue, which does notmean if anyone wished to implement it there was any objection from my side,i only bothered to ask because i stumbled upon it before myself.Anyway, that's unrelated to the question how my enthusiam reached it's limits toproceed any further - and this is unrelated to tinycc-devel alike.It's tiresome to see people arguing how not to implement this functionality or that support, taming down willing enthusiasts.
No wonder why TCC is still at 0.9.27 after so long, nobody wanting to take it seriously as a capable yet lightweight C compiler
contender.
tinycc is way beyond 0.9.27 already, there's just not been anyone brave enoughto issue an official git-tag on latest HEAD, for x86_32 at least.
We've seen some BSD patches recently, some breaking things, some fixing things, __Complex has been an issue for a while now (some libraries need it nonetheless).
Good question: which libraries do need _Complex extension? FYI i've notencountered any yet when backporting mentioned userspace components:http://tinyfront.mooo.com/downloads/x86-embedded/666666/tinyfront-packages.list(ALL of this is driven by tinycc 100% without gcc/binutils/llvm/clang involvedanywhere); Of cause this list may not be complete although i tried to salvagealmost EVERYTHING relevant that a C-compiler could digest, but haven't checkedall options for math-libraries coping with signal processing and complexnumbers, and if any of those would need support from tinycc with _Complex.There is other, language features however, NPTL and __thread for example,which had to be coped with and their absense didn't cause any relevant troubleeither so far when remaining a bit conservative on the userspace side.Nonetheless i do appreciate activity on the BSD side alot in principle, really.For the record last time OpenBSD tried with PCC (year 2007) they did not yield acomplete system-integration anywhere close to what's been possible with tinyccsince recently (here's a few notes again http://tinyfront.mooo.com/docs.html#Kernel)Why should we always have to rely on "many other gigantic heavy-weight toolchains" when it surely doesn't need "millions of
lines of code which do implement it" ?Gladly we do not have to anymore, because tinycc is in decent shape and amostly complete GNUish/POSIX port being confirmed to pass both compile-timeand initial run-time testing (with x86_32).Come on guys, make TCC great again, with each passing year it should implement many new things and fix bugs, by now it should be
"gcc or llvm/clang" at a fraction of the size.
Is it ?
Regards.
----- Mail d'origine -----
De: Michael Ackermann via Tinycc-devel <[email protected]>
From: [email protected]
Cc: Michael Ackermann <[email protected]>
Envoy�: Thu, 13 Aug 2026 11:33:27 +0200 (CEST)
Objet: Re: [Tinycc-devel] ISOC99 _Complex
Hi,
i'll try to summarize a few notes concerning C99 _Complex first:
- with C11 it was designated an _optional_ core language feature again;
in principle i do feel _Complex is non-orthogonal to C-language at the
abstraction layer of C language
- of cause complex numbers are important, question is if those should become
a core language-feature of C itself hence
- there certainly are other options to implement complex numbers such as some
dedicated math-library (would be curious myself which those are);
and what would any benefit of _Complex be over any dedicated math library?
- another motivation to implement _Complex language extension regardless seems
musl-libc for example by default relies upon it, but this can easily be
patched without extending tinycc compiler and won't cause any trouble
anywhere then (i'm maintaining such a musl-libc and userspace fork here to
backport onto linux-tcc/musl for example, absense of _Complex was a
non-issue so far, and when complex numbers are required i would be curious
which math libraries existed to implement them where those belong)
- it's important to consider the trade-off between language features supported
and complexity of tinycc compiler; obviously tinycc is intended to be tiny
by design and i do not know how much _Complex extension would add to the belly
of tinycc (there is many other gigantic heavy-weight toolchains such as
gcc or llvm/clang with dozens of millions of lines of code which do implement it)
Long story short, of cause _Complex implementation is an interesting topic,
given the importance of this with signal processing etc,
but i tend to think tinycc may not be the playground for it.
Hope i'm not in error with this judgement, feedback appreciated if any.
Michael
On 2026-08-12 21:51, [email protected] wrote:
Hi,
I was wondering if any has attempted or started to work out
implementing _Complex?
Thanks,
Jordan
_______________________________________________
Tinycc-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
_______________________________________________Tinycc-devel mailing list[email protected]https://lists.nongnu.org/mailman/listinfo/tinycc-devel
|
signature.asc