Hello Sam,
> we can discuss whether tcc should implement them or not See, "not" again. Let's say TCC 1.0 is fully C11 compliant so we don't bother wondering what's inside or what's "not". The "optional feature" thingy will only add further confusion, make then all supported and case closed. Then if TCC 1.0 stays that way for years to come, I guess we could be plenty satisfied enough with it. At least we know we have a reliable reference implementation, the only "improvements" being target support. And bug fixes of course. If the goal if just "compactness and speed" then I guess C4 is enough for everybody (like 640 kB). https://github.com/rswier/c4 > if we are doing this just to tick the box of C11 compliance, that is another. No, it's about knowing that TCC have at least one standard fully supported, hence when a software is said to be C11 compliant, we know "for sure" that TCC is capable of compiling it. Many people don't use TCC because it's a "toy" compiler (did someone said a "playground") that is unknown for feature support and code reliability. If TCC can prove its full C11 compliance at least it'll gain some respect, not necessary popularity though, a step in the right direction though. But at least it'll prove there is some kind of governance and technical knowledge to cover all of at least one standard, be it 15 years old. No need to chase silly extensions and CPU support when there is already a full specification to chew on. That doesn't prevent TCC to keep its goals of "compactness and speed", but at least people would know it could do one thing well. > make the case for them individually and not just gesture towards C11 There are no cases to be made up out of thin air, could people rely on a compiler whose feature set is barely documented ? Should people cross their fingers before using TCC because they don't know if someone decided what to support or not, if the code will run or segfault. No wonder people are using "gigantic heavy-weight toolchains" to compile C89-C11 code, because those compilers have reputation and are used in production. Not TCC. Standards have been made to avoid the implementation jungle of the 80's when C compilers were not compatibles with each others : https://cscie26.dce.harvard.edu/~dce-lib113/reference/c/c_history.html https://thechipletter.substack.com/p/a-history-of-c-compilers-part-1-performance Hence no need to mindboggle yourself about which boxes to tick regarding what TCC should support/implement : tick them all and call it a day. It's only you arguing what TCC should probably "not" support (because "still considered a usable C compiler"), yet without giving a definitive answer. I'm the one remaining in the clear about this : it's my "final answer". Regards. ----- Mail d'origine ----- De: Sam Ellicott <[email protected]> À: [email protected] Envoyé: Thu, 13 Aug 2026 17:43:03 +0200 (CEST) Objet: Re: [Tinycc-devel] Re : Re: Re : Re: ISOC99 _Complex > > Let me help pointing you to the right "concrete, technical arguments" : > > https://docs.google.com/file/d/0BwtP9e5j1RbpbHF2UXg3dEg2eWs/edit?resourcekey=0-vvVF6Ls0oBlWLZklxaJedQ > https://en.wikipedia.org/wiki/C11_(C_standard_revision) > https://cppreference.com/c/11 What *exact* parts of C11 is tcc missing that makes compilation fail. _Complex isn't one of these since it was made optional in C11 (We should probably set the __STDC_NO_COMPLEX__ macro if it isn't already set) Once we all have an idea on exactly what features are being proposed for addition we can discuss whether tcc should implement them or not (instead of vaguely pointing at the C11 standard). MSVC didn't implement many of the C99 or C11 requirements for decades and was still considered a usable C compiler (not that MSVC is necessarily an example to emulate). These are the features I see here: https://en.cppreference.com/c/11 * Analyzability - optional feature * Threading support - optional feature * Atomics - optional feature * Complex - optional feature * _Alignof / _Alignas - Probably useful to add * Unicode support - IMHO this would be a significant amount of work. Additionally, getting this to work cross-platform will be another headache. https://thephd.dev/cuneicode-and-the-future-of-text-in-c * _Generic - Meh (IMHO not super useful until the C2y additions coming soon (possibly)) * _Noreturn - not really useful for tcc, but just "absorbing" it wouldn't cause problems and be easy to implement * Anonymous structs and union members - We might already handle this due to gcc-isms? * Order of operations changes - I haven't looked. Reference here: https://en.cppreference.com/c/language/eval_order * Lifetime extension on temporary objects - I haven't looked. Reference here: https://en.cppreference.com/c/language/lifetime#Temporary_lifetime * _Static_assert - This might be painful to implement, or it might be easy. I don't know. Every additional feature impacts the goal of compactness and speed. > > It's no more OTCC time, my computer could handle more than megabytes. Typical TCC installation is 7 MB, even if it double (14 MB) I guess I can > live with that. > >> Tinycc has a very different purpose than those > > Isn't compiling C their common purpose ? > Why would TCC not being able to build "real" C and just a sub standard of > it ? > Because of "the goal of compactness and speed" ? > Producing unusable code at lighting fast speed still produces unusable > code. > If you manage to compile C11 code at half "gcc or llvm/clang" speed, it > still fits the "speed" goal. > Of course compiling 10x time faster a code ("speed") that runs 10x time > slower than what "gcc or llvm/clang" do (because no optimization) is > questionable. I expect most of us using tcc value it for being *very* small. I don't want tcc to chase gcc or clang exclusively for the sake of standards compliance. C has *already* fragmented, where almost everyone writes in some subset of language features and compiler extensions. What we do here isn't going to change that. If there is some real piece of software that doesn't compile with tcc due to missing features, that's one thing; if we are doing this just to tick the box of C11 compliance, that is another. If you want any of these features (or ones not mentioned) I would encourage you to make the case for them individually and not just gesture towards C11; otherwise we will just end up debating back and forth with nothing getting done. Thanks, -Sam Ellicott Soli Deo Gloria _______________________________________________ Tinycc-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/tinycc-devel
