On Thu, Oct 23, 2025 at 10:23 AM Martin Uecker <[email protected]> wrote: > > Am Donnerstag, dem 23.10.2025 um 09:29 +0200 schrieb Richard Biener: > > On Wed, Oct 22, 2025 at 5:15 PM David Malcolm <[email protected]> wrote: > > ... > > > > > > > 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. > > If one would would remove Objective-C, OpenMP, various extensions, > and especially all support for out-dated language versions and > related forwards-backwards compatibility warnings from the C frontend, > it would also end up quite simple.
I think the important part of such an example frontend would be being up-to-date with respect to language <-> middle-end interfacing. If the C frontend is OK in that regard it would be a good recepie if the code with this interface is suitably separated from actual parsing and semantic analysis and possibly if there's some documentation about the frontend sources at least for that interfacing code (mostly the parser-to-interface side, the middle-end interfacing should be documented already) Richard. > > Martin
