On Wed, Oct 22, 2025 at 5:15 PM David Malcolm <[email protected]> wrote: > > 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.
In fact there's no written down "tiering" and this part of the criteria has not been updated for a long time. > I wonder if we could introduce a concept of a "tertiary" language for > these criteria? (for Algol68) This might help set expectations here. I think we should clarify release criteria for non-C/C++ languages. Most of that falls out from the criteria for the target tiers - both primary and secondary targets are expected to bootstrap (or build in case of non-hosted targets) with the default set of languages chosen by configure (which can be target dependent). Any problem when deviating from this language configuration is not release critical (as in, we won't block the release for such an issue if it appears last minute). > 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 think this should be documented elsewhere, since it is not something that is version specific. Possibly develop.html is a good place. This would probably include adding a set of primary development host platforms which we handle strictest with respect to bootstrap/build breakage. Somewhere we document patch reversion policy, this is a good place to talk about such tiering. Like above, the default set of languages is what is important here IMO, because that's what we document as requirement to bootstrap and test when submitting patches. > 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). Heh, we had 'treelang' at some point. But sure this might be interesting, still I'd likely pick a "real" language for such a frontend. The most simplistic one wouldn't exercise most of the FE/middle-end interaction (exceptions come to my mind, but also nested functions or variable-length types or layout) or be quite a complicated beast. Most useful for GCC itself would be having a separate GIMPLE frontend (or 'GENERIC' frontend?), but that might be less suitable for a copy&paste boiler-plate. > Hope this is constructive Yes it is. I do think that our developer information on the webpages could use quite some TLC and refactoring to make it a) easier discoverable and b) less scattered and incomplete. Richard. > 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 > > > > > > > >
