Hi Jordan, > have a TCC compiles musl with no patches as a milestone?
probably not, although musl-libc compilation is relevant to the question. However i am not aware of any kernel which could be fully supported with TCC, hence the mentioned linux-tcc (2.4) kernel fork (or fiwix too known to compile with tcc, if you wish). To keep musl-libc stable with such a linux-tcc kernel alot more patching was necessary anyway, to prevent runtime -ENOSYS for example and ensuring plausible ./configure header-checks. So far dynamic-linking support didn't pass with tcc+musl-libc either, hence a complete system integration was tested with static linking. Once those two milestones - kernel AND libc - were accomplished, only this enabled compile-time and run-time testing hundreds of software components written in C with TCC, mostly recent versions of those. The major hindrance from my side, it's the great efforts necessary to migrate hundreds of ebuilds from gentoo-portage into the configurator steps/ buildsystem - since i consider a complete system-bootstrap with tinycc and a sane and simple packaging system highly relevant too; which so far was not feasible with the portage system (given the trouble to cross-compile/link a python3.static with tcc for example, nasty bashism and the trouble i've had with a tcc compiled bash5.static; nonetheless those problems were solved too and a fully self-hosting portage system is available driven by tcc only 100%). Another current open task is re-basing and testing the tcc-0.9.27 patchset to compile that one with pnut-cc (laurenth) onto mob/HEAD to have a short system-integration path for tcc HEAD (instead of 0.9.26 intermediate). The nightly build CI setup for this is published here, which already can roll along with mob/HEAD but needs the 0.9.26 intermediate still: https://codeberg.org/aggi/tiny-bootstrap Then again, this touches the concern which standard and features tcc itself should rely upon _internally_, which too should be distinguished when discussing C standard compliance. And you'll find the tcc and musl-libc re-compilation steps/ are rather complicated still. Hence this is the pull-request for the bootstrapping patchset which needs a re-base onto mob/HEAD and testing: https://lists.gnu.org/archive/html/tinycc-devel/2026-07/msg00046.html This doesn't necessarily have to be integrated onto mob/HEAD directly though, and such patchset to can be integrated into a dedicated tcc-HEAD boostrapping package step/ instead. Once this is done, an easily compiled linux-tcc/busybox/tcc-HEAD system is unleashed, and another 500 builds ready for re-packaging: http://tinyfront.mooo.com/downloads/x86-embedded/666666/tinyfront-packages.list (this system is up and running for several month already, but the chaos of hundreds of patches and hacks needs a cleanup for a common baseline for tinycc-devel, and bootstrappable) And, i think, this could be a decent guideline to keep such a complete package set including kernel and libc STABLE with i386-tcc at least. Which too establishes a known-working baseline to test for any other ARCH later (once you've got some kernel which can be compiled with tcc; pointing to gcc -S and linker-script support to discuss elsewhere). Long story short, _Complex extension isn't an urgent issue from this perspective. And the guideline should cover, imo: - a complete system bootstrap - a complete system integration, libc, kernel, bootloader - mentioned userspace, for x86_32 at least As a bonus, all this could yield a common development host, let's say TinyCC/OS. Most of the time, i could do all this work without messaging tinycc-devel. However, having applied at various research institutes, universities, employers in germany none of them so far consented with anything yet; hence i wasn't in the mood anymore to git-push anything for almost half a year already, and wasting my time with HR nonsense instead. Hence i git-pushed the most important pieces only and kept some notes, so these aren't lost in case other unexpected trouble escalates. On 2026-08-13 19:28, [email protected] wrote: > 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, [1][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 <[2][email protected]> > À: [3][email protected] > Cc: John Mastronardo <[4][email protected]>, Michael Ackermann > <[5][email protected]>, [6][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 > <[7][email protected]> wrote: > > > Thanks for the feedback. > > > On 2026-08-13 12:12, [8][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: > > > [9]http://tinyfront.mooo.com/downloads/x86-embedded/666666/tinyfront-packag > es.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 > [10]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 <[11][email protected]> > > From: [12][email protected] > > Cc: Michael Ackermann <[13][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, [14][email protected] wrote: > > Hi, > > > I was wondering if any has attempted or started to work out > > implementing _Complex? > > > > > Thanks, > > > > Jordan > > > _______________________________________________ > > Tinycc-devel mailing list > > [15][email protected] > > [16]https://lists.nongnu.org/mailman/listinfo/tinycc-devel > > > _______________________________________________ > > Tinycc-devel mailing list > > [17][email protected] > > [18]https://lists.nongnu.org/mailman/listinfo/tinycc-devel > > References > > 1. mailto:[email protected] > 2. mailto:[email protected] > 3. mailto:[email protected] > 4. mailto:[email protected] > 5. mailto:[email protected] > 6. mailto:[email protected] > 7. mailto:[email protected] > 8. mailto:[email protected] > 9. > http://tinyfront.mooo.com/downloads/x86-embedded/666666/tinyfront-packages.list > 10. http://tinyfront.mooo.com/docs.html#Kernel > 11. mailto:[email protected] > 12. mailto:[email protected] > 13. mailto:[email protected] > 14. mailto:[email protected] > 15. mailto:[email protected] > 16. https://lists.nongnu.org/mailman/listinfo/tinycc-devel > 17. mailto:[email protected] > 18. https://lists.nongnu.org/mailman/listinfo/tinycc-devel > _______________________________________________ > Tinycc-devel mailing list > [email protected] > https://lists.nongnu.org/mailman/listinfo/tinycc-devel
signature.asc
Description: Digital signature
_______________________________________________ Tinycc-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/tinycc-devel
