On Tue, 2024-02-27 at 10:15 +0100, Richard Biener via Gcc wrote:
> On Fri, Feb 23, 2024 at 10:22 AM Miro Palmu via Gcc <gcc@gcc.gnu.org>
> wrote:
> >
> > Hi.
> >
> > I have a idea about long term hobby project relating to gcc,
> > so with this email I'm asking feedback about the idea
> > early rather than later. First little bit of context.
> >
> > I'm a student deep in a university course about compilers
> > and I have been writing a compiler for language
> > which is a subset of Herb Sutter's Cpp2.
> > I chose this because I'm bit of a Cpp language nerd,
> > and I can apply all of my Cpp knowledge to this project, which is
> > fun.
> >
> > After the course I'm interested in converting this to a front end
> > to gcc,
> > with goal of learning about front end development to gcc.
> > (It is a non-goal to try to upstream the project.)
> >
> > I don't see any obvious reason why this would not be possible.
> > It just need to be able to target (C++ version of ?) GENERIC.
> > This would be the first goal of the compiler
> > and would serve as the MVP of the project.
> > Below is discussing/theorizing post MVP goals.
>
> Note there is no textual form of GENERIC that a GCC compiler
> binary could parse. So your Cpp compiler would need to build
> GENERIC data structures itself, basically be a real GCC language
> frontend.
> The alternative is to use GCCs JIT but that emits GIMPLE only
FWIW libgccjit does build GENERIC internally, rather than GIMPLE, but
hides it all behind an API; the pertinent code is in gcc/jit/jit-
playback.{cc,h}
> (I think there's a rust frontend project that tries to leverage that,
> and also GNU emacs is using it).
[...]
>
