For me, I would go for just the basic C11 as 1.0.
Then once we reach 1.0, add various language features as 1.1, etc.
Given the difficult in getting to 1.0, we should consider a more
reachable goal compared to the whole C11 standard. Would be nice as 1.0
but a 1.0 would be nicer than the whole C11 standard.
Moving forward is better, for me, than debating which C standard.
My two cents anyway,
Jordan
-------- Original Message --------
SUBJECT:
Re: [Tinycc-devel] Version 0.9.27
DATE:
2026-08-13 15:33
FROM:
J Mastron via Tinycc-devel <[email protected]>
TO:
[email protected]
I think the discussion is getting to a very good place.
For me, the clearest definition of TCC 1.0 would be complete
implementation of the C11 standard, including its optional language and
library features. Define the supported targets and operating systems,
make the C11 baseline explicit, and then we know exactly what "1.0"
means.
Of course, 1.0 is a milestone, not a retirement party. After that,
development should continue indefinitely with new architectures,
extensions, optimizations and bug fixes. 1.0 doesn't have to mean
"finished forever." It means that TCC has reached a well-defined,
reliable production baseline.
And that brings me back to the original point: 0.9.27 was released on
December 17, 2017. We're now nearly nine years beyond that, yet 0.9.27
remains the official production release.
I'd like to see a roadmap something like:
0.10.x → 0.11.x → ... → 1.0 = complete C11 implementation
with each release representing a clearly documented step toward that
goal.
That would give developers and users something much better than an
apparently endless series of patches on a nearly nine-year-old 0.9.27
designation.
And once TCC 1.0 exists as a stable, complete C11 implementation, it
should of course continue to evolve.
On Aug 13, 2026, at 11:18 AM, [email protected] wrote:
A version 1.0 would usually stands for a "feature completeness", a
"goal reached".
What is the purpose to fulfill for TCC version 1.0 ? What is the goal
to reach ?
A new 0.10.0 should already signal something big happened.
But then again, some milestones should be set, with release date of
course :
0.10.1 : RISC-V "A" extension
0.10.2 : RISC-V "M" extension
0.10.3 : _Complex support (CMPLX, CMPLXF, CMPLXL macros)
0.10.4 : ...
Using git it's easy to work on separate features in parallel, with unit
testing, then merge it when it's done.
As soon as the feature is merged, new tag and official release is made
(eg. RISC-V "M" extension done : 0.10.2 is released).
Meanwhile the other features are developed/tested/fixed.
A dependency graph might have to be made to decide which feature comes
first and thus set the release "schedule".
C11 is more than 15 years old now (april 2011) so I guess things are
well understood and documented.
Let's say 1.00.0 should be full C11 support, indistinguable from "gcc
or llvm/clang" but "compactness and speed".
I repeat : only regarding C11 support, the rest is out of scope.
Now one have to decide which target to support : x86, AMD64, arm,
aarch64, RISC-V, what extensions.
But also limit the scope of supported OS to a few : linux, windows,
mac, BSD
That would help to design a clear roadmap.
The rest could be ported by the community, knowing that TCC 1.00.1
would better worth their consideration now.
Regards.
----- Mail d'origine -----
De: John Mastronardo via Tinycc-devel <[email protected]>
À: [email protected]
Cc: John Mastronardo <[email protected]>, Michael Ackermann
<[email protected]>, [email protected]
Envoyé: Thu, 13 Aug 2026 16:37:36 +0200 (CEST)
Objet: Re: [Tinycc-devel] Version 0.9.27
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 already
at 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.27
compilable by pnut-cc compiler recently. I've just not been in the mood
to 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 not
mean 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 to
proceed 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
enough
to 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 not
encountered 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
involved
anywhere); Of cause this list may not be complete although i tried to
salvage
almost EVERYTHING relevant that a C-compiler could digest, but haven't
checked
all options for math-libraries coping with signal processing and
complex
numbers, 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
trouble
either 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 a
complete system-integration anywhere close to what's been possible with
tinycc
since 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
a
mostly complete GNUish/POSIX port being confirmed to pass both
compile-time
and 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
_______________________________________________
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
