Richard Biener <richard.guent...@gmail.com> writes:
Hello Richard,
many thanks for taking the time to review the patches and tarball.
> It looks like libgm2 is built independently on whether m2 is enabled or not?
> I'd like to see a while-listing of supported targets like done for example
> for libgomp via configure.tgt or for libgo (see toplevel configure).
ok thanks for the pointers - will do.
> The driver changes have been posted and reviewed previously but I
> didn't see any real OK there but motivational questions - they never
> were posted together with the m2 driver portion (I guess that would
> be gcc/m2/gm2spec.c in the tarball).
yes true.
> I've not seen reviews or postings (besides as tarball) of the frontend
> or the library (but I don't remember seeing extensive reviews of
> other languages frontends or runtime portions at the point of their
> inclusion - still the glueing to the middle-end should get the chance
> to be reviewed).
the glue code for gm2 is in the directory gcc/m2/gm2-gcc which is
implemented in C and associated matching C header and M2 definition
modules.
> I've tried to find my way through gcc/m2 but am quite lost in the
> number of subdirectories. I do see in gm2-lang.c and elsewhere
> inclusion of system headers outside of system.h which is going
> to be a portability problem.
ah thanks for spotting this - will fix.
> From the parse_file langhook we eventually dispatch to
> init_PerCompilationInit which looks like a Modula-2 scaffolding file?
> Is the compiler written in Modula-2?
yes mainly written in Modula-2, the sources are in gcc/m2/gm2-compiler,
core libraries are in gcc/m2/gm2-libs. These are converted into C++
files during the build using the translator in gcc/m2/mc (gcc/m2/mc-boot
C++ version). (For developers the Modula-2 compiler sources can be
built using stage1 gm2 later on). All libraries are eventually compiled
by gm2 for target of course.
> It's not clear what parts make up the interface to the GCC middle-end.
the interface to the GCC middle-end is in gcc/m2/gm2-gcc which are
called by the front end sources in gcc/m2/gm2-compiler. For example the
main declarations are performed by gcc/m2/gm2-compiler/M2GCCDeclare.mod
and the code trees are produced by gcc/m2/gm2-compiler/M2GenGCC.mod.
> I'm missing a patch for gcc/doc/install.texi which should list
> requirements plus a patch to sourcebuild.texi listing the new
> toplevel dirs (at least).
ah thank you yes I missed this.
> We don't usally ship "examples" in the GCC source tree,
> there's a gm2-tools directory which name suggests those are
> host tools which should usually reside in the toplevel.
ok sure, maybe best to move the examples into the regression test suite
and move the minimal number of gm2-tools required into the toplevel.
> There's copies of gpl and gpl-3.0.texi files in m2/ but I think
> all .texi stuff (even language specific) should be in gcc/doc/
> and not the lang specific subdirectory.
yes indeed sounds good and clean.
> I've just tried following the merge instructions and a build
> on SUSE Leap 15.2 produces a toplevel m2/ and stage{1,2,3,4}
> directories (empty?!) which hints at some bootstrapping magic taking place?
> In the end the build fails like the following in stage2
>
> bash: ..//home/rguenther/src/trunk/gcc/m2/tools-src/makeversion: No
> such file or directory
> make[3]: *** [/home/rguenther/src/trunk/gcc/m2/Make-lang.in:111:
> gm2version-check] Error 127
> make[3]: *** Waiting for unfinished jobs....
> /bin/sh: ..//home/rguenther/src/trunk/gcc/m2/configure: No such file
> or directory
> make[3]: *** [/home/rguenther/src/trunk/gcc/m2/Make-lang.in:1159:
> m2/gm2config.h] Error 127
>
> (sorry, parallel make), re-doing serial make ontop of the above yields
>
> bash: ..//home/rguenther/src/trunk/gcc/m2/tools-src/makeversion: No
> such file or directory
> make[3]: *** [/home/rguenther/src/trunk/gcc/m2/Make-lang.in:111:
> gm2version-check] Error 127
>
> looks like
>
> gm2version-check:
> cd m2 ; bash ../$(srcdir)/m2/tools-src/makeversion -p ../$(srcdir)
> $(STAMP) gm2version-check
>
> is bogus (in particular using $(srcdir) as part of a relative path?)
ah very sorry - yes - I'll fix this.
> I've just done ./configure --enable-languages=m2; make -j24
>
> I would suggest to not rush this in now during stage4
> but instead take the opportunity of this "quiet" phase
> to prepare an integration branch with all the issues above
> sorted out which we can merge at the beginning of stage1
> for GCC 12 (or later during stage4 if everyone is happy
> and/or backport for GCC 11.2 when it landed in trunk).
ok sure - this sounds a good plan
regards,
Gaius
