Re: [PATCH] Modula-2 into the GCC tree on master

[Segher Boessenkool]

On Tue, Jun 22, 2021 at 12:41:27AM +0200, Jakub Jelinek wrote:
> On Mon, Jun 21, 2021 at 11:36:48PM +0100, Gaius Mulley via Gcc-patches wrote:
> > > : error: the file containing the definition module 
> > > <80><98>M2RTS
> > > <80><99> cannot be found
> > > compiler exited with status 1
> > > output is:
> > > : error: the file containing the definition module 
> > > <80><98>M2RTS
> > > <80><99> cannot be found
> > 
> > ah yes, it would be good to make it autoconf locale utf-8
> 
> No, whether gcc is configured on an UTF-8 capable terminal or using UTF-8
> locale doesn't imply whether it will actually be used in such a terminal
> later on.
> See e.g. gcc/intl.c (gcc_init_libintl) how it decides whether to use UTF-8
> or normal quotes.

Right, and I build and regcheck GCC with LANG=C (and no LC_*) so I
should never see anything translated at all, and nothing should generate
UTF-8 for me.


Segher

Re: [PATCH] Modula-2 into the GCC tree on master

[Gaius Mulley via Gcc-patches]

Jakub Jelinek  writes:

>
> On Mon, Jun 21, 2021 at 11:36:48PM +0100, Gaius Mulley via Gcc-patches wrote:
>> > : error: the file containing the definition module 
>> > <80><98>M2RTS
>> > <80><99> cannot be found
>> > compiler exited with status 1
>> > output is:
>> > : error: the file containing the definition module 
>> > <80><98>M2RTS
>> > <80><99> cannot be found
>>
>> ah yes, it would be good to make it autoconf locale utf-8
>
> No, whether gcc is configured on an UTF-8 capable terminal or using UTF-8
> locale doesn't imply whether it will actually be used in such a terminal
> later on.
> See e.g. gcc/intl.c (gcc_init_libintl) how it decides whether to use UTF-8
> or normal quotes.

thank you for the steer - and to avoid a mistake of confusing host and
build.  I've generated a small patch which works using gcc/intl.c
open_quote/close_quote.  Hopefully it improves the aesthetics on host
machines.

diff --git a/gcc-versionno/gcc/m2/ChangeLog b/gcc-versionno/gcc/m2/ChangeLog
index 25cee8ed..86a95270 100644
--- a/gcc-versionno/gcc/m2/ChangeLog
+++ b/gcc-versionno/gcc/m2/ChangeLog
@@ -1,3 +1,16 @@
+2021-06-22   Gaius Mulley 
+
+   * m2/gm2-compiler/M2ColorString.mod:  import open_quote and
+   close_quote from m2color.
+   * m2/gm2-gcc/m2color.c:  (open_quote) New function implemented.
+   (close_quote) New function implemented, both functions import
+   open and close quotes from gcc/intl.c to pick up whether the
+   host has utf-8 capability.
+   * m2/gm2-gcc/m2color.def:  (open_quote) New function defined.
+   (close_quote) New function defined.
+   * m2/gm2-gcc/m2color.h:  (open_quote) and (close_quote) provide C
+   prototypes for external functions.
+
 2021-06-21   Gaius Mulley 
 
* tools-src/calcpath:  (New file).
diff --git a/gcc-versionno/gcc/m2/gm2-compiler/M2ColorString.mod 
b/gcc-versionno/gcc/m2/gm2-compiler/M2ColorString.mod
index cecee131..f32ef88c 100644
--- a/gcc-versionno/gcc/m2/gm2-compiler/M2ColorString.mod
+++ b/gcc-versionno/gcc/m2/gm2-compiler/M2ColorString.mod
@@ -21,7 +21,7 @@ along with GNU Modula-2; see the file COPYING3.  If not see
 
 IMPLEMENTATION MODULE M2ColorString ;
 
-FROM m2color IMPORT colorize_start, colorize_stop ;
+FROM m2color IMPORT colorize_start, colorize_stop, open_quote, close_quote ;
 FROM DynamicStrings IMPORT InitString, InitStringCharStar,
ConCat, ConCatChar, Mark, string, KillString,
Dup, char, Length, Mult ;
@@ -70,7 +70,7 @@ END append ;
 
 PROCEDURE quoteOpen (s: String) : String ;
 BEGIN
-   RETURN ConCat (append (s, "quote"), Mark (InitString ("‘")))
+   RETURN ConCat (append (s, "quote"), Mark (InitStringCharStar (open_quote 
(
 END quoteOpen ;
 
 
@@ -82,7 +82,7 @@ PROCEDURE quoteClose (s: String) : String ;
 BEGIN
s := endColor (s) ;
s := append (s, "quote") ;
-   s := ConCat (s, Mark (InitString ("’"))) ;
+   s := ConCat (s, Mark (InitStringCharStar (close_quote ( ;
s := endColor (s) ;
RETURN s
 END quoteClose ;
diff --git a/gcc-versionno/gcc/m2/gm2-gcc/m2color.c 
b/gcc-versionno/gcc/m2/gm2-gcc/m2color.c
index ec58a4b7..72299e34 100644
--- a/gcc-versionno/gcc/m2/gm2-gcc/m2color.c
+++ b/gcc-versionno/gcc/m2/gm2-gcc/m2color.c
@@ -38,6 +38,18 @@ const char *m2color_colorize_stop (bool show_color)
 }
 
 
+const char *m2color_open_quote (void)
+{
+  return open_quote;
+}
+
+
+const char *m2color_close_quote (void)
+{
+  return close_quote;
+}
+
+
 void _M2_m2color_init ()
 {
 }
diff --git a/gcc-versionno/gcc/m2/gm2-gcc/m2color.def 
b/gcc-versionno/gcc/m2/gm2-gcc/m2color.def
index 6fa48d2a..a6e96e21 100644
--- a/gcc-versionno/gcc/m2/gm2-gcc/m2color.def
+++ b/gcc-versionno/gcc/m2/gm2-gcc/m2color.def
@@ -39,4 +39,16 @@ PROCEDURE colorize_start (show_color: BOOLEAN;
 PROCEDURE colorize_stop (show_color: BOOLEAN) : ADDRESS ;
 
 
+(* open_quote - return a C string containing the open quote character which
+   might be a UTF-8 character if on a UTF-8 supporting host.  *)
+
+PROCEDURE open_quote () : ADDRESS ;
+
+
+(* close_quote - return a C string containing the close quote character which
+   might be a UTF-8 character if on a UTF-8 supporting host.  *)
+
+PROCEDURE close_quote () : ADDRESS ;
+
+
 END m2color.
diff --git a/gcc-versionno/gcc/m2/gm2-gcc/m2color.h 
b/gcc-versionno/gcc/m2/gm2-gcc/m2color.h
index 08ef9e72..1b9be66b 100644
--- a/gcc-versionno/gcc/m2/gm2-gcc/m2color.h
+++ b/gcc-versionno/gcc/m2/gm2-gcc/m2color.h
@@ -37,9 +37,11 @@ along with GNU Modula-2; see the file COPYING3.  If not see
 
 
 EXTERN const char *m2color_colorize_start (bool show_color, char *name, 
unsigned int name_len);
-
 EXTERN const char *m2color_colorize_stop (bool show_color);
 
+EXTERN const char *m2color_open_quote (void);
+EXTERN const char *m2color_close_quote (void);
+
 EXTERN void _M2_m2color_init ();
 EXTERN void _M2_m2color_finish ();


regards,
Gaius

Re: [PATCH] Modula-2 into the GCC tree on master

[Jakub Jelinek via Gcc-patches]

On Mon, Jun 21, 2021 at 11:36:48PM +0100, Gaius Mulley via Gcc-patches wrote:
> > : error: the file containing the definition module 
> > <80><98>M2RTS
> > <80><99> cannot be found
> > compiler exited with status 1
> > output is:
> > : error: the file containing the definition module 
> > <80><98>M2RTS
> > <80><99> cannot be found
> 
> ah yes, it would be good to make it autoconf locale utf-8

No, whether gcc is configured on an UTF-8 capable terminal or using UTF-8
locale doesn't imply whether it will actually be used in such a terminal
later on.
See e.g. gcc/intl.c (gcc_init_libintl) how it decides whether to use UTF-8
or normal quotes.

Jakub

Re: [PATCH] Modula-2 into the GCC tree on master

[Gaius Mulley via Gcc-patches]

Segher Boessenkool  writes:

> On Sat, Jun 19, 2021 at 09:09:05AM -0500, Segher Boessenkool wrote:
>> powerpc64-linux now is building, and is running the tetsuite.  My
>> powerpc64le-linux build used --enable-languages=all, but Ada fails to
>> build, so I'll redo that without Ada.
>
> For powerpc64le-linux I get
>
> === gm2 tests ===
>
>
> Running target unix
> FAIL: gm2/pim/fail/TestLong4.mod,  -g
> FAIL: gm2/pim/fail/TestLong4.mod,  -O
> FAIL: gm2/pim/fail/TestLong4.mod,  -O -g
> FAIL: gm2/pim/fail/TestLong4.mod,  -Os
> FAIL: gm2/pim/fail/TestLong4.mod,  -O3 -fomit-frame-pointer
> FAIL: gm2/pim/fail/TestLong4.mod,  -O3 -fomit-frame-pointer -finline-functions
> FAIL: gm2/pimlib/logitech/run/pass/realconv.mod execution,  -g
> FAIL: gm2/pimlib/logitech/run/pass/realconv.mod execution,  -O
> FAIL: gm2/pimlib/logitech/run/pass/realconv.mod execution,  -O -g
> FAIL: gm2/pimlib/logitech/run/pass/realconv.mod execution,  -Os
> FAIL: gm2/pimlib/logitech/run/pass/realconv.mod execution,  -O3 
> -fomit-frame-pointer
> FAIL: gm2/pimlib/logitech/run/pass/realconv.mod execution,  -O3 
> -fomit-frame-pointer -finline-functions
>
> === gm2 Summary ===
>
> # of expected passes11610
> # of unexpected failures12
>
> So that is excellent, only two failing tests :-)

yes indeed - I see TestLong4.mod fail on some of my x86_64 test
machines.

> For BE there is more:
>
> A whole bunch of testcases fail to build (both 32-bit and 64-bit).  I
> don't know yet.
>
> The realconv.mod testcase fails at all optimisation levels (also -O0).
>
> setarith*.mod and setrotate*.mod and setshift*.mod and simple*.mod fail
> to build.  Also cardrange*.mod and intrange*.mod and multint*.mod and
> realrange*.mod and subrange.mod and cardrange.mod and forcheck.mod.
> And the extended-opaque tests.  And more :-)
>
> : error: the file containing the definition module <80><98>M2RTS
> <80><99> cannot be found
> compiler exited with status 1
> output is:
> : error: the file containing the definition module <80><98>M2RTS
> <80><99> cannot be found

ah yes, it would be good to make it autoconf locale utf-8

> (That is UTF-8 quotation marks, and I do not use an UTF-8 locale there
> btw.  That is just a cosmetic problem of course.)
>
> Does this have to do with gm2tools?

Ah just examined simple2.mod and yes absolutely [to the set test
failures] - gm2tools uses word sized set types to implement the first
and follow set recursive descent parsers.  simple2.mod is performing bit
exclusion on a word sized set and failing :-) - which is good news as
this should be easy to debug.  Thanks for testing!




regards,
Gaius

Re: [PATCH] Modula-2 into the GCC tree on master

[Gaius Mulley via Gcc-patches]

Segher Boessenkool  writes:

> Gaius, could you look through the two patches I did to get the build to
> work, see if those are correct or if something better needs to be done?
>
> 
> $(subdir) is an absolute path for me, so ../$(subdir) cannot work.

Hi Segher,

ah after more testing the patch will fail on a relative srcdir and the
configure has to be run in the m2 or m2/gm2-libs build directories.
I've pushed some changes onto the gm2 repro at savannah to fix this
which are included below.  Also included are the renaming changes to
getopt you suggested

regards,
Gaius


diff --git a/gcc-versionno/gcc/m2/ChangeLog b/gcc-versionno/gcc/m2/ChangeLog
index eeac1930..e523f307 100644
--- a/gcc-versionno/gcc/m2/ChangeLog
+++ b/gcc-versionno/gcc/m2/ChangeLog
@@ -1,4 +1,23 @@
-2021-06-19  Matthias Klose 
+2021-06-21   Gaius Mulley 
+
+   * tools-src/calcpath:  (New file).
+   * Make-lang.in:  (m2/gm2-libs/gm2-libs-host.h) use calcpath
+   to determine the srcdir of the new subdirectory.
+   (m2/gm2config.h) use calcpath
+   to determine the srcdir of the new subdirectory.
+   Fixes an error and based on a patch reported by Segher Boessenkool
+   .
+   * Make-lang.in:  (m2/gm2-libs/gm2-libs-host.h) Restore tabs.
+   * Make-lang.in:  (m2/gm2config.h) Restore tabs.
+   * Make-lang.in:  Replaced getopt.c by cgetopt.c.
+   * gm2-libs/getopt.def:  Renamed gm2-libs/cgetopt.def.
+   * gm2-libs-ch/getopt.c:  Renamed gm2-libs-ch/cgetopt.c.
+   Replaced getopt_ by cgetopt_.
+   Fixes an error reported by Segher Boessenkool
+   .
+   * tools-src/calcpath:  (Corrected header comment).
+
+2021-06-19   Matthias Klose 
 
* Make-lang.in:  introduce parallel linking.
* Make-lang.in (m2.serial): New target.
diff --git a/gcc-versionno/gcc/m2/Make-lang.in 
b/gcc-versionno/gcc/m2/Make-lang.in
index 58e5312e..298da26f 100644
--- a/gcc-versionno/gcc/m2/Make-lang.in
+++ b/gcc-versionno/gcc/m2/Make-lang.in
@@ -1179,9 +1179,11 @@ m2/gm2-libs-iso/%.o: $(srcdir)/m2/gm2-libs-iso/%.mod
 
 m2/gm2-libs/gm2-libs-host.h:
echo "Configuring to build libraries using native compiler" ; \
+NEW_SRCDIR=`${srcdir}/m2/tools-src/calcpath ../../ ${srcdir} 
m2/gm2-libs` ; \
+export NEW_SRCDIR ; \
 cd m2/gm2-libs ; \
-$(SHELL) -c '../../$(srcdir)/m2/gm2-libs/config-host \
-   --srcdir=../../$(srcdir)/m2/gm2-libs \
+$(SHELL) -c '$${NEW_SRCDIR}/config-host \
+   --srcdir=$${NEW_SRCDIR} \
--target=$(target) \
--program-suffix=$(exeext)'
 
@@ -1189,15 +1191,21 @@ m2/gm2-libs/gm2-libs-host.h:
 # cross compiler and the ../Makefile.in above appends this to INTERNAL_CFLAGS.
 
 m2/gm2config.h:
+   NEW_SRCDIR=`${srcdir}/m2/tools-src/calcpath ../ ${srcdir} m2` ; \
+export NEW_SRCDIR ; \
cd m2 ; \
if echo $(INTERNAL_CFLAGS) | grep \\-DCROSS_DIRECTORY_STRUCTURE; then \
-AR=`echo $(AR_FOR_TARGET) | sed -e "s/^ //"` ; \
+AR=$(echo $(AR_FOR_TARGET) | sed -e "s/^ //") ; \
 export AR ; \
-RANLIB=`echo $(RANLIB_FOR_TARGET) | sed -e "s/^ //"` ; \
+RANLIB=$(echo $(RANLIB_FOR_TARGET) | sed -e "s/^ //") ; \
 export RANLIB ; \
-$(SHELL) -c '../$(srcdir)/m2/configure --srcdir=../$(srcdir)/m2 
--target=$(target) --program-suffix=$(exeext) --includedir=$(SYSTEM_HEADER_DIR) 
--libdir=$(libdir) --libexecdir=$(libexecdir)' ; \
+$(SHELL) -c '$${NEW_SRCDIR}/configure --srcdir=$${NEW_SRCDIR} \
+--target=$(target) --program-suffix=$(exeext) \
+--includedir=$(SYSTEM_HEADER_DIR) --libdir=$(libdir) \
+--libexecdir=$(libexecdir)' ; \
 else \
-$(SHELL) -c '../$(srcdir)/m2/configure --srcdir=../$(srcdir)/m2 
--target=$(target) --program-suffix=$(exeext)' ; \
+$(SHELL) -c '$${NEW_SRCDIR}/configure --srcdir=$(NEW_SRCDIR) \
+--target=$(target) --program-suffix=$(exeext)' ; \
 fi
 
 $(objdir)/m2/gm2-libs-min/SYSTEM.def: $(GM2_PROG_DEP)
diff --git a/gcc-versionno/gcc/m2/gm2-libs-ch/getopt.c 
b/gcc-versionno/gcc/m2/gm2-libs-ch/cgetopt.c
similarity index 67%
rename from gcc-versionno/gcc/m2/gm2-libs-ch/getopt.c
rename to gcc-versionno/gcc/m2/gm2-libs-ch/cgetopt.c
index 1f483a72..205c0487 100644
--- a/gcc-versionno/gcc/m2/gm2-libs-ch/getopt.c
+++ b/gcc-versionno/gcc/m2/gm2-libs-ch/cgetopt.c
@@ -28,21 +28,21 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  
If not, see
 #include "system.h"
 #include "ansi-decl.h"
 
-char *getopt_optarg;
-int getopt_optind;
-int getopt_opterr;
-int getopt_optopt;
+char *cgetopt_optarg;
+int cgetopt_optind;
+int cgetopt_opterr;
+int cgetopt_optopt;
 
 
 char
-getopt_getopt (int argc, char *argv[], char *optstring)
+cgetopt_getopt (int argc, char *argv[], char 

Re: [PATCH] Modula-2 into the GCC tree on master

[Gaius Mulley via Gcc-patches]

Segher Boessenkool  writes:

> Hi!
>
> On Fri, Jun 18, 2021 at 10:00:40PM +0100, Gaius Mulley wrote:
>> Segher Boessenkool  writes:
>> > On Thu, Jun 17, 2021 at 11:26:41PM +0100, Gaius Mulley via Gcc-patches 
>> > wrote:
>> >> Debian Stretch using make -j 4, x86_64 GNU/Linux Debian Stretch built
>> >> using make -j 24 and also under x86_64 GNU/Linux Debian Buster using
>> >> make -j 4.
>> >
>> > I am building it on powerpc64-linux (-m32,-m64) and poweerpc64le-linux
>> > currently.  (All CentOS 7 fwiw).
>>
>> excellent the more varieties the better - I'm eagerly awaiting a risc-v
>> motherboard which might also be interesting
>
> I needed a few fixes to get it to build, they are in my branch
> (https://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=users/segher/heads/gm2)
>
> The files gm2-libs/getopt.def and gm2-libs/GetOpt.def have filenames
> that differ case only, this is censored by the scripts that we run on
> the Git server.  I renamed the former to cgetopt.def for now, but of
> course more changes are needed for this to work at all.

Hi Segher,

ah yes thanks for spotting this - I recall I had a similar issue with
SYSTEM.def will change to getopt.def to cgetopt.def.

>> > It does not want to build gm2tools, haven't investigated that yet
>> > either.
>
> Not yet :-)
>
>> > Will report results later.
>
> powerpc64-linux now is building, and is running the tetsuite.  My
> powerpc64le-linux build used --enable-languages=all, but Ada fails to
> build, so I'll redo that without Ada.
>
> Gaius, could you look through the two patches I did to get the build to
> work, see if those are correct or if something better needs to be done?
>
> 
> $(subdir) is an absolute path for me, so ../$(subdir) cannot work.

this looks sensible - I'll also test and apply this on a few machines.

> 
> Maybe your texinfo is less picky than mine, I use an older one (5.1)?

(Debian buster texinfo is on 6.5.0 and Debian stretch is on 6.3.0).  But
the up node was inconsistent :-), again thanks for these up node fixes.

I will rebuild on aarch64 (Debian stretch), x86_64 Debian stretch and
x86_64 Debian buster and make source changes for cgetopt.def etc.


regards,
Gaius

Re: [PATCH] Modula-2 into the GCC tree on master

[Segher Boessenkool]

On Sat, Jun 19, 2021 at 09:09:05AM -0500, Segher Boessenkool wrote:
> powerpc64-linux now is building, and is running the tetsuite.  My
> powerpc64le-linux build used --enable-languages=all, but Ada fails to
> build, so I'll redo that without Ada.

For powerpc64le-linux I get

=== gm2 tests ===


Running target unix
FAIL: gm2/pim/fail/TestLong4.mod,  -g  
FAIL: gm2/pim/fail/TestLong4.mod,  -O  
FAIL: gm2/pim/fail/TestLong4.mod,  -O -g  
FAIL: gm2/pim/fail/TestLong4.mod,  -Os  
FAIL: gm2/pim/fail/TestLong4.mod,  -O3 -fomit-frame-pointer  
FAIL: gm2/pim/fail/TestLong4.mod,  -O3 -fomit-frame-pointer -finline-functions  
FAIL: gm2/pimlib/logitech/run/pass/realconv.mod execution,  -g 
FAIL: gm2/pimlib/logitech/run/pass/realconv.mod execution,  -O 
FAIL: gm2/pimlib/logitech/run/pass/realconv.mod execution,  -O -g 
FAIL: gm2/pimlib/logitech/run/pass/realconv.mod execution,  -Os 
FAIL: gm2/pimlib/logitech/run/pass/realconv.mod execution,  -O3 
-fomit-frame-pointer 
FAIL: gm2/pimlib/logitech/run/pass/realconv.mod execution,  -O3 
-fomit-frame-pointer -finline-functions 

=== gm2 Summary ===

# of expected passes11610
# of unexpected failures12

So that is excellent, only two failing tests :-)

For BE there is more:

A whole bunch of testcases fail to build (both 32-bit and 64-bit).  I
don't know yet.

The realconv.mod testcase fails at all optimisation levels (also -O0).

setarith*.mod and setrotate*.mod and setshift*.mod and simple*.mod fail
to build.  Also cardrange*.mod and intrange*.mod and multint*.mod and
realrange*.mod and subrange.mod and cardrange.mod and forcheck.mod.
And the extended-opaque tests.  And more :-)

: error: the file containing the definition module <80><98>M2RTS
<80><99> cannot be found
compiler exited with status 1
output is:
: error: the file containing the definition module <80><98>M2RTS
<80><99> cannot be found

(That is UTF-8 quotation marks, and I do not use an UTF-8 locale there
btw.  That is just a cosmetic problem of course.)

Does this have to do with gm2tools?


Segher

Re: [PATCH] Modula-2 into the GCC tree on master

[Segher Boessenkool]

Hi!

On Fri, Jun 18, 2021 at 10:00:40PM +0100, Gaius Mulley wrote:
> Segher Boessenkool  writes:
> > On Thu, Jun 17, 2021 at 11:26:41PM +0100, Gaius Mulley via Gcc-patches 
> > wrote:
> >> Debian Stretch using make -j 4, x86_64 GNU/Linux Debian Stretch built
> >> using make -j 24 and also under x86_64 GNU/Linux Debian Buster using
> >> make -j 4.
> >
> > I am building it on powerpc64-linux (-m32,-m64) and poweerpc64le-linux
> > currently.  (All CentOS 7 fwiw).
> 
> excellent the more varieties the better - I'm eagerly awaiting a risc-v
> motherboard which might also be interesting

I needed a few fixes to get it to build, they are in my branch
().

The files gm2-libs/getopt.def and gm2-libs/GetOpt.def have filenames
that differ case only, this is censored by the scripts that we run on
the Git server.  I renamed the former to cgetopt.def for now, but of
course more changes are needed for this to work at all.

> > It does not want to build gm2tools, haven't investigated that yet
> > either.

Not yet :-)

> > Will report results later.

powerpc64-linux now is building, and is running the tetsuite.  My
powerpc64le-linux build used --enable-languages=all, but Ada fails to
build, so I'll redo that without Ada.

Gaius, could you look through the two patches I did to get the build to
work, see if those are correct or if something better needs to be done?


$(subdir) is an absolute path for me, so ../$(subdir) cannot work.


Maybe your texinfo is less picky than mine, I use an older one (5.1)?


Segher

Re: [PATCH] Modula-2 into the GCC tree on master

[Matthias Klose]

On 6/19/21 9:53 AM, Gaius Mulley wrote:
> Matthias Klose  writes:
> 
>> x86_64-linux-gnu-g++-10 is the compiler used for the bootstrap.  I haven't
>> checked if that is also seen for a normal bootstrap. Apparently it tries to
>> re-bootstrap the compiler.
>>
>> The build is configured with --with-build-config=bootstrap-lto-lean, built 
>> with
>> make profiledbootstrap-lean
> 
> many thanks for the patch - committed.  I've also fixed the make install
> bug (causing the re-bootstrap mentioned above),

the build now fails already in stage1 with

[...]
gm2.a m2/mc-boot-ch/Glibc.o m2/mc-boot-ch/Gmcrts.o libcommon.a
../libcpp/libcpp.a   ../libbacktrace/.libs/libbacktrace.a
../libiberty/libiberty.a ../libdecnumber/libdecnumber.a  -lm
/usr/bin/x86_64-linux-gnu-ld: cannot find libcommon.a: No such file or directory
collect2: error: ld returned 1 exit status

Matthias

Re: [PATCH] Modula-2 into the GCC tree on master

[Gaius Mulley via Gcc-patches]

Matthias Klose  writes:

> x86_64-linux-gnu-g++-10 is the compiler used for the bootstrap.  I haven't
> checked if that is also seen for a normal bootstrap. Apparently it tries to
> re-bootstrap the compiler.
>
> The build is configured with --with-build-config=bootstrap-lto-lean, built 
> with
> make profiledbootstrap-lean

many thanks for the patch - committed.  I've also fixed the make install
bug (causing the re-bootstrap mentioned above),




regards,
Gaius

Re: [PATCH] Modula-2 into the GCC tree on master

[Gaius Mulley via Gcc-patches]

Matthias Klose  writes:

>
> I checked that with a profiled lto build.  The build succeeds with the 
> attached
> patch to respect the parallel linking limitations, which you can configure 
> with
> --enable-link-serialization=N
>
> However the build fails in the installation step with:
>
> [...]
> Linking stage1/m2/cc1gm2 |--| 0%
> x86_64-linux-gnu-g++-10 -std=c++11 -no-pie   -g -O2 -DIN_GCC-W -Wall
> -Wno-narrowing -Wwrite-strings -Wcast-q
> ual -Wno-error=format-diag -Wstrict-prototypes -Wmissing-prototypes
> -Wno-error=format-diag  -Wold-style-definition -Wc++-compat -
> fno-common  -DHAVE_CONFIG_H  -o stage1/m2/cc1gm2 m2/gm2-lang.o 
> m2/stor-layout.o
> m2/m2pp.o m2/gm2-gcc/m2assert.o m2/gm2-gcc/m2block.o m2/gm2-gcc/m2builtins.o
> m2/gm2-gcc/m2except.o m2/gm2-gcc/m2convert.o m2/gm2-gcc/m2color.o
> m2/gm2-gcc/m2decl.o m2/gm2-gcc/m2expr.o m2/gm2-gcc/m2linemap.o
> m2/gm2-gcc/m2statement.o m2/gm2-gcc/m2type.o m2/gm2-gcc/m2tree.o
> m2/gm2-gcc/m2treelib.o m2/gm2-gcc/m2top.o m2/gm2-gcc/m2misc.o 
> m2/gm2-gcc/init.o
> m2/gm2-compiler-boot/m2flex.o \
> attribs.o \
>  m2/gm2-compiler-boot/gm2.a
> m2/gm2-libs-boot/libgm2.a m2/mc-boot-ch/Glibc.o m2/mc-boot-ch/Gmcrts.o
> m2/gm2-gcc/rtegraph.o \
>  libbackend.a main.o libcommon-target.a 
> libcommon.a
> ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a 
> ../libcpp/libcpp.a
>   ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a
> ../libdecnumber/libdecnumber.a  -lisl -lmpc -lmpfr -lgmp -rdynamic -ldl  -lz 
> -lzstd
> lto1: fatal error: bytecode stream in file 'm2/gm2-compiler-boot/m2flex.o'
> generated with LTO version 12.0 instead of the expected 9.2
> compilation terminated.
> lto-wrapper: fatal error: x86_64-linux-gnu-g++-10 returned 1 exit status
> compilation terminated.
> /usr/bin/ld: error: lto-wrapper failed
> collect2: error: ld returned 1 exit status
> Command exited with non-zero status 1
>
> x86_64-linux-gnu-g++-10 is the compiler used for the bootstrap.  I haven't
> checked if that is also seen for a normal bootstrap. Apparently it tries to
> re-bootstrap the compiler.
>
> The build is configured with --with-build-config=bootstrap-lto-lean, built 
> with
> make profiledbootstrap-lean

Hi Matthias,

thanks for the patch - I will re-examine the install - there is
definitely something odd going on.  On one of my machines it always
wants to rebuild gcc/m2/gm2-lang.o and falls over and on another (same
release - same gcc version 6.3.0 20170516 - debian stretch) it succeeds.

Thanks for the tips on --enable-link-serialization=N,


regards,
Gaius

Re: [PATCH] Modula-2 into the GCC tree on master

[Gaius Mulley via Gcc-patches]

Segher Boessenkool  writes:

> Hi Gaius,
>
> On Thu, Jun 17, 2021 at 11:26:41PM +0100, Gaius Mulley via Gcc-patches wrote:
>> here are a set of patches which merge the gm2 front end into the
>> GCC tree.
>
> I have looked through the patches in this email, and they all look good
> too me.  (There are a few warnings about whitespace from "git am", I
> haven't looked if those are from your code, or auto-generated).

ah thanks - yes I'll try and avoid generating whitespace diff hunks

>> The patches have been bootstrapped under aarch64 GNU/Linux
>> Debian Stretch using make -j 4, x86_64 GNU/Linux Debian Stretch built
>> using make -j 24 and also under x86_64 GNU/Linux Debian Buster using
>> make -j 4.
>
> I am building it on powerpc64-linux (-m32,-m64) and poweerpc64le-linux
> currently.  (All CentOS 7 fwiw).

excellent the more varieties the better - I'm eagerly awaiting a risc-v
motherboard which might also be interesting

> It does not want to build gm2tools, haven't investigated that yet
> either.
>
> Will report results later.  Thanks for your persistence!

many thanks for trying it and your patience,


regards,
Gaius

Re: [PATCH] Modula-2 into the GCC tree on master

[Gaius Mulley via Gcc-patches]

Richard Biener  writes:

>> > 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).
>
> So as suggested above please create a public branch off trunk where you
> do the integration and keep it rebased on trunk regularly.  It looks
> like you do not have write access to the GCC repository, please
> obtain that and make yourself familiar with the repository and
> branch layout.

ok thanks - will do.  Incidentally there is a nightly rebase
automatically performed on

git clone http://floppsie.comp.glam.ac.uk/gm2 combined-repro-gcc

with a number of branches.  git checkout remotes/origin/gm2-master
obtains gcc 12, it runs about 24 hours behind gcc and the gm2 repro.

I'll create a public branch on gcc.gnu.org and keep it up to date.

> I see there are copyright disclaimers and assignments to the FSF
> for you though for GCC I see specific changes rather than
> boiler-plate "past and future changes".  Fortunately we now have
> a DCO in place so I suggest to make sure to annotate commits
> to areas you did not assign copyright with appropriate Signed-Off-By
> lines - or maybe for simplicity apply that to all commits.

good idea - as you say fortunate the DCO came along - impeccable timing
:-).  I will use a DCO on all commits to be safe,

> The SC may also have comments here.
>
> Basically I'd like to see the merged state accessible on a branch.
>
> Thanks,
> Richard.


regards,
Gaius

Re: [PATCH] Modula-2 into the GCC tree on master

[Segher Boessenkool]

On Fri, Jun 18, 2021 at 12:52:41PM +0200, Richard Biener wrote:
> So as suggested above please create a public branch off trunk where you
> do the integration and keep it rebased on trunk regularly.  It looks
> like you do not have write access to the GCC repository, please
> obtain that and make yourself familiar with the repository and
> branch layout.

I've pushed a branch with the patches in the first post in this thread
to users/segher/heads/gm2 .  Maybe it can help; I'll delete it to reduce
confusion when something more official shows up :-)

> I see there are copyright disclaimers and assignments to the FSF
> for you though for GCC I see specific changes rather than
> boiler-plate "past and future changes".  Fortunately we now have
> a DCO in place so I suggest to make sure to annotate commits
> to areas you did not assign copyright with appropriate Signed-Off-By
> lines - or maybe for simplicity apply that to all commits.

It is spelled Signed-off-by: (one capital only).


Segher

Re: [PATCH] Modula-2 into the GCC tree on master

[Segher Boessenkool]

Hi Gaius,

On Thu, Jun 17, 2021 at 11:26:41PM +0100, Gaius Mulley via Gcc-patches wrote:
> here are a set of patches which merge the gm2 front end into the
> GCC tree.

I have looked through the patches in this email, and they all look good
too me.  (There are a few warnings about whitespace from "git am", I
haven't looked if those are from your code, or auto-generated).

> The patches have been bootstrapped under aarch64 GNU/Linux
> Debian Stretch using make -j 4, x86_64 GNU/Linux Debian Stretch built
> using make -j 24 and also under x86_64 GNU/Linux Debian Buster using
> make -j 4.

I am building it on powerpc64-linux (-m32,-m64) and poweerpc64le-linux
currently.  (All CentOS 7 fwiw).

It does not want to build gm2tools, haven't investigated that yet
either.

Will report results later.  Thanks for your persistence!


Segher

Re: [PATCH] Modula-2 into the GCC tree on master

[Richard Biener]

On Thu, 17 Jun 2021, Gaius Mulley wrote:

> 
> 
> Hello Richard, David, Matthias and GCC Steering Committee,
> 
> here are a set of patches which merge the gm2 front end into the
> GCC tree.  The patches have been bootstrapped under aarch64 GNU/Linux
> Debian Stretch using make -j 4, x86_64 GNU/Linux Debian Stretch built
> using make -j 24 and also under x86_64 GNU/Linux Debian Buster using
> make -j 4.
> 
> Tested on Debian Stretch x86_64
> ===
> 
> built GCC bootstrap 3 times:
> 
> 1.  built vanilla GCC (enabling bootstrap) enabling front ends:
> c,c++,go,d,fortran and ran the regression tests.  (make -j 4).
> 
> 2.  the patches below were applied and associated tarball untarred.
> The same front ends c,c++,go,d,fortran (again building from
> bootstrap) were enabled (no m2) and ran the regression tests.
> There were no changes to the regression test results between 1 and
> 2.
> 
> 3.  Then it was rebuilt (from bootstrap) enabling the front ends
> c,c++,go,d,fortran,m2 and ran the
> regression tests and again no extra failures were seen.
> 
> 4.  It has been built in source tree (./configure --enable-languages=m2)
> and out of source tree with make -j 24.
> 
> Built on Debian Buster x86_64
> =
> 
> 1.  built vanilla GCC (enabling bootstrap) enabling front ends:
> c,c++,go,d,fortran and ran the regression tests.
> 
> 2.  the patches below were applied and associated tarball untarred.
> The same front ends c,c++,go,d,fortran (again building from
> bootstrap) were enabled (no m2) and ran the regression tests.
> There were no changes to the regression test results between 1 and
> 2.
> 
> 3.  Then it was rebuilt (from bootstrap) enabling the front ends
> c,c++,go,d,fortran,m2 and ran the
> regression tests and again no extra failures were seen.
> 
> Built a patched tree enabling bootstrap make -j 4 for front ends
> c,c++,m2 all compiled and bootstrapped.
> 
> How to merge
> 
> 
> 1.  apply patches below to the master GCC tree.
> 
> 2.  cd gcc-git-top
> 
> wget http://floppsie.comp.glam.ac.uk/download/c/gm2-front-end-20210617-tar.gz
> 
> tar zxf gm2-front-end-20210617-tar.gz
> rm gm2-front-end-20210617-tar.gz
> # new directories gm2tools, libgm2, gcc/m2, gcc/testsuite/gm2 are created
> # and populated.  Documentation in gcc/doc and testsuite/lib contains some
> # Modula-2 dejagnu scripts.
> 
> 3.  cd gcc-git-top
> autogen Makefile.def
> autoconf
> cd libgm2
> /bin/sh ./autogen.sh
> cd ../gm2tools
> /bin/sh ./autogen.sh
> 
> Thank you Richard for the extensive feedback from the last time the
> patches were posted.  I've gone though your points and addressed them
> (I think).
> 
> > 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).
> 
> I've added a test in libgm2/configure.ac to restict the building of
> libgm2 - or to restrict it to building libm2min which is a near zero
> runtime library.  It restricts on host and target and can easily be
> changed.
> 
> > 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 gcc/m2/gm2spec.c.
> 
> > 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 is in m2/gm2-gcc/*.[ch].  The filenames adopt a similar
> naming scheme to other front ends: m2/gm2-gcc/m2decl.c for
> declarations, m2/gm2-gcc/m2expr.c for expressions etc.  The exported
> names are prefixed by the module name so that the code can be linked
> against the Modula-2 version with an appropriate definition module
> (for example m2/gm2-gcc/m2expr.def).
> 
> > I've tried to find my way through gcc/m2 but am quite lost in the
> > number of subdirectories.
> 
> I've added a README in each directory giving an overview of the
> contents.
> 
> > 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.
> 
> I've changed nearly all headers to use "config.h", "system.h" and
> friends and modified the bootstrap tool to automatically generate
> these gcc header includes.
> 
> > From the parse_file langhook we eventually dispatch to
> > init_PerCompilationInit which looks like a Modula-2 scaffolding
> > file?
> 
> yes indeed.
> 
> > Is the compiler written in Modula-2?  It's not clear what
> > parts make up the interface to the GCC 

Re: [PATCH] Modula-2 into the GCC tree on master

[Matthias Klose]

On 6/18/21 12:26 AM, Gaius Mulley wrote:
> 
> 
> Hello Richard, David, Matthias and GCC Steering Committee,
> 
> here are a set of patches which merge the gm2 front end into the
> GCC tree.  The patches have been bootstrapped under aarch64 GNU/Linux
> Debian Stretch using make -j 4, x86_64 GNU/Linux Debian Stretch built
> using make -j 24 and also under x86_64 GNU/Linux Debian Buster using
> make -j 4.
> 
> Tested on Debian Stretch x86_64
> ===
> 
> built GCC bootstrap 3 times:
> 
> 1.  built vanilla GCC (enabling bootstrap) enabling front ends:
> c,c++,go,d,fortran and ran the regression tests.  (make -j 4).
> 
> 2.  the patches below were applied and associated tarball untarred.
> The same front ends c,c++,go,d,fortran (again building from
> bootstrap) were enabled (no m2) and ran the regression tests.
> There were no changes to the regression test results between 1 and
> 2.
> 
> 3.  Then it was rebuilt (from bootstrap) enabling the front ends
> c,c++,go,d,fortran,m2 and ran the
> regression tests and again no extra failures were seen.
> 
> 4.  It has been built in source tree (./configure --enable-languages=m2)
> and out of source tree with make -j 24.
> 
> Built on Debian Buster x86_64
> =
> 
> 1.  built vanilla GCC (enabling bootstrap) enabling front ends:
> c,c++,go,d,fortran and ran the regression tests.
> 
> 2.  the patches below were applied and associated tarball untarred.
> The same front ends c,c++,go,d,fortran (again building from
> bootstrap) were enabled (no m2) and ran the regression tests.
> There were no changes to the regression test results between 1 and
> 2.
> 
> 3.  Then it was rebuilt (from bootstrap) enabling the front ends
> c,c++,go,d,fortran,m2 and ran the
> regression tests and again no extra failures were seen.
> 
> Built a patched tree enabling bootstrap make -j 4 for front ends
> c,c++,m2 all compiled and bootstrapped.

I checked that with a profiled lto build.  The build succeeds with the attached
patch to respect the parallel linking limitations, which you can configure with
--enable-link-serialization=N

However the build fails in the installation step with:

[...]
Linking stage1/m2/cc1gm2 |--| 0%
x86_64-linux-gnu-g++-10 -std=c++11 -no-pie   -g -O2 -DIN_GCC-W -Wall
-Wno-narrowing -Wwrite-strings -Wcast-q
ual -Wno-error=format-diag -Wstrict-prototypes -Wmissing-prototypes
-Wno-error=format-diag  -Wold-style-definition -Wc++-compat -
fno-common  -DHAVE_CONFIG_H  -o stage1/m2/cc1gm2 m2/gm2-lang.o m2/stor-layout.o
m2/m2pp.o m2/gm2-gcc/m2assert.o m2/gm2-gcc/m2block.o m2/gm2-gcc/m2builtins.o
m2/gm2-gcc/m2except.o m2/gm2-gcc/m2convert.o m2/gm2-gcc/m2color.o
m2/gm2-gcc/m2decl.o m2/gm2-gcc/m2expr.o m2/gm2-gcc/m2linemap.o
m2/gm2-gcc/m2statement.o m2/gm2-gcc/m2type.o m2/gm2-gcc/m2tree.o
m2/gm2-gcc/m2treelib.o m2/gm2-gcc/m2top.o m2/gm2-gcc/m2misc.o m2/gm2-gcc/init.o
m2/gm2-compiler-boot/m2flex.o \
attribs.o \
 m2/gm2-compiler-boot/gm2.a
m2/gm2-libs-boot/libgm2.a m2/mc-boot-ch/Glibc.o m2/mc-boot-ch/Gmcrts.o
m2/gm2-gcc/rtegraph.o \
 libbackend.a main.o libcommon-target.a libcommon.a
../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a ../libcpp/libcpp.a
  ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a
../libdecnumber/libdecnumber.a  -lisl -lmpc -lmpfr -lgmp -rdynamic -ldl  -lz 
-lzstd
lto1: fatal error: bytecode stream in file 'm2/gm2-compiler-boot/m2flex.o'
generated with LTO version 12.0 instead of the expected 9.2
compilation terminated.
lto-wrapper: fatal error: x86_64-linux-gnu-g++-10 returned 1 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
Command exited with non-zero status 1

x86_64-linux-gnu-g++-10 is the compiler used for the bootstrap.  I haven't
checked if that is also seen for a normal bootstrap. Apparently it tries to
re-bootstrap the compiler.

The build is configured with --with-build-config=bootstrap-lto-lean, built with
make profiledbootstrap-lean


Matthias



2021-06-18  Matthias Klose  

	* Make-lang.in (m2.serial): New target.
	(cc1gm2): Depend on $(m2.prev).
	(stageN/m2/cc1gm2): Call LLINKER, also call LINK_PROGRESS.

--- a/gcc/m2/Make-lang.in
+++ b/gcc/m2/Make-lang.in
@@ -82,6 +82,7 @@ TEXISRC = $(objdir)/m2/images/gnu.eps \
 # Define the names for selecting GNU Modula-2 in LANGUAGES.
 m2 modula-2 modula2: gm2$(exeext) xgcc$(exeext) cc1gm2$(exeext) \
  $(GCC_TOOLS_FOR_GM2)
+m2.serial = cc1gm2$(exeext)
 
 # Tell GNU make to ignore these if they exist.
 .PHONY: m2 modula-2 modula2
@@ -530,7 +531,7 @@ GM2_LIBS_PARANOID = m2/gm2-compiler-para
 
 gm2.paranoid: stage3/m2/cc1gm2$(exeext) gm2.verifyparanoid
 
-cc1gm2$(exeext): stage1/m2/cc1gm2$(exeext)
+cc1gm2$(exeext): stage1/m2/cc1gm2$(exeext) $(m2.prev)
 	cp -p $< $@
 
 gm2lcc$(exeext): 

[PATCH] Modula-2 into the GCC tree on master

[Gaius Mulley via Gcc-patches]

Hello Richard, David, Matthias and GCC Steering Committee,

here are a set of patches which merge the gm2 front end into the
GCC tree.  The patches have been bootstrapped under aarch64 GNU/Linux
Debian Stretch using make -j 4, x86_64 GNU/Linux Debian Stretch built
using make -j 24 and also under x86_64 GNU/Linux Debian Buster using
make -j 4.

Tested on Debian Stretch x86_64
===

built GCC bootstrap 3 times:

1.  built vanilla GCC (enabling bootstrap) enabling front ends:
c,c++,go,d,fortran and ran the regression tests.  (make -j 4).

2.  the patches below were applied and associated tarball untarred.
The same front ends c,c++,go,d,fortran (again building from
bootstrap) were enabled (no m2) and ran the regression tests.
There were no changes to the regression test results between 1 and
2.

3.  Then it was rebuilt (from bootstrap) enabling the front ends
c,c++,go,d,fortran,m2 and ran the
regression tests and again no extra failures were seen.

4.  It has been built in source tree (./configure --enable-languages=m2)
and out of source tree with make -j 24.

Built on Debian Buster x86_64
=

1.  built vanilla GCC (enabling bootstrap) enabling front ends:
c,c++,go,d,fortran and ran the regression tests.

2.  the patches below were applied and associated tarball untarred.
The same front ends c,c++,go,d,fortran (again building from
bootstrap) were enabled (no m2) and ran the regression tests.
There were no changes to the regression test results between 1 and
2.

3.  Then it was rebuilt (from bootstrap) enabling the front ends
c,c++,go,d,fortran,m2 and ran the
regression tests and again no extra failures were seen.

Built a patched tree enabling bootstrap make -j 4 for front ends
c,c++,m2 all compiled and bootstrapped.

How to merge


1.  apply patches below to the master GCC tree.

2.  cd gcc-git-top

wget http://floppsie.comp.glam.ac.uk/download/c/gm2-front-end-20210617-tar.gz

tar zxf gm2-front-end-20210617-tar.gz
rm gm2-front-end-20210617-tar.gz
# new directories gm2tools, libgm2, gcc/m2, gcc/testsuite/gm2 are created
# and populated.  Documentation in gcc/doc and testsuite/lib contains some
# Modula-2 dejagnu scripts.

3.  cd gcc-git-top
autogen Makefile.def
autoconf
cd libgm2
/bin/sh ./autogen.sh
cd ../gm2tools
/bin/sh ./autogen.sh

Thank you Richard for the extensive feedback from the last time the
patches were posted.  I've gone though your points and addressed them
(I think).

> 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).

I've added a test in libgm2/configure.ac to restict the building of
libgm2 - or to restrict it to building libm2min which is a near zero
runtime library.  It restricts on host and target and can easily be
changed.

> 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 gcc/m2/gm2spec.c.

> 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 is in m2/gm2-gcc/*.[ch].  The filenames adopt a similar
naming scheme to other front ends: m2/gm2-gcc/m2decl.c for
declarations, m2/gm2-gcc/m2expr.c for expressions etc.  The exported
names are prefixed by the module name so that the code can be linked
against the Modula-2 version with an appropriate definition module
(for example m2/gm2-gcc/m2expr.def).

> I've tried to find my way through gcc/m2 but am quite lost in the
> number of subdirectories.

I've added a README in each directory giving an overview of the
contents.

> 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.

I've changed nearly all headers to use "config.h", "system.h" and
friends and modified the bootstrap tool to automatically generate
these gcc header includes.

> From the parse_file langhook we eventually dispatch to
> init_PerCompilationInit which looks like a Modula-2 scaffolding
> file?

yes indeed.

> Is the compiler written in Modula-2?  It's not clear what
> parts make up the interface to the GCC middle-end.

yes most of the compiler and libraries are written in Modula-2 there
is some interface code written in C/C++.  In particular, for the
compiler, the directory m2/gm2-gcc contains all the tree creation code.
m2/gm2-libs-ch is the small amount of C required to interface to the
host 

Re: [PATCH] Modula-2 into the GCC tree on master

[Gaius Mulley via Gcc-patches]

Matthias Klose  writes:

> On 1/18/21 2:55 PM, Gaius Mulley via Gcc-patches wrote:
>> Richard Biener  writes:
>>> 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
>
> Gaius, now with the 1.1 relase out of the door, please could you clarify about
> your plans getting this into trunk, and do you plan to get this into 11.2 as 
> well?
>
> Thanks, Matthias

Hello Matthias and Richard,

just a small update to say that I think all the code changes are done -
I've a tiny amount of documentation texinfo file moving / reorganising
then testing and then the patches will be posted.


regards,
Gaius

Re: [PATCH] Modula-2 into the GCC tree on master

[Gaius Mulley via Gcc-patches]

Matthias Klose  writes:

> On 1/18/21 2:55 PM, Gaius Mulley via Gcc-patches wrote:
>> Richard Biener  writes:
>>> 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
>
> Gaius, now with the 1.1 relase out of the door, please could you clarify about
> your plans getting this into trunk, and do you plan to get this into 11.2 as 
> well?
>
> Thanks, Matthias

Hi Matthias,

sure yes - I plan on getting it into trunk and then backporting it to
11.2.  If anyone with copyright assignment wants to expedite this - feel
free to forge ahead (and post patches).  I'm working though Richard's
review:

 https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563747.html

and should be able to post the latest patch set in say 2 weeks
time (for trunk) - would that time frame work?


regards,
Gaius

Re: [PATCH] Modula-2 into the GCC tree on master

[Matthias Klose]

On 1/18/21 2:55 PM, Gaius Mulley via Gcc-patches wrote:
> Richard Biener  writes:
>> 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

Gaius, now with the 1.1 relase out of the door, please could you clarify about
your plans getting this into trunk, and do you plan to get this into 11.2 as 
well?

Thanks, Matthias

Re: [PATCH] Modula-2 into the GCC tree on master

[Gaius Mulley via Gcc-patches]

Matthias Klose  writes:

> this is mising the definition of lang_register_spec_functions for the jit 
> build.
>
> 2020-03-23  Matthias Klose  
>
> * jit-spec.c (lang_register_spec_functions): New, not used for jit.
>
>
> --- a/gcc/jit/jit-spec.c
> +++ b/gcc/jit/jit-spec.c
> @@ -39,3 +39,9 @@ lang_specific_pre_link (void)
>
>  /* Number of extra output files that lang_specific_pre_link may generate.  */
>  int lang_specific_extra_outfiles = 0;  /* Not used for jit.  */
> +
> +/* lang_register_spec_functions.  Not used for jit.  */
> +void
> +lang_register_spec_functions (void)
> +{
> +}

Hello Matthias,

thanks for spotting this - yes - quite correct,

Re: [PATCH] Modula-2 into the GCC tree on master

[Gaius Mulley via Gcc-patches]

Richard Biener  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

Re: [PATCH] Modula-2 into the GCC tree on master

[Matthias Klose]

On 1/18/21 2:09 AM, Gaius Mulley via Gcc-patches wrote:
> gcc/
> 
> * gcc/brig/brigspec.c (lang_register_spec_functions): Added.
> * gcc/c-family/cppspec.c (lang_register_spec_functions): Added.
> * gcc/c/gccspec.c (lang_register_spec_functions): Added.
> * gcc/cp/g++spec.c (lang_register_spec_functions): Added.
> * gcc/d/d-spec.cc (lang_register_spec_functions): Added.
> * gcc/fortran/gfortranspec.c(lang_register_spec_functions): Added.
> * gcc/gcc.c (allow_linker): Global variable to disable
> linker by the front end.  (xputenv) available externally.
> (xgetenv) New function.  (save_switch) available externally.
> (fe_add_linker_option) New function.  (handle_OPT_B) New function.
> (fe_add_infile) New function.  (fe_mark_compiled) New function.
> (driver_handle_option) call handle_OPT_B.  (print_option) New
> function.  (print_options) New function.  (dbg_options) New function.
> (fe_add_spec_function) New function.  (lookup_spec_function)
> checks front end registered functions.
> (driver::set_up_specs):  call lang_register_spec_functions.
> (maybe_run_linker): Check allow_linker before running the linker.
> * gcc/gcc.h (fe_save_switch): Prototype.
> (handle_OPT_B) Prototype.  (fe_add_infile) Prototype.
> (fe_add_linker_option) Prototype.  (fe_add_spec_function) Prototype.
> (xputenv) Prototype.  (xgetenv) Prototype.  (print_options) Prototype.
> (print_option) Prototype.  (dbg_options) Prototype.
> (lang_register_spec_functions) Prototype.
> (allow_linker): Extern.
> * gcc/go/gospec.c (lang_register_spec_functions): Added.

this is mising the definition of lang_register_spec_functions for the jit build.

2020-03-23  Matthias Klose  

* jit-spec.c (lang_register_spec_functions): New, not used for jit.


--- a/gcc/jit/jit-spec.c
+++ b/gcc/jit/jit-spec.c
@@ -39,3 +39,9 @@ lang_specific_pre_link (void)

 /* Number of extra output files that lang_specific_pre_link may generate.  */
 int lang_specific_extra_outfiles = 0;  /* Not used for jit.  */
+
+/* lang_register_spec_functions.  Not used for jit.  */
+void
+lang_register_spec_functions (void)
+{
+}

Re: [PATCH] Modula-2 into the GCC tree on master

[Richard Biener via Gcc-patches]

On Mon, Jan 18, 2021 at 2:09 AM Gaius Mulley via Gcc-patches
 wrote:
>
>
> Hello,
>
> here is a patch which merges the gm2 front end into the GCC tree.  The
> patches have been boostrapped under x86_64 GNU/Linux Debian Stretch
> built using make -j 24 and also under x86_64 GNU/Linux Debian Buster
> using make -j 4.
>
> Tested on Debian Stretch x86_64
> ===
>
> built GCC bootstrap 3 times:
>
> 1.  built vanilla GCC (enabling bootstrap) enabling front ends:
> brig,c,c++,go,d,fortran and ran the regression tests.
>
> 2.  the patches below were applied and associated tarball untarred.
> The same front ends brig,c,c++,go,d,fortran (again building from
> bootstrap) were enabled (no m2) and ran the regression tests.
> There were no changes to the regression test results between 1 and
> 2.
>
> 3.  Then it was rebuilt (from bootstrap) enabling the front ends
> brig,c,c++,go,d,fortran,m2 and ran the
> regression tests and again no extra failures were seen.
>
> [should I also be testing ada?]
>
> Built on Debian Buster x86_64
> =
>
> Built a patched tree enabling bootstrap make -j 4 for front ends c,c++,m2
> all compiled and bootstrapped.
>
> How to merge
> 
>
> 1.  apply patches below to the master GCC tree.
>
> 2.  cd gcc-git-top
> wget 
> http://floppsie.comp.glam.ac.uk/download/c/gm2-front-end-20210116-tar.gz
> tar zxf gm2-front-end-20210116-tar.gz
> rm gm2-front-end-20210116-tar.gz
> # new directories libgm2 and gcc/m2 are created and populated
>
> 3.  cd gcc-git-top
> autogen Makefile.def
> autoconf
> cd libgm2
> /bin/sh ./autogen.sh
>
> when built this implements iso, pim2, pim3 and pim4 editions of Modula-2
> with access to GCC features (gcc/m2/gm2.texi).
>
> hope this is useful - enjoy,

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).

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).

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).

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.  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?
It's not clear what parts make up the interface to the GCC middle-end.

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).

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.

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.

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?)

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 

[PATCH] Modula-2 into the GCC tree on master

[Gaius Mulley via Gcc-patches]

Hello,

here is a patch which merges the gm2 front end into the GCC tree.  The
patches have been boostrapped under x86_64 GNU/Linux Debian Stretch
built using make -j 24 and also under x86_64 GNU/Linux Debian Buster
using make -j 4.

Tested on Debian Stretch x86_64
===

built GCC bootstrap 3 times:

1.  built vanilla GCC (enabling bootstrap) enabling front ends:
brig,c,c++,go,d,fortran and ran the regression tests.

2.  the patches below were applied and associated tarball untarred.
The same front ends brig,c,c++,go,d,fortran (again building from
bootstrap) were enabled (no m2) and ran the regression tests.
There were no changes to the regression test results between 1 and
2.

3.  Then it was rebuilt (from bootstrap) enabling the front ends
brig,c,c++,go,d,fortran,m2 and ran the
regression tests and again no extra failures were seen.

[should I also be testing ada?]

Built on Debian Buster x86_64
=

Built a patched tree enabling bootstrap make -j 4 for front ends c,c++,m2
all compiled and bootstrapped.

How to merge


1.  apply patches below to the master GCC tree.

2.  cd gcc-git-top
wget 
http://floppsie.comp.glam.ac.uk/download/c/gm2-front-end-20210116-tar.gz
tar zxf gm2-front-end-20210116-tar.gz
rm gm2-front-end-20210116-tar.gz
# new directories libgm2 and gcc/m2 are created and populated

3.  cd gcc-git-top
autogen Makefile.def
autoconf
cd libgm2
/bin/sh ./autogen.sh

when built this implements iso, pim2, pim3 and pim4 editions of Modula-2
with access to GCC features (gcc/m2/gm2.texi).

hope this is useful - enjoy,

regards,
Gaius



2021-01-18  Gaius Mulley   

* configure.ac (GM2_FOR_TARGET): Added.
Request build driver program gm2.
(libgm2) option added.
(compare_exclusions) includes SYSTEM and M2Version.
* Makefile.def (GM2_FOR_TARGET): Added.
(GM2FLAGS_FOR_TARGET): Added.  Assign GM2,
GM2_FOR_BUILD, GM2_FOR_TARGET and GM2FLAGS.
Pass variables to make.  Add new language Modula-2
(m2).  (target_modules) includes libgm2.  (flags_to_pass)
includes GM2_FOR_TARGET and GM2FLAGS_FOR_TARGET.
* Makefile.tpl (GM2FLAGS): Added.  (GM2) Added.
(GM2_FOR_BUILD) Added.

gcc/

* gcc/brig/brigspec.c (lang_register_spec_functions): Added.
* gcc/c-family/cppspec.c (lang_register_spec_functions): Added.
* gcc/c/gccspec.c (lang_register_spec_functions): Added.
* gcc/cp/g++spec.c (lang_register_spec_functions): Added.
* gcc/d/d-spec.cc (lang_register_spec_functions): Added.
* gcc/fortran/gfortranspec.c(lang_register_spec_functions): Added.
* gcc/gcc.c (allow_linker): Global variable to disable
linker by the front end.  (xputenv) available externally.
(xgetenv) New function.  (save_switch) available externally.
(fe_add_linker_option) New function.  (handle_OPT_B) New function.
(fe_add_infile) New function.  (fe_mark_compiled) New function.
(driver_handle_option) call handle_OPT_B.  (print_option) New
function.  (print_options) New function.  (dbg_options) New function.
(fe_add_spec_function) New function.  (lookup_spec_function)
checks front end registered functions.
(driver::set_up_specs):  call lang_register_spec_functions.
(maybe_run_linker): Check allow_linker before running the linker.
* gcc/gcc.h (fe_save_switch): Prototype.
(handle_OPT_B) Prototype.  (fe_add_infile) Prototype.
(fe_add_linker_option) Prototype.  (fe_add_spec_function) Prototype.
(xputenv) Prototype.  (xgetenv) Prototype.  (print_options) Prototype.
(print_option) Prototype.  (dbg_options) Prototype.
(lang_register_spec_functions) Prototype.
(allow_linker): Extern.
* gcc/go/gospec.c (lang_register_spec_functions): Added.

Patches
===

diff --git a/Makefile.def b/Makefile.def
index 3e38f61193f..ef428b98f40 100644
--- a/Makefile.def
+++ b/Makefile.def
@@ -180,6 +180,7 @@ target_modules = { module= libffi; no_install=true; };
 target_modules = { module= zlib; };
 target_modules = { module= rda; };
 target_modules = { module= libada; };
+target_modules = { module= libgm2; lib_path=.libs; };
 target_modules = { module= libgomp; bootstrap= true; lib_path=.libs; };
 target_modules = { module= libitm; lib_path=.libs; };
 target_modules = { module= libatomic; lib_path=.libs; };
@@ -298,6 +299,8 @@ flags_to_pass = { flag= GOC_FOR_TARGET ; };
 flags_to_pass = { flag= GOCFLAGS_FOR_TARGET ; };
 flags_to_pass = { flag= GDC_FOR_TARGET ; };
 flags_to_pass = { flag= GDCFLAGS_FOR_TARGET ; };
+flags_to_pass = { flag= GM2_FOR_TARGET ; };
+flags_to_pass = { flag= GM2FLAGS_FOR_TARGET ; };
 flags_to_pass = { flag= LD_FOR_TARGET ; };
 flags_to_pass = { flag= LIPO_FOR_TARGET ; };
 flags_to_pass = { flag= LDFLAGS_FOR_TARGET ; };
@@ -652,6 +655,7 @@ languages = { language=obj-c++; 
gcc-check-target=check-obj-c++; };
 languages = { language=go; gcc-check-target=check-go;
lib-check-target=check-target-libgo;
lib-check-target=check-gotools; };
+languages = { language=m2;