On Fri, Aug 14, 2026 at 2:29 AM <[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? >
Please implement _Complex and show us the code. It's always easier to achieve something with code to show, debating generally lead nowhere, and it's easier to convince people with code that it is with words. If you're scare to spend a lot of time working on a complex piece of code that will not be merge at the end, then keep in mind that it's just another challenge that your implementation should be simple enough so peoples accept it. As for me I've never used _Complex, but a reason for that is that compiler support is pretty bad, so getting tinycc supporting it, would mean that I could use it. Don't know if I'll have the use-case though. Matthias, > > > 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] 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
