1-800-GIT-HELP question

[Gaius Mulley]

Hello,

Firstly many thanks to all who have worked on the git migration and also
for the offer of help :-)

I'm seeking a little advice on an efficient way to combine the gm2 git
repro with the gcc git repro.  When gcc was using subversion I had a
script which untared the gm2 git over the subversion, applied local
patches to the gcc tree and then it was ready for use.  I could git diff
in the gm2 tree and svn diff in the gcc tree - etc.

I wonder if a similar model can be achieved now gcc uses git?

In essence the gm2 front end adds three subtrees to gcc

libgm2

gcc/m2

gcc/testsuite/gm2

currently these are all in one repro
gm2/gcc-versionno/{libgm2,gcc/m2,gcc/testsuite/gm2}.

http://git.savannah.gnu.org/cgit/gm2.git/tree

I'm a little cautious of choosing an initial working model without
knowing the implications.  There seem to be many possible solutions
(subtree, submodule) to name but two.

Disk space is not a concern, the time to recreate a working tree is more
important.

regards,
Gaius

Re: 1-800-GIT-HELP question

[Gaius Mulley]

Jonathan Wakely  writes:

> Is there a reason you can't just make it a branch of the GCC repo?
>
> It would mean you need to merge from upstream GCC into your repo,
> rather than just dropping your repo into/onto a GCC clone, but to me
> it seems the more natural solution. The modifications to the files in
> the GCC tree would also be in your branch (and properly tracked in
> git), and so not need to be done manually after untarring gm2 into the
> GCC tree.
>
> It would mean your gm2 repo would contain the full GCC history, but
> you said disk space isn't a concern. A checkout would need to check
> out the full GCC tree as well, but presumably you need some way to
> obtain that anyway if you're going to unpack/checkout/whatever the gm2
> repo inside the GCC tree.

Hello,

awesome thank you - yes indeed the branch suggestion makes a lot of
sense,

Re: 1-800-GIT-HELP question

[Gaius Mulley]

Andrew Pinski  writes:

>
> One thing which you could do is kinda of what glibc did when they
> merged glibc and glibc-ports.
> Really it would useful if you get GM2 into the base sources of gcc
> instead for GCC 11 :).

Hello,

yes indeed this is a huge priority for gm2 - all the big issues are
resolved now (licensing/gpl3/!libpth).  So I'm really hoping this can be
achieved,

regards,
Gaius

Re: 1-800-GIT-HELP question

[Gaius Mulley]

Jonathan Wakely  writes:

> On Wed, 15 Jan 2020 at 11:21, Gaius Mulley  wrote:
>>
>> Andrew Pinski  writes:
>>
>> >
>> > One thing which you could do is kinda of what glibc did when they
>> > merged glibc and glibc-ports.
>> > Really it would useful if you get GM2 into the base sources of gcc
>> > instead for GCC 11 :).
>>
>> Hello,
>>
>> yes indeed this is a huge priority for gm2 - all the big issues are
>> resolved now (licensing/gpl3/!libpth).  So I'm really hoping this can be
>> achieved,
>
> Great!
>
> That's even more reason to do it as a branch in (your copies of) the
> GCC tree then: it will make the process of submitting patches for
> inclusion upstream much more straightforward!

yes this is good to see triangulation of decisions along the same
direction of travel - thank you!

Re: Deprecate -traditional-cpp?

[Gaius Mulley]

Steve Kargl  writes:

> On Thu, Sep 05, 2019 at 07:08:48AM -0700, Steve Kargl wrote:
>> On Thu, Sep 05, 2019 at 07:03:25AM -0700, Steve Kargl wrote:
>> > On Thu, Sep 05, 2019 at 02:16:08PM +0300, Janne Blomqvist wrote:
>> > > On Thu, Sep 5, 2019 at 2:08 PM Nathan Sidwell  wrote:
>> > > >
>> > > > Is it time to deprecate traditional preprocessing?  It's been  30 years
>> > > > since C89.  Are (non-compiler) tools that use it still things?
>> > > >
>> > > > Handling it gets its hooks into a bunch of odd places in libcpp.
>> > > >
>> > > > To be specific: deprecate -traditional-cpp for GCC10, remove in GCC11.
>> > > 
>> > > The Fortran frontend uses traditional mode, for reasons I can't recall
>> > > at the moment.
>> > > 
>> > 
>> > Modern C allows single line comments to start with //
>> > 
>> > program hello
>> >print *, "Hello " // "world!"
>> > end program
>> 
>> With trunk,
>> 
>> % ~/work/bin/cpp hello.F90
>> # 1 "hello.F90"
>> # 1 ""
>> # 1 ""
>> # 1 "hello.F90"
>> program hello
>>print *, "Hello "
>> end program
>> 
>
> There are 9 open PRs about cpp and Fortran.  Of those nine, these
> seem to be important for moving to modern cpp.
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67623
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56659
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53934
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42954
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28662

for the sake of completeness - Modula-2 can also use cpp in traditional
mode.  I quite like the solution suggested in:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67623

"Fortran devs need to add a Fortran mode to CPP." which could apply to
Modula-2 as well


regards,
Gaius

state of play/strategy for including Modula-2 into the trunk (licence queries)

[Gaius Mulley]

Hello,

I thought I'd seek advice on how to get the Modula-2 front end into
trunk and also give a state of play.


State of play
=

Currently the gm2-trunk passes all but one regression test on amd64.
Other architectures/platforms vary.  In early September the whole number
overflow detection was completed, which was the final ISO feature
required.  The compiler and libraries completely implement the ISO
standard.  The good news is that the focus is now bug
hunting/fixing/maintainance and updating all boiler-plates.

I'm currently semi-manually walking the source tree updating all GPL
boiler-plates.  All compiler source files have been changed to GPL3.

http://git.savannah.gnu.org/cgit/gm2.git/tree/gcc-versionno/gcc/gm2/gm2-compiler

All library source files have been changed to GPL3 with runtime
exception in these directories:

http://git.savannah.gnu.org/cgit/gm2.git/tree/gcc-versionno/gcc/gm2/gm2-libs
http://git.savannah.gnu.org/cgit/gm2.git/tree/gcc-versionno/gcc/gm2/gm2-libs-min
http://git.savannah.gnu.org/cgit/gm2.git/tree/gcc-versionno/gcc/gm2/gm2-libs-pim
http://git.savannah.gnu.org/cgit/gm2.git/tree/gcc-versionno/gcc/gm2/gm2-libs-iso
http://git.savannah.gnu.org/cgit/gm2.git/tree/gcc-versionno/gcc/gm2/gm2-libs-coroutines
http://git.savannah.gnu.org/cgit/gm2.git/tree/gcc-versionno/gcc/gm2/gm2-libiberty
http://git.savannah.gnu.org/cgit/gm2.git/tree/gcc-versionno/gcc/gm2/gm2-libs-ch

Is this correct?  Without wishing to seem presumptuous - is it preferred to
use the project name GCC or stick with GNU Modula-2?

(I still need to visit:
http://git.savannah.gnu.org/cgit/gm2.git/tree/gcc-versionno/libgm2)

gm2 does use GNU libpth (to create context and switch contexts).
Although it doesn't need libpth for single process programs.  I think
the GNU libpth project is no longer maintained, so I've included it in:

http://git.savannah.gnu.org/cgit/gm2.git/tree/gcc-versionno/libgm2/libpth/pth

I assuming this is okay as it is an official GNU project?  It contains
the important clause:

>  This library is free software; you can redistribute it and/or
>  modify it under the terms of the GNU Lesser General Public
>  License as published by the Free Software Foundation; either
>  version 2.1 of the License, or (at your option) any later version.

in its source files - so I plan to bump this to GPL3 with runtime
exception.  Is this sensible and what is expected?

Anyway I thought it best to ask these questions even though there is
still a little way to go - but the finishing line is in sight!  (In
terms of visiting each and every file and checking the boiler-plates).

I've yet to tackle the regression test directory and the examples
directory.  I also need to check all Makefiles, script files and double
check the texi files.

Once the tree of source file visiting is complete, how should I proceed?

My default plan would be to work on the compiler driver patches again
after applying the changes advised.  If/when they go through ask for a
review of the tree for inclusion:

http://git.savannah.gnu.org/cgit/gm2.git/tree/gcc-versionno

again is this sensible?  Are there [obvious] issues I've missed?
What would you prefer?

many thanks,

regards,
Gaius

Re: state of play/strategy for including Modula-2 into the trunk (licence queries)

[Gaius Mulley]

Florian Weimer  writes:

> * Gaius Mulley:
>
>> gm2 does use GNU libpth (to create context and switch contexts).
>> Although it doesn't need libpth for single process programs.  I think
>> the GNU libpth project is no longer maintained, so I've included it in:
>>
>> http://git.savannah.gnu.org/cgit/gm2.git/tree/gcc-versionno/libgm2/libpth/pth
>
> libpth is dead upstream, I think, so it's not an ideal choice.
>
>> I assuming this is okay as it is an official GNU project?  It contains
>> the important clause:
>>
>>>  This library is free software; you can redistribute it and/or
>>>  modify it under the terms of the GNU Lesser General Public
>>>  License as published by the Free Software Foundation; either
>>>  version 2.1 of the License, or (at your option) any later version.
>>
>> in its source files - so I plan to bump this to GPL3 with runtime
>> exception.  Is this sensible and what is expected?
>
> Copyright has not been assigned to the FSF, so I wouldn't recommend
> making this change without consulting the major copyright holders
> first.

ah thanks - really useful info, I hadn't realised the copyright was not
assigned to the FSF.

> The question is whether this is really necessary.  Obviously, there is
> no requirement to ship all supporting code under the GPL version 3 or
> later for GCC.  See the libffi subdirectory, which has its own
> license.

sure I think it is looking sensible to stop using libpth.  gm2 only
needs the two basic primitives create a context and switch to a context
in any case.  Furthermore it only needs these if the user wants
coroutines.  For most Modula-2 programs it isn't required.

> (Note: I'm just a random bystander here, this is not official policy.)

the feedback is really helpful - thanks,


regards,
Gaius

Re: state of play/strategy for including Modula-2 into the trunk (licence queries)

[Gaius Mulley]

Florian Weimer  writes:

> * Gaius Mulley:
>
>>> The question is whether this is really necessary.  Obviously, there is
>>> no requirement to ship all supporting code under the GPL version 3 or
>>> later for GCC.  See the libffi subdirectory, which has its own
>>> license.
>>
>> sure I think it is looking sensible to stop using libpth.  gm2 only
>> needs the two basic primitives create a context and switch to a context
>> in any case.  Furthermore it only needs these if the user wants
>> coroutines.  For most Modula-2 programs it isn't required.
>
> One possibility would be to have an implementation based on the
> libgcc/gthr.h abstraction.  It would not be very efficient if the user
> is looking for coroutines, but it would avoid a dependency on yet
> another thread library.

yes thanks for the pointer - I will explore this in detail.  It looks
interesting as there is better potential for multi-language projects
(m2/C++ maybe).


regards,
Gaius

Re: state of play/strategy for including Modula-2 into the trunk (licence queries)

[Gaius Mulley]

ah no - lto builds fine.  But with make profiledbootstrap
it errors out with:

gm2/gm2-libs-boot/pthdummy.o: In function `pth_init':
/home/gaius/GM2/graft-trunk/build-lto-trunk/gcc/../../gcc-versionno/gcc/gm2/gm2-libs-ch/pthdummy.c:48:
 undefined reference to `__gcov_indirect_call'

the positive is that again I'm focused back onto replacing libpth 🙂

regards,
Gaius


From: Matthias Klose 
Sent: 01 October 2019 13:46
To: Gaius Mulley ; gcc@gcc.gnu.org 

Subject: Re: state of play/strategy for including Modula-2 into the trunk 
(licence queries)

On 30.09.19 18:46, Gaius Mulley wrote:
> again is this sensible?  Are there [obvious] issues I've missed?

does the profiled LTO build now work? I didn't check recently myself.

Matthias

integer overflow detection

[Gaius Mulley]

Hi,

I was wondering whether there is an easy way for a front end to detect
whether an integer overflow had occurred?  Currently the GNU Modula-2
front end will detect cardinal number and integer subrange out of bound
(during assignment, INC and DEC).  However it does not detect overflows
for these data types during arithmetic expressions.

I guess it is not particularly difficult to wrap front end '-', '+', '*'
with checks similar to those found here: http://www.fefe.de/intof.html
albeit with the cost of a significant code explosion.  Is it possible
for subsequent TREEs to be able to detect whether the carry bit has been
set (for non constant tree expressions) at runtime?

regards,
Gaius

Re: integer overflow detection

[Gaius Mulley]

"Joseph S. Myers"  writes:

> See PR 48580 for discussion of possible approaches for representing 
> overflow detection and handling (and, in particular, making -ftrapv work 
> properly and making -fwrapv and -ftrapv affect the IR generated by front 
> ends instead of being global flags), both in GIMPLE and at the C source 
> level.

many thanks for the pointer,

regards,
Gaius

Re: [Gm2] gnu modula-2 + cygwin compilerfehler.... mit loesung

[Gaius Mulley]

Robert Bergermann  writes:

> Hallo gcc@gcc.gnu.org g...@nongnu.org !
>
> Als erstes moechte ich meine Begeisterung zum Ausdruck bringen, da ich mich
> sehr
> darueber gefreut habe das es einen Modula2-Compiler gibt der recht aktuell ist
> und ger gepflegt wird! Super Sache!!
>
> Aus Bequemlichkeit habe ich versucht gcc-4.1.2+gm2-cvs-latest.tar.gz nach der
> Anleitung auf http://www.nongnu.org/gm2/cygwin.html mit Cygwin unter Win7 zum
> laufen zu bekommmen. Ist mir auch gelungen, es gab jedoch 2 kleine Heraus-
> forderungen. Hier meine Systeminformationen:
>
> $ ./config.guess
> i686-pc-cygwin
>
> $ uname -a
> CYGWIN_NT-6.1-WOW64 ASUS 1.7.9(0.237/5/3) 2011-03-29 10:10 i686 Cygwin
>
> $ gcc -v
> Reading specs from /usr/lib/gcc/i686-pc-cygwin/3.4.4/specs
> Configured with: /managed/gcc-build/final-v3-bootstrap/gcc-3.4.4-999/configure
> --verbose --program-suffix=-3 --prefix=/usr --exec-prefix=/usr --sysconfdir=/
> etc
> --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
> --infodir=/usr/share/info --enable-languages=c,ada,c++,d,f77,pascal,java,objc
> --enable-nls --without-included-gettext --enable-version-specific-runtime-libs
> --without-x --enable-libgcj --disable-java-awt --with-system-zlib
> --enable-interpreter --disable-libgcj-debug --enable-threads=posix
> --enable-java-gc=boehm --disable-win32-registry --enable-sjlj-exceptions
> --enable-hash-synchronization --enable-libstdcxx-debug
> Thread model: posix
> gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)
>
> Die folgende Datei bereitete Probleme
>
> ~/gcc-4.1.2+gm2-cvs-latest/libiberty/strsignal.c
>
> die ich wie folgt geloest habe
>
> In Zeile 31 einfuegen:
> #define DEFS_H 1
> da sonst /usr/include/string.h Zeile 92..94 Probleme bereitet und der
> Compiler mit Fehler abbricht! strsigno in strsignal.c/zeile 467 wird
> auch bereits durch ~/gcc-4.1.2+gm2-cvs-latest/include/libiberty.h als
> "extern const char *strsigno (int);" definiert.
>
>
> Zeile 552 aendern in
> psignal (int signo, char *message)
> da unsinged ebenfalls falsch ist und zum Abbruch fuehrt.
>
>
> Mit freundlichen Gruessen
> Robert Bergermann
>
>
>
> $ gm2 -v
> Using built-in specs.
> Target: i686-pc-cygwin
> Configured with: ../gcc-4.1.2+gm2-cvs-latest/configure --prefix=/opt/gm2
> --disable-multilib --enable-checking=all --enable-language=c,c++,gm2
> Thread model: single
> gcc version 4.1.2
>
> $ gm2 --version
> GNU Modula-2  1.0.1  (20110715)
>   grafted onto GCC 4.1.2
> Copyright (C) 2011 Free Software Foundation, Inc.
> License GPLv2: GNU GPL version 2 or later 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.

Hi Robert,

good to hear about the success of building gm2 under cygwin.  Do you
want to prepare a patch set which could be applied by others to get the
same successful results?

regards,
Gaius

GNU Modula-2 version 1.0

[Gaius Mulley]

Hi,

GNU Modula-2 1.0 has been released.  Full details on how to download
gm2 can be found on the homepage www.nongnu.org/gm2.  It successfully
passes all regression tests on both the x86_32 and x86_64 Debian
GNU/Linux platforms, for details about other ports please also see the
homepage.

A huge thanks to all the numerous people that have supported this
project over the last decade.

regards,
Gaius

the loss of SET_TYPE

[Gaius Mulley]

Hi,

I'm trying to port bring the GNU Modula-2 front end up to gcc-4.1.0
and have found out that SET_TYPE has been removed :-)

I see the patch from Dec 2004:

http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00670.html

and understand the reason (no front ends in gcc tree use SET_TYPE
etc). I suppose I'd just like to flag that Modula-2 utilises this type
during the generation of BITSET types and also large sets (built
internally from multiple int length SET_TYPEs). But I totally
understand it might be difficult to justify code which is never run
(and difficult to test) in the main gcc tree..

Pragmatically I guess it is best for me to maintain a reversed patch
which can be applied to a gcc-4.1.0 tar ball which reintroduces this
TYPE. Any thoughts?

Many thanks,
Gaius

Re: the loss of SET_TYPE

[Gaius Mulley]

Eric Botcazou <[EMAIL PROTECTED]> writes:

> > Pragmatically I guess it is best for me to maintain a reversed patch
> > which can be applied to a gcc-4.1.0 tar ball which reintroduces this
> > TYPE. Any thoughts?
> 
> Integrating the Modula-2 front-end?

Hi,

this would be an excellent thing to do..  What do you folks need me to
do?  Presumably bring gm2 up to the latest gcc cvs with its regression
test suite working etc?  Copyright has been assigned to the FSF and
the documentation is in texinfo.

Are there any more issues?

regards,
Gaius

Re: the loss of SET_TYPE

[Gaius Mulley]

"Steven Bosscher" <[EMAIL PROTECTED]> writes:

> On 25 Mar 2006 00:02:43 +, Gaius Mulley <[EMAIL PROTECTED]> wrote:
> > Pragmatically I guess it is best for me to maintain a reversed patch
> > which can be applied to a gcc-4.1.0 tar ball which reintroduces this
> > TYPE. Any thoughts?
> 
> I think it would be better if you make the SET_TYPE a front-end
> specific tree node, much like e.g. the tcc_type tree codes in
> cp/cp-tree.def.  Then you can use SET_TYPE in the front end, and
> translate the set operations to valid GIMPLE later on when
> gimplifying.

Hi,

thanks for the pointers - yes this does seem a better approach..

regards,
Gaius

Re: the loss of SET_TYPE

[Gaius Mulley]

"Steven Bosscher" <[EMAIL PROTECTED]> writes:

> Does the code conform to the GNU/GCC coding conventions? You can find
> those on the gcc web site (http://gcc.gnu.org/codingconventions.html).

Hi,

thanks for the URL.

Generally yes - although the documentation needs more work to include
internal front end details (gm2 as of gcc-3.3.6 graft needed no tree
extensions).  The later graft will define its own tree.def to
implement SET_TYPE as previously advised etc. All gm2 command line
switches are documented in gm2/gm2.texinfo.

It would be good to restructure some of the gm2-gcc interface code,
into similar filenames to that used by other front ends. Ie
m2typeck.c, m2decl.c rather than the large single file gm2/gccgm2.c.
There is quiet a bit of pseudo duplication between gm2 and say the C
front end - it would be really good to reduce this if possible..

Regressions tests and ChangeLog entries have been coordinated for some
time now. Although they could adopt a more formal PR numbering scheme
as per gcc.

regards,
Gaius

Re: Great example of why "everything is a tree" sucks

[Gaius Mulley]

Richard Biener  writes:

> On Wed, Nov 13, 2013 at 11:37 AM, Steven Bosscher  
> wrote:
>> On Wed, Nov 13, 2013 at 11:10 AM, Richard Biener wrote:
>>> Well, he doesn't even consider that the exact same "tree rant" applies
>>> to frontend code.
>>
>> That's not entirely true, either. Most front ends already use their
>> own IL in the parser (only C++ uses 'tree' for everything).
>>
>> What worries me most, is that we may end up with:
>>
>> FE-IL => 'tree' => gimple
>>
>> where 'tree' is just a memory-consuming, complicated intermediate step
>> between the front ends and the middle end. I don't think that's the
>> interface we want.
>
> True.  The above applies to Fortran and Ada, and maybe also to Go
> and Java.

just for completeness this also applies to Modula-2 which uses the
technique of double book keeping.  Not sure if this is totally relevant
but gm2 needs (would like :-) the ability to create a SET_TYPE which
maps onto appropriate debugging type info.

regards,
Gaius

Re: Great example of why "everything is a tree" sucks

[Gaius Mulley]

Jeff Law  writes:

> On 11/13/13 11:30, Joseph S. Myers wrote:
>> On Wed, 13 Nov 2013, Gaius Mulley wrote:
>>
>>> just for completeness this also applies to Modula-2 which uses the
>>> technique of double book keeping.  Not sure if this is totally relevant
>>> but gm2 needs (would like :-) the ability to create a SET_TYPE which
>>> maps onto appropriate debugging type info.
>>
>> Note we removed SET_TYPE in 2004 for lack of in-tree uses (there was a
>> suspicion it might have been for Pascal, but GNU Pascal is now a moribund
>> project (largely I think because of the combination of (a) being closely
>> tied to GCC internals through use of trees as front-end internal
>> representation and (b) not being developed in the GCC repository but
>> externally with attempts to support multiple GCC versions from one GNU
>> Pascal version, meaning lots of effort needed outside the GCC community to
>> update it to new GCC versions - also (c) there's another more actively
>> developed GPL Pascal compiler, Free Pascal, albeit for different versions
>> of the Pascal language).
>>
>> In general, for GCC development to consider requirements of your front end
>> or back end, getting it into the GCC repository and developing it there is
>> strongly recommended.
> Sadly, I tried multiple times in the late 90s to bring the folks going
> GNU Pascal development into the GCC project without any
> success. Eventually I have up.

I'd be delighted to see gm2 in the gcc repository.  The gm2 repository
is currently in git format (changed from cvs 2 weeks ago).  All fsf
copyright assignment forms have been done some years ago.

At present the gm2 master can be grafted onto gcc-4.7.3 with 10 patches
applied.  Under Debian Wheezy x86_64 the regression tests show 332
failures and 8298 passes.

>From reading http://gnu.gcc.org/wiki/SvnBranch I wonder whether it would
seem sensible to create two branches one at 4.7.3 and another at branch
at the head (maybe) and mercilessly merge from the head.  Maybe one
of the earlier activities should be to forward port the 10 patches and
post them to the appropriate mailing list?

regards,
Gaius

Re: Great example of why "everything is a tree" sucks

[Gaius Mulley]

"Joseph S. Myers"  writes:

> On Wed, 13 Nov 2013, Gaius Mulley wrote:
>
>> >> In general, for GCC development to consider requirements of your front end
>> >> or back end, getting it into the GCC repository and developing it there is
>> >> strongly recommended.
>> > Sadly, I tried multiple times in the late 90s to bring the folks going
>> > GNU Pascal development into the GCC project without any
>> > success. Eventually I have up.
>> 
>> I'd be delighted to see gm2 in the gcc repository.  The gm2 repository
>> is currently in git format (changed from cvs 2 weeks ago).  All fsf
>> copyright assignment forms have been done some years ago.
>
> Personally I'd welcome addition of front ends for any mainstream languages 
> (of the sort that are suited to ahead-of-time compilation to machine code 
> as in GCC) where there are developers interested in maintaining them in 
> GCC following the usual GCC coding standards and development practices.  
> (sourcebuild.texi, "Front End", provides a checklist so you don't have 
> anything obviously missing, but of course there's lots more involved in 
> following what are currently considered good coding practices in GCC - 
> some things existing front ends do may not now be considered good practice 
> for new front ends.)  This doesn't say whether a new front end would be 
> built by default (though my personal view is that --enable-languages=all 
> should mean all languages supported for the given target with the 
> available build tools, and should be the default, but the expectations for 
> routine patch testing could be something less).
>
> Of course, if a front end then ceases to be maintained it may get removed, 
> as the CHILL front end was removed.
>
>> >From reading http://gnu.gcc.org/wiki/SvnBranch I wonder whether it would
>> seem sensible to create two branches one at 4.7.3 and another at branch
>> at the head (maybe) and mercilessly merge from the head.  Maybe one
>> of the earlier activities should be to forward port the 10 patches and
>> post them to the appropriate mailing list?
>
> Any patches that aren't simply filling in checklist items for a new front 
> end certainly need posting separately with their own rationale (for 
> example, if there's an optimizer bug fix for a bug the front end shows 
> up).  If the patch only makes sense with the new front end, but isn't 
> simply checklist-filling, it's probably best posted at the same time as 
> the front end itself, but as a separate patch in the series (for example, 
> if you want a new language-independent GIMPLE operation).
>
> I think it's reasonable to give SVN write access to anyone with a 
> copyright assignment on file who is interested in maintaining a front end 
> on a branch and hopefully contributing it to trunk in future.

many thanks for the great advice and pointers!  I'm leaning towards
three branches, head, 4.8.2 and 4.7.3.  The last since it is so close
to passing all gm2 regression tests and thus useful to the m2 community.
4.8.2 to allow patch testing against the whole gcc testsuite and
finally head.

Once 4.7.3 and all gm2 regression tests pass then this would be becomes
maintenance and my focus would be on 4.8.2 and head.

regards,
Gaius

implementing exception handlers in a front end

[Gaius Mulley]

Hi,

I'm currently trying to implement the exception handling in GNU
Modula-2 and was wondering which of the following two routes to use.
I was initially enthusiastic about using __builtin_setjmp/
__builtin_longjmp as Modula-2 exceptions can be implemented with these
mechanisms - and it would also be tantalisingly easy to code..

  However, upon searching this list I see that there are a number of
problems with __builtin_setjmp and __builtin_longjmp and have begun
to examine TRY_CATCH_EXPR nodes instead.  It seems that if this later
route is taken then the front end also needs to add:

DEFTREECODE (THROW_EXPR, "throw", tcc_unary, 1)

to its language tree.def and gimplify this.  Before I embark on this
I'd like to ask whether using __builtin_longjmp/__builtin_setjmp is
definitely the wrong way to go?

regards,
Gaius

Re: implementing exception handlers in a front end

[Gaius Mulley]

"Richard Guenther" <[EMAIL PROTECTED]> writes:

> > to its language tree.def and gimplify this.  Before I embark on this
> > I'd like to ask whether using __builtin_longjmp/__builtin_setjmp is
> > definitely the wrong way to go?
> 
> Definitely.  You will be not able to handle/throw exceptions from other
> languages if the target ABI doesn't use sjlj exceptions (which only
> a few use).

many thanks for the reply,  yes I hadn't considered the issue of
inter-language exception handling - this makes the TRY_CATCH_EXPR route
highly attractive..

regards,
Gaius

Re: gimple type system

[Gaius Mulley]

Kenneth Zadeck <[EMAIL PROTECTED]> writes:

> >> Anyway, there must be other uses of types in either the existing middle end
> >> or that people have dreams of adding to the middle end in the future.   Now
> >> is the time to raise your hand before the design has been started.

Hi,

for me its great use will be to introduce set type debugging into gm2.
At the very minimum it would be nice to be able to define a word sized
bit set which the middle and back end can consider it to have the
properties of "unsigned int" however the debugging info emitted needs
to say that this word is really a set type of some lower and upper
bounds and subtype.

But how this is done via an API is up to you :-).  My initial thoughts
would be for the front end to be able to define this unsigned int
"fake" type and obtain a unique handle.  The front end would then need
to also maintain the debugging stubs for the type (say dwarf2 and
stabs) which will be invoked by some call back mechanism during the
back end.  But I readily admit this is a little messy..

regards,
Gaius

Re: implementing exception handlers in a front end

[Gaius Mulley]

"Richard Guenther" <[EMAIL PROTECTED]> writes:

> > to its language tree.def and gimplify this.  Before I embark on
> > this I'd like to ask whether using
> > __builtin_longjmp/__builtin_setjmp is definitely the wrong way to
> > go?
> 
> Definitely.  You will be not able to handle/throw exceptions from
> other languages if the target ABI doesn't use sjlj exceptions (which
> only a few use).

just to say thanks for the advice and that they have been implemented
in the Modula-2 front end using the cpp TRY_CATCH_EXPR/THROW etc tree
nodes.  A few core ISO Modula-2 runtime exception libraries have also
been implemented.

Anyway here are some screen-casts of inter-language C++/M2 and M2/Python
throwing and catching exceptions:

http://floppsie.comp.glam.ac.uk/download/screencasts/gnu-modula-2/python/python-exception-gnu-modula2.mp4
http://floppsie.comp.glam.ac.uk/download/screencasts/gnu-modula-2/cpp/cpp-exception-gnu-modula2.mp4

[screen-casts are roughly 7MB each]

regards,
Gaius

Modula-2 into the GCC tree on master?

[Gaius Mulley via Gcc]

Hello GCC Steering Committee and fellow GCC developers,

I was wondering whether now might be a sensible time to graft GNU
Modula-2 into the GCC tree?  (on the master branch only).  At present
gm2 fully implements PIM2, PIM3, PIM4 and ISO dialects of Modula-2.  All
the ISO libraries are implemented - there are a number of PIM libraries
as well.  There are also no extra failures on master branch for other
languages when Modula-2 is introduced.

Since last year all non GPL3 material has been purged, the Ulm libraries
removed (which were GPL2) and libpth removed.  All dependent code
(coroutines) replaced by functionally equivalent modules using
libatomic.  Multilib libraries are built and gm2 works with lto.  All
code is now GPL3 or GPL3.1 with GCC runtime exemption (libraries).  It
comes with a testsuite using dejagnu.  gm2 builds and runs on i386,
amd64, powerpc64le, aarch64 and thanks to Matthias Klose there are gm2
Debian packages on https://packages.debian.org/bullseye/gm2 with a few
more architectures.

Currently gm2 is tracking the GCC development model, there are branches
open for [gm2-4, gm2-6, gm2-8, gm2-9, gm2-10], and gm2-master.
(Although the branches in [] < 10 are not all GPL3 compliant and/or
require libpth).

The gm2 front code is currently in git on Savannah:

   git clone https://git.savannah.nongnu.org/git/gm2.git

and there is a nightly automatic rebase of gm2 onto GCC which is
available from:

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

   [See http://www.nongnu.org/gm2/development.html].

which contains the above branches and GCC.  The gm2-master branch (on
the floppsie git repro) passes all regressions (on aarch64 and there is
one failure on amd64 - which I will fix after sending this email).  It
perhaps might be useful to have yet another language with a regression
testsuite even if just as a canary in the coal mine for various
architectures, maybe?

There are a few patches required to non m2 directories.  A number of
these have been posted before and reviewed twice by Richard Sandiford
and Joseph Myers.  (For reference
https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg225115.html).
I've made the suggested changes and the latest patches to be applied can
be found here:

   
http://git.savannah.nongnu.org/cgit/gm2.git/tree/gcc-versionno/gcc/m2/patches/gcc/trunk

The git sources can be browsed at:

   http://git.savannah.nongnu.org/cgit/gm2.git/tree/gcc-versionno

using the master branch.  When the patches are applied it would look
like the gm2-master branch on floppsie.comp.glam.ac.uk.

Anyway from my perspective I'd be very happy to see the master
branch reside in GCC :-) and was wondering if this is a good time?

regards,
Gaius

Re: Modula-2 into the GCC tree on master?

[Gaius Mulley via Gcc]

David Edelsohn  writes:

> Hi, Gaius
>
> Thanks for your diligent effort to complete this port of Modula-2 and
> prepare it for inclusion in GCC.  I have forwarded the proposal to the
> GCC Steering Committee.
>
> Thanks, David

Hi David,

many thanks for forwarding the proposal - always great fun to work with
GCC

regards,
Gaius

[Bug modula2/102344, 102339, 102323, 102325] confirmed and resolved

[Gaius Mulley via Gcc]

Hello,

a huge apology as I'm sure this must be obvious - but I cannot see how
to set the status on bugzilla.  In summary the above bugs have been
resolved (I believe),


regards,
Gaius

gm2 development status (tracking gcc-12 20211209)

[Gaius Mulley via Gcc]

I've been testing the gm2 development branch (based on gcc-12)
against lto and non lto builds.

  git clone git://gcc.gnu.org/git/gcc.git gcc-git
  cd gcc-git
  git checkout devel/modula-2

I'm using the configure options:

CXXFLAGS="-g" CFLAGS="-g $PROFILE" ${absdir}/configure \
--prefix=$HOME/${INSTALLDIR} \
--libexecdir=$HOME/${INSTALLDIR}/lib \
--enable-threads=posix \
--enable-clocale=gnu --enable-languages=${LANGUAGES} \
--disable-multilib  --enable-checking \
--enable-long-longx \
--enable-bootstrap

and building using: make -j 12.

Without lto the repro above (from Dec 9th) passes all gm2 regressions
on the amd64 architecture and does not introduce any regression tests
for the languages (c,c++,go,fortran).

With lto there are no extra errors introduced compared between other
languages.  However I do see many large set regression test failures
in gm2 when lto is enabled.  I'm using the configure arguments:

CXXFLAGS="-g" CFLAGS="-g $PROFILE" ${absdir}/configure \
--prefix=$HOME/${INSTALLDIR} \
--libexecdir=$HOME/${INSTALLDIR}/lib \
--enable-threads=posix \
--enable-clocale=gnu --enable-languages=${LANGUAGES} \
--disable-multilib  --enable-checking \
--enable-long-longx \
--enable-bootstrap \
--with-build-config=bootstrap-lto-lean

and building with

   make -j 12 profiledbootstrap-lean

The good news is that I can test and hunt for the large set failures
(diff the execution of the cc1gm2 built with/without lto) and also good
that gm2 builds with lto.  [Interestingly there has been a problem with
large sets and sparc64 and a 64 bit powerppc variant - so hopefully this
could all be the same bug.. maybe].  From some time ago I have a python
script which will run two copies of gdb/cc1gm2 and single step both in
lock step and dump out when they differ.

Aside from the bug(s) above it is looking pretty stable - and was
wondering when or if it would be a good time to merge gm2 into the
trunk?

In the meantime I'll hunt the gm2/lto bug above and keep git merging
(approx weekly) and feed in small patches to the gm2 development
branch,

regards,
Gaius

Re: gm2 development status (tracking gcc-12 20211209)

[Gaius Mulley via Gcc]

Richard Biener  writes:

>>Aside from the bug(s) above it is looking pretty stable - and was
>>wondering when or if it would be a good time to merge gm2 into the
>>trunk?
>
> Merging early in stage1 would make most sense. 

yes, sure - sounds sensible.  I'll polish, patch, git merge, test and
bug hunt in devel/modula-2 ready for inclusion early in stage1,


regards,
Gaius

Re: Fwd: ULM Modula-2 Libraries for inclusion in GM2

[Gaius Mulley via Gcc]

David Edelsohn  writes:

> Hi, Gaius
>
> I hope that you and the GNU Modula-2 team can propose the merge of the
> Modula-2 front-end and library soon.
>
> Thanks, David

Hi David,

yes indeed - sorry for the delay in my reply.

Yes I was also wondering whether now might be a sensible time for the
Modula-2 front end to move across onto the master branch?

The current Modula-2 front end is in the branch: devel/modula-2 and it
builds on gnu/linux/amd64, gnu/linux/aarch64, gnu/linux/sparc64,
solaris/sparc64, gnu/linux/i386, gnu/linux/ppc64le, gnu/linux/power7
(and probably others).  (Test results posted to gcc-testresults).

More than happy for the gm2 front end to be merged and/or help or
receive instructions on how to progress the merge

regards,
Gaius

Proposal for the merger of devel/modula-2 into master

[Gaius Mulley via Gcc]

Hi David,

David Edelsohn  writes:

> I hope that you and the GNU Modula-2 team can propose the merge of the
> Modula-2 front-end and library soon.

[reposting with a new title for mailing list clarity]

Yes I was also wondering whether now might be a sensible time for the
Modula-2 front end to move across onto the master branch?

The current Modula-2 front end and libraries are in the branch:
devel/modula-2 and it builds on gnu/linux/amd64, gnu/linux/aarch64,
gnu/linux/sparc64, solaris/sparc64, gnu/linux/i386, gnu/linux/ppc64le,
gnu/linux/power7 (and probably others).  (Test results posted to
gcc-testresults).

More than happy for the gm2 front end to be merged and/or help or
receive instructions on how to progress the merge

regards,
Gaius

Re: Proposal for the merger of devel/modula-2 into master

[Gaius Mulley via Gcc]

Richard Biener  writes:

>> Am 14.05.2022 um 00:57 schrieb Gaius Mulley via Gcc :
>> 
>> 
>> Hi David,
>> 
>> David Edelsohn  writes:
>> 
>>> I hope that you and the GNU Modula-2 team can propose the merge of the
>>> Modula-2 front-end and library soon.
>> 
>> [reposting with a new title for mailing list clarity]
>> 
>> Yes I was also wondering whether now might be a sensible time for the
>> Modula-2 front end to move across onto the master branch?
>
> Yes, it’s stage1 now.
>
>> The current Modula-2 front end and libraries are in the branch:
>> devel/modula-2 and it builds on gnu/linux/amd64, gnu/linux/aarch64,
>> gnu/linux/sparc64, solaris/sparc64, gnu/linux/i386, gnu/linux/ppc64le,
>> gnu/linux/power7 (and probably others).  (Test results posted to
>> gcc-testresults).
>
> There’s at least BSD in the list of primary targets. It would be nice to 
> enable more but that can be done during stage1.
>
> I suggest you post merge patches where the branch touches generic code for 
> review again, indicating parts that have been approved in the past.
>
> Richard 

Hi Richard,

thanks for the email - sure I'll post the generic code patches with
references to those components which were okayed.  I'm in the process of
building on BSD (Free and Open) platforms.

regards,
Gaius

Proposal for the merger and patch set

[Gaius Mulley via Gcc]

Richard Biener  writes:

> I suggest you post merge patches where the branch touches generic code
> for review again, indicating parts that have been approved in the
> past.

Hello Richard, David and the GCC Steering Committee,

Firstly thank you for the release of gcc-12.1 and secondly thank you
for taking the time to review the Modula-2 front end and for valuable
review feedback over the years.  I hope you have all managed to have a
break after the 12.1 release.

Here for reference are the previous patch emails and reviews

[For historical completeness
https://gcc.gnu.org/pipermail/gcc-patches/2019-November/534683.html
]

Jan 18 2021 patches:

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

Richard's  review of the patches last year.

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


June 2021 patches:

https://gcc.gnu.org/pipermail/gcc-patches/2021-June/573103.html

Richard's  review of the June patches last year.

https://gcc.gnu.org/pipermail/gcc-patches/2021-June/573147.html

Richard Guenther   writes:

> I suggest you post merge patches where the branch touches generic
> code for review again, indicating parts that have been approved in
> the past.

Sure I'll try and group the subsequent email patches into the following 
categories:

  1.  all GCC files which have been patched.
  2.  the top level /gm2tools contents.
  3.  the top level /libgm2 contents.
  4.  the glue code (between Modula-2 and GCC) contained in /gcc/m2/gm2-gcc.
  (these have not been reviewed before).  These will be posted in
  3 sub parts.
  5.  all the driver code /gcc/m2.
  6.  /gcc/m2/Make-lang.in
  (not been reviewed before)
  7.  /gcc/doc/gm2.texi
  (not been reviewed before)

The full source code is available via:

  $ git clone git://gcc.gnu.org/git/gcc.git gcc-git-devel-modula2
  $ cd gcc-git-devel-modula2
  $ git checkout devel/modula-2

currently it is being merged every 1-3 days or so.  One of the
recommendations after the last review was to maintain this branch.
Over the last year the changes include many bug porting fixes, removal
of compiler build warnings, migrating the code base to C++, improving
accuracy/detail of compiler error messages and improving error recovery.

It builds on gnu/linux/amd64, gnu/linux/aarch64, gnu/linux/sparc64,
solaris/sparc64, gnu/linux/i386, gnu/linux/ppc64le, gnu/linux/power7
(and probably others).  Also built with profiled lto on amd64 and
aarch64.

Richard Guenther   writes

> There’s at least BSD in the list of primary targets. It would be
> nice to enable more but that can be done during stage1.

and now FreeBSD 13 i586 providing a patch was applied for C++.
[Interestingly csinl, ctanl and friends are missing on FreeBSD 13
which cause all runtime tests to fail].

(Test results posted to gcc-testresults).

On amd64-gnu-linux it builds as a cross compiler for aarch64.
http://floppsie.comp.glam.ac.uk/Southwales/gaius/web/bare-metal-m2.html

I've built GCC from the master branch enabled c,c++,fortran,go,d
and then built GCC from devel/modula-2 enabled c,c++,fortran,go,d,m2
and no further regressions were seen.

Anyway I suspect this email is long enough for now - feel free to ask
questions, 9 patches posted to the gcc-patches list.  Let me know if you
require the patch set and/or new files in a different format,

regards,
Gaius

1-800-GIT-HELP (how to delete a user branch?)

[Gaius Mulley via Gcc]

Just wondering what is the safest way to delete a user branch?

[I used ./contrib/git-add-user-branch.sh and wanted to start over
 (user branch for m2 and gcc12)],
 
many thanks,
Gaius

Re: 1-800-GIT-HELP (how to delete a user branch?)

[Gaius Mulley via Gcc]

Jonathan Wakely  writes:

> On Tue, 25 Oct 2022 at 13:23, Gaius Mulley via Gcc  wrote:
>>
>>
>> Just wondering what is the safest way to delete a user branch?
>>
>> [I used ./contrib/git-add-user-branch.sh and wanted to start over
>>  (user branch for m2 and gcc12)],
>
> When you say start over, do you mean reuse the same branch name for a
> different branch with unrelated history, but using the same name?

yes

> If yes, you can just force push the new history to the branch. That's
> the simplest answer.

great thanks a lot!  I will try this approach

> If you really want to delete the branch, then you just say:
>
> git push --dry-run --delete REMOTE BRANCH
> and if that looks right, remove the --dry-run option.
>
> The REMOTE will be something like users/gaius and BRANCH will be
> something like refs/users/gaius/heads/m2gcc12 depending on how you set
> up your local user branches.

many thanks useful info.

Re: Nonbootstrap build with Apple clang broken in gm2

[Gaius Mulley via Gcc]

FX Coudert  writes:

> Hi,
>
> I am unable to perform a nonbootstrap build when gm2 is included, with
> Apple clang 15 as compiler. The error is due to incorrect inclusion of
> headers ( and ) which are included after GCC’s
> system.h has been included, and macros like abort() are redefined or
> poisoned.
>
> I think the correct idiom in GCC is to #define INCLUDE_STRING (for
> example) before “system.h” is included, rather than #include 
> directly. The attached patch fixes the issue.
>
> Best,
> FX

Hi,

many thanks for the patch - will apply,

regards,
Gaius

Re: Nonbootstrap build with Apple clang broken in gm2

[Gaius Mulley via Gcc]

FX Coudert  writes:

> Another quick m2-related question: I am seeing, in a build of GCC
> 14.1.0 on Linux, that flex is called when building with the modula-2
> front-end. It was not the case in previous builds, and the only
> difference is that I added m2 to the languages. Is that systematic? If
> so, the prerequisites page should be amended:
> https://gcc.gnu.org/install/prerequisites.html
>

Ah yes indeed it is systematic.  Many thanks for spotting this - git
pushed GNU flex required

https://gcc.gnu.org/pipermail/gcc-cvs/2024-July/406305.html

regards,
Gaius

Re: Nonbootstrap build with Apple clang broken in gm2

[Gaius Mulley via Gcc]

FX Coudert  writes:

>> Ah yes indeed it is systematic.  Many thanks for spotting this - git
>> pushed GNU flex required
>> https://gcc.gnu.org/pipermail/gcc-cvs/2024-July/406305.html
>
> Couldn’t the generated files be committed to the tree, so that flex is not 
> needed (unless one modifies the source). This is what is done for the other 
> use of flex.
>
> FX

Thanks for the hint, yes opened PR 116123

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116123

regards,
Gaius