Been there already : https://lists.nongnu.org/archive/html/tinycc-devel/2026-05/msg00007.html
----- Mail d'origine ----- De: david koch <[email protected]> À: [email protected] Cc: [email protected], 'J Mastron' <[email protected]>, 'Michael Ackermann' <[email protected]> Envoyé: Fri, 14 Aug 2026 07:16:58 +0200 (CEST) Objet: [Tinycc-devel] Re : RE: Version 0.9.27 Chicken - egg problem : Shouldn't musl stick to a standard conformance or a compiler bending to adapt to a specific software ? Regards ----- Mail d'origine ----- De: [email protected] À: [email protected], david koch <[email protected]> Cc: 'J Mastron' <[email protected]>, 'Michael Ackermann' <[email protected]> Envoyé: Fri, 14 Aug 2026 02:28:11 +0200 (CEST) Objet: RE: [Tinycc-devel] Version 0.9.27 Question – TCC pairs really well with musl. Would it be worthwhile to have a TCC compiles musl with no patches as a milestone? Jordan From: [email protected] <[email protected]> On Behalf Of J Mastron via Tinycc-devel Sent: Thursday, August 13, 2026 2:33 PM To: [email protected] Cc: J Mastron <[email protected]>; [email protected]; Michael Ackermann <[email protected]> Subject: Re: [Tinycc-devel] Version 0.9.27 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] <mailto:[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] <mailto:[email protected]> > À: [email protected] <mailto:[email protected]> Cc: John Mastronardo <[email protected] <mailto:[email protected]> >, Michael Ackermann <[email protected] <mailto:[email protected]> >, [email protected] <mailto:[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] <mailto:[email protected]> > wrote: Thanks for the feedback. On 2026-08-13 12:12, [email protected] <mailto:[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] <mailto:[email protected]> > From: [email protected] <mailto:[email protected]> Cc: Michael Ackermann <[email protected] <mailto:[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] <mailto:[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] <mailto:[email protected]> https://lists.nongnu.org/mailman/listinfo/tinycc-devel _______________________________________________ Tinycc-devel mailing list [email protected] <mailto:[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
