On Wed, 2025-10-22 at 10:38 +0200, Richard Biener wrote: > On Wed, Oct 22, 2025 at 8:41 AM Martin Uecker via Gcc > <[email protected]> wrote: > > > > Am Dienstag, dem 21.10.2025 um 18:58 -0400 schrieb David Malcolm > > via Gcc: > > > On Tue, 2025-10-21 at 22:32 +0200, Jose E. Marchesi via Gcc > > > wrote: > > ... > > > > > > > > For (b), messaging, for example, I see news sites picking up on > > > your > > > patch postings and there's been discussion in related forums that > > > could > > > be paraphrased about whether the gcc devs don't have better > > > things to > > > do with their time. I wonder if we need to explicitly state that > > > this > > > is intended as a fun retrocomputing side-project that serves the > > > greater good of ensuring that GCC can support many kinds of > > > programming > > > language, and to make it clear that what we're spending the bulk > > > of our > > > cycles on as upstream developers for GCC 16 are things like C++ > > > improvements (reflection support, better template errors), better > > > code > > > generation in general, and on specific targets, better support > > > for the > > > Linux kernel, etc. > > > > If there is enough interest to write and polish a FE, then, IMHO, > > this > > should already be justification enough to include it (assuming > > there are > > no other serious concerns about technical aspects or others > > concerns why this adds specific problems). If the GCC community is > > so weak > > that we can not accept such a gift without worrying maintenance > > burden, > > is has much more serious problems. If it can, but GCC judges the > > value > > of such contributions only based on some narrow idea of economic > > interests > > or utility for some parts of the industry, then it is on the way > > towards > > irrelevancy as a free software project. > > > > So in terms of messaging, I think this is the point we should make: > > The > > GCC community is strong enough to support it even though it may not > > be > > the most important thing for the industry, and as a free software > > project is also allows the community to contribute meaningfully > > based > > on its interests, and these contributions are not simply rejected > > because some part of the industry may not see it as important for > > the > > future. > > I wholeheartedly agree here. With open source the power is to those > who > do the work. And GCCs mission statement supports this. > > If ports or languages start to bitrot and are no longer maintained we > can, > will and have in the past, rip them out again. > > As to diagnostics subsystem support, David, while it's nice if you do > not > break Algol68 build you are not required to care but instead help > from > respective frontend maintainers is expected. Giving heads-up is > nice, > but fixing after-the-fact by the maintainers is good enough here. We > do > have a set of default languages for a reason (likewise a set of > primary and secondary targets). I do not ever expect the Algol68 > frontend to become a tier 1 language, aka any issue becoming release > critical.
Hi Richard Looking at https://gcc.gnu.org/gcc-16/criteria.html the "Language" section currently gives special priority to C and C++ in terms of "release criteria", and then the section "Primary and Secondary Platforms" talks about primary, secondary, and tertiary platforms and has definitions of release criteria. So it seems that we currently have primary and secondary languages, where C and C++ are primary and the others are all secondary. I wonder if we could introduce a concept of a "tertiary" language for these criteria? (for Algol68) This might help set expectations here. The "criteria.html" page above talks about *release* criteria. A related but separate concern is the health of trunk - we don't want to break the build, and as a community we rightly are concerned about making sure that trunk builds on a wide variety of configurations (AFAIK this was historically one of the motivations for the egcs fork, right?) Is there a page spelling out expectations on maintainers here? For example, when I do bootstrap and regression-testing of a patch, I currently have: --enable-host-shared \ --enable-libgdiagnostics \ --enable-languages=\ cobol,c,c++,d,objc,objc++,fortran,ada,go,lto,jit,rust,m2 (note that --enable-languages=all is *not* all languages, as IIRC at least jit is omitted; maybe --enable-languages= could gain "primary", "secondary" and "tertiary" args?) Perhaps the "criteria.html" page could be split up by development stage? I try to test my patches well, and to promptly fix things when something slips through and I do break the build of trunk (sorry!). If there's an expectation that I don't need to enable Algol68 in my testing (which would save CPU cycles and disk space), it might be good to document this. This might also benefit new contributors; a common question in GSoC is how should a patch be tested, and how much should it be tested (do we document that somewhere? It might be in my newcomers' guide) I should probably also mention that I've been experimenting with an "example" frontend, the idea being something that could live in the source tree and be maintained, to be an example for people to copy and refer to when implementing their own frontends. But it's nowhere close to being ready for GCC 16 as I write this (and I have plenty of higher priority work). Hope this is constructive Dave > > Richard. > > > My 2 cents. > > > > Martin > > > > > > > > > > I hope this is constructive criticism; I'm sorry if it comes > > > across as > > > dunking on your project, and again, this is just my personal > > > opinion. > > > > > > Dave > > > > > > > > > > > > > > > > > Stage 1 of GCC 16 is almost over, so hereby we are asking the > > > > SC to > > > > please consider accepting the contribution of the front-end in > > > > its > > > > current form, which hopefully this time will be considered > > > > mature > > > > enough > > > > as to not be a burden once integrated. > > > > > > > > There is still a lot of work to do and it is not our intention > > > > to nag > > > > the committee nor the community with this; we could certainly > > > > stay > > > > off-tree for more cycles, and we will do it if we have to, but > > > > we > > > > really > > > > are eager to be in-tree as it would make implementing modules > > > > and > > > > other > > > > advanced features, that are next in our TODO now that the > > > > support for > > > > the core language has been completed, so much easier. > > > > > > > > I of course offer my personal commitment to maintain the front- > > > > end > > > > responsibly and timely, to the best of my limited abilities and > > > > even > > > > more limited availability. > > > > > > > > Thank you for considering! > > > > > > > > [1] Front-end homepage: > > > > https://gcc.gnu.org/wiki/Algol68FrontEnd > > > > > > > > [2] Version 4 of the patch series in gcc-patches: > > > > > > > > https://gcc.gnu.org/pipermail/gcc-patches/2025-October/698011.html > > > > >
