David Koch is spot on. I couldn’t agree more, and I’m paraphrasing him here: Pause the adventurous code. Do a feature freeze and a comparison checklist with other compilers. Then thoroughly test a few release candidates with a chosen set of popular platforms. After that, publish a completely stable new official TCC 10.0 that we can be proud of. Like David, I’d like TCC to be treated more professionally than its original legacy. And, I also thank you all for putting your time and passion into its maintenance. —JM
> On May 29, 2023, at 6:06 PM, david.k...@libertysurf.fr wrote: > > Hi Detlef, > > I don't care about the "simplicity" of tcc and its supposed goal not to > compete with larger and more established compilers like gcc or clang. > > Tcc still have to be reliable and not falling on simple corner cases because > someone decided to push a patch on the mob branch, requiring someone else to > remove it. > > I'd like tcc not to be considered just a "quick hack" or a "toy compiler" due > to its inherent simplicity, it still have to produce correct and reliable > code. > > Especially since its internals are so "simple", there is no reason tcc > couldn't be thoroughly tested and stabilized orthogonally across all > supported architectures. > > It's been more than 5 years since the last "stable" release, I'd like the > next one to be as much "reliable" despite the mob branch will still remain > the Wild Wide West of salvage patches. > > Experimenting is one thing, but regarding the last few months of adventurous > code modifications and group discussions, I would NOT bet on just numbering > the current state as being the new 0.10.0. > > Let's do a feature freeze first, a comparison checklist with other compilers, > supporting common flags and attributes, producing correct binary files > (Windows, Linux, Mac, ...). > > Then after a few release candidates, maybe only we could decide the last RC > to be worthwhile enough to get released with the new official 0.10.0 tags > that we could feel proud of. > > Until then tcc:mob will just remain a nerd's joke and a geek's playground > that only a few insiders can really use it after great hacking to get it to > work almost like expected. > > Our view on tcc may diverge, but rest assured I like it anyway, I just would > like it to be treated more fairly and professionally than its original legacy. > > Thank you all for putting all such time and passion into its maintenance. > > Regards. > > > ----- Mail d'origine ----- > De: wine dev <wine....@web.de> > À: tinycc-devel@nongnu.org > Envoyé: Mon, 29 May 2023 14:39:17 +0200 (CEST) > Objet: Re: [Tinycc-devel] Re : Calling for Release 0.10.0 > >> [Tinycc-devel] Re : Calling for Release 0.10.0 – Hi, >> >> the mob branch is pretty much unstable. >> >> Before turning the mob branch into a new release, better do some thorough >> checking and regression testing. >> >> And have something consistent across the various supported platforms (x86, >> AMD64, ARM, M1, RISC-V, ...). >> >> Regards. [...] > > Where do you see tcc to be unstable? > > Yes, the last patch is ugly and should be removed or fixed > (path is created with alloca and later overwritten with malloc), > and that patch is only used as fallback, > when CONFIG_TCCDIR is undefined. > > Primary goals for tcc are: > * Compile to correct code, > * as fast as possible, > * while being as simple as possible > > > For memory leaks from malloc, which are only freed at program shutdown: > A design decision is not a bug. > * tcc is a short running program, > and a design decission to not free every memory from malloc > is also done by other compiler for speed reasons: > (look at DMC or DMD as examples.) > (i dont know, if both compiler do not free, but i can remember, > that walter bright wrote, not to free memory was his > design decision for speed reasons). > * things done in libtcc are different, > as the programm, which is using libtcc might live longer. > I would suggest to fix memory leaks in libtcc. > > > For using an object format, with is not the same, what most other compiler > use on that system: > A design decision, and not a bug > Disadvantage: > * You can't link object files from other compiler > Advantage: > * simplify the code generator, the linker and probably other tools > > This is also done by other compiler for many Years: > * Watcom/OpenWatcom uses OMF > * Embarcadero C++ Builder: > The newer compiler are based on clang > and use ELF object files also on Windows > > -- > Regards ... Detlef > > > _______________________________________________ > Tinycc-devel mailing list > Tinycc-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/tinycc-devel > > > _______________________________________________ > Tinycc-devel mailing list > Tinycc-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/tinycc-devel
_______________________________________________ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
