> > 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
