gcc-2.8.0 mailing list ?

gcc-2.8.0 mailing list ?

[Matthias Kurz]

Hi.

Is there a list like this for gcc-2.8 ? Is there a web page or other
information ?
Does egcs/gcc-2.8 support profiling under Solaris-x86 ?
Does egcs/gcc-2.8 under Solaris-x86 generate 'out of the box' debugging
information for c++ that is understandable by gdb ?

  Thanks

   (mk)

PS: Does anybody know what happened to GNU Modula-2 ?

-- 
Matthias Kurz; Fuldastr. 3; D-28199 Bremen; VOICE +49 421 53 600 47

Re: gcc-2.8.0 mailing list ?

[Michael Neuffer]

On Sat, 27 Dec 1997, Matthias Kurz wrote:
> PS: Does anybody know what happened to GNU Modula-2 ?

While talking about Modula*:

Does anyone know if there is anybody still working on
SRC-Modula3 ? 

It can be found on http://www.research.digital.com/SRC/modula-3/html/
and is based on an anicient gcc (2.3.something or so).


Mike

Re: gcc-2.8.0 mailing list ?

[John Polstra]

In article < Pine.OSF.3.95.971227204730.10273E-100000@kralle.zdv.Uni-Mainz.DE >,
Michael Neuffer  <neuffer@goofy.zdv.uni-mainz.de> wrote:

> Does anyone know if there is anybody still working on
> SRC-Modula3 ? 

Yes, there is still development going on.  The folks at SRC aren't
doing too much on it any more, but other developers have picked it
up.  There's even a commercial version -- see < http://www.cmass.com >.
The newsgroup for the language is "comp.lang.modula3".  It has a
relatively low signal to noise ratio.

> It can be found on http://www.research.digital.com/SRC/modula-3/html/
> and is based on an anicient gcc (2.3.something or so).

It's not quite _that_ ancient.  The code generator is based on GCC
2.6.3.  I updated it fairly painlessly to the 2.7.2.1 code generator,
and that's the version used under FreeBSD.  The Modula-3 specific
files for the 2.7.2.1 code generator can be found at:

ftp://ftp.freebsd.org/pub/FreeBSD/distfiles/LOCAL_PORTS/m3-fbsd-m3cc-3.6.tar.gz

John
--
   John Polstra                                       jdp@polstra.com
   John D. Polstra & Co., Inc.                Seattle, Washington USA
   "Self-knowledge is always bad news."                 -- John Barth

Re: gcc-2.8.0 mailing list ?

[Jeffrey A Law]

  In message < 9712271745.aa04767@baerlap.north.de >you write:
  > Is there a list like this for gcc-2.8 ?
Yes, but it is a private list.


  > Is there a web page or other information ?
http://www.gnu.org/software/gcc/gcc.html

  > Does egcs/gcc-2.8 support profiling under Solaris-x86 ?
Don't know -- if it's not supported, then that might be a good
beginner project for someone that needs support for profiling
on that platform.  I see lots of stuff that relates to profiling
for solaris-x86, so hopefully it actually works.

  > Does egcs/gcc-2.8 under Solaris-x86 generate 'out of the box' debugging
  > information for c++ that is understandable by gdb ?
It defaults to the same debug symbols as the native compiler on that
system, dwarf1 I believe.  And dwarf1's support for C++ is marginal
at best.

It also supports gdb and dwarf2 as command line options, which should
work much better with C++.


jeff

Re: gcc-2.8.0 mailing list ?

[Michael Neuffer]

On Sat, 27 Dec 1997, John Polstra wrote:
> > Does anyone know if there is anybody still working on
> > SRC-Modula3 ? 
> 
> Yes, there is still development going on.  The folks at SRC aren't
> doing too much on it any more, but other developers have picked it
> up.  There's even a commercial version -- see < http://www.cmass.com >.

There is a non-commercial branch from SRC-M3 which seems to be much more
active: Cambridge Modula-3

http://www.cl.cam.ac.uk/m3doc/linux/cambridge.html

Richard Watts <Richard.Watts@cl.cam.ac.uk> is working on getting 
CAM3 to work with glibc 2. The same patches would probably then also fit
for SRC-M3 

> The newsgroup for the language is "comp.lang.modula3".  It has a
> relatively low signal to noise ratio.

> > It can be found on http://www.research.digital.com/SRC/modula-3/html/
> > and is based on an anicient gcc (2.3.something or so).
> 
> It's not quite _that_ ancient.  The code generator is based on GCC
> 2.6.3.

Ooops. Mea Culpa. I should have looked at it again.

> I updated it fairly painlessly to the 2.7.2.1 code generator,
> and that's the version used under FreeBSD.  The Modula-3 specific
> files for the 2.7.2.1 code generator can be found at:
> 
> ftp://ftp.freebsd.org/pub/FreeBSD/distfiles/LOCAL_PORTS/m3-fbsd-m3cc-3.6.tar.gz

Did anyone ever think about integrating M3 with gcc/egcs as an additional
frontend similar to the Fortran and Pascal frontends ?

I think that would make more sense in the long run then duplicating or
even triplicating porting efforts of different (semi-)independent 
branches.

Mike

Re: gcc-2.8.0 mailing list ?

[Richard Watts]

On Sun 28 December 1997, Michael Neuffer
<neuffer@goofy.zdv.uni-mainz.de> wrote:

>On Sat, 27 Dec 1997, John Polstra wrote:
>> > Does anyone know if there is anybody still working on
>> > SRC-Modula3 ? 
>> 
>> Yes, there is still development going on.  The folks at SRC aren't
>> doing too much on it any more, but other developers have picked it
>> up.  There's even a commercial version -- see < http://www.cmass.com >.
>
>There is a non-commercial branch from SRC-M3 which seems to be much more
>active: Cambridge Modula-3
>
> http://www.cl.cam.ac.uk/m3doc/linux/cambridge.html

 :-). You might also want to have a look at polymtl M3 - Cam3 and pm3 
tend to get things added to them as and when the maintainers have effort
available, but pm3 tend to have more effort available. There are plans 
afoot to merge the distributions just as soon as we can figure out 
how :-).

>
>Richard Watts <Richard.Watts@cl.cam.ac.uk> is working on getting 
>CAM3 to work with glibc 2. The same patches would probably then also fit
>for SRC-M3 

 Apart from some problems with m3gdb, reported by  Rajat Datta 
<rajat@ix.netcom.com> and the fact that I forgot to add a declaration for
getcwd :

<*EXTERNAL*> PROCEDURE getcwd (pathname: char_star; count : int): char_star;

 (also thanks to rajat@ix.netcom.com, who spotted that), you can pick
up some (very basic: I didn't have time to package them properly) patches 
for glibc2 support for Cam3 from

ftp://epona.ucam.org/pub/users/rrw/Cam3-LINUXLIBC6.tgz 

 I'm still having problems with X binaries, but I suspect that's
just a problem with my setup (Rajat didn't seem to have any problems with
RH 5).

 I'll get around to packaging the glibc2 patches up properly when I 
get back to college - probably around the 6th or 7th: the interactive
performance of this 'net link is awful (mutter mutter the good old days
mutter mutter 2400 baud mutter mutter bloody web traffic mutter :-()

[snip]
>> It's not quite _that_ ancient.  The code generator is based on GCC
>> 2.6.3.
>
>Ooops. Mea Culpa. I should have looked at it again.

 I think polymtl M3 has a more recent backend, but don't quote me on 
that..

>
>> I updated it fairly painlessly to the 2.7.2.1 code generator,
>> and that's the version used under FreeBSD.  The Modula-3 specific
>> files for the 2.7.2.1 code generator can be found at:
>> 
>> ftp://ftp.freebsd.org/pub/FreeBSD/distfiles/LOCAL_PORTS/m3-fbsd-m3cc-3.6.tar.gz
>
>Did anyone ever think about integrating M3 with gcc/egcs as an additional
>frontend similar to the Fortran and Pascal frontends ?

 Yes. It would be nice, but it would also probably be a lot of work,
probably wouldn't be supported (I presume the frontends need to be
written in C/have the same general invocation requirements/whatever
to be supported ?), and (more importantly) runs into copyright 
difficulties: I don't want to infect the Cam3 compiler with the 
GPL. 

 What are the current maintenance arrangements for the multiple
frontends ?

>
>I think that would make more sense in the long run then duplicating or
>even triplicating porting efforts of different (semi-)independent 
>branches.

 Well, yes and no: porting efforts are mostly in the realm of getting
the C API right (the glibc2 port, for example, is just a set of 
replacements for the Unix and C interfaces which need to be equivalent
to the C header files), so it'd have to be done anyway, and as John
Polstra says, these are pretty much uniform over all branches, so
porting only has to be done once anyway (SRC and polymtl can more or
less copy Cam3, and vice versa).

 Where integration would help would be to make sure that the M3
compiler could take full advantage of new gcc features (mainly
optimisation), and avoid bugs in the m3/m3cc interface (ie. bad
optimisation hints).

 A large amount of maintenance effort actually tends to go into 
either changing compiler functionality or maintaining the libraries.


Richard.
[with apologies for the spelling mistakes: this net link is dreadful]

M3 and gcc/egcs (was: Re: gcc-2.8.0 mailing list ?)

[Michael Neuffer]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4399 bytes --]

On Sun, 28 Dec 1997, Richard Watts wrote:
> >> > Does anyone know if there is anybody still working on
> >> > SRC-Modula3 ? 
> >> 
> >> Yes, there is still development going on.  The folks at SRC aren't
> >> doing too much on it any more, but other developers have picked it
> >> up.  There's even a commercial version -- see < http://www.cmass.com >.
> >
> >There is a non-commercial branch from SRC-M3 which seems to be much more
> >active: Cambridge Modula-3
> >
> > http://www.cl.cam.ac.uk/m3doc/linux/cambridge.html
> 
>  :-). You might also want to have a look at polymtl M3 - Cam3 and pm3 
> tend to get things added to them as and when the maintainers have effort
> available, but pm3 tend to have more effort available. 

Where can I find it ?

> There are plans 
> afoot to merge the distributions just as soon as we can figure out 
> how :-).

:-)

> >Richard Watts <Richard.Watts@cl.cam.ac.uk> is working on getting 
> >CAM3 to work with glibc 2. The same patches would probably then also fit
> >for SRC-M3 
> 
>  Apart from some problems with m3gdb, reported by  Rajat Datta 
> <rajat@ix.netcom.com> and the fact that I forgot to add a declaration for
> getcwd :
> 
> <*EXTERNAL*> PROCEDURE getcwd (pathname: char_star; count : int): char_star;
> 
>  (also thanks to rajat@ix.netcom.com, who spotted that), you can pick
> up some (very basic: I didn't have time to package them properly) patches 
> for glibc2 support for Cam3 from
> 
> ftp://epona.ucam.org/pub/users/rrw/Cam3-LINUXLIBC6.tgz 
> 
>  I'm still having problems with X binaries, but I suspect that's
> just a problem with my setup (Rajat didn't seem to have any problems with
> RH 5).

John, do you think this might be enough to get CVSup running ?

>  I'll get around to packaging the glibc2 patches up properly when I 
> get back to college - probably around the 6th or 7th: the interactive
> performance of this 'net link is awful (mutter mutter the good old days
> mutter mutter 2400 baud mutter mutter bloody web traffic mutter :-()

I can understand your feelings. I often see >40% package drops on
connections within Germany. 

> >> It's not quite _that_ ancient.  The code generator is based on GCC
> >> 2.6.3.
> >
> >Ooops. Mea Culpa. I should have looked at it again.
> 
>  I think polymtl M3 has a more recent backend, but don't quote me on 
> that..
> 
> >
> >> I updated it fairly painlessly to the 2.7.2.1 code generator,
> >> and that's the version used under FreeBSD.  The Modula-3 specific
> >> files for the 2.7.2.1 code generator can be found at:
> >> 
> >> ftp://ftp.freebsd.org/pub/FreeBSD/distfiles/LOCAL_PORTS/m3-fbsd-m3cc-3.6.tar.gz
> >
> >Did anyone ever think about integrating M3 with gcc/egcs as an additional
> >frontend similar to the Fortran and Pascal frontends ?
> 
>  Yes. It would be nice, but it would also probably be a lot of work,
> probably wouldn't be supported (I presume the frontends need to be
> written in C/have the same general invocation requirements/whatever
> to be supported ?), and (more importantly) runs into copyright 
> difficulties: I don't want to infect the Cam3 compiler with the 
> GPL. 

What copyright is it under at the moment ?

>  What are the current maintenance arrangements for the multiple
> frontends ?

I´m not sure. 

Maybe some of the Pascal or Fortran developers could comment on that ?
The Fortran and Pascal are definitely under GNU copyright.

> >I think that would make more sense in the long run then duplicating or
> >even triplicating porting efforts of different (semi-)independent 
> >branches.
> 
>  Well, yes and no: porting efforts are mostly in the realm of getting
> the C API right (the glibc2 port, for example, is just a set of 
> replacements for the Unix and C interfaces which need to be equivalent
> to the C header files), so it'd have to be done anyway, and as John
> Polstra says, these are pretty much uniform over all branches, so
> porting only has to be done once anyway (SRC and polymtl can more or
> less copy Cam3, and vice versa).
> 
>  Where integration would help would be to make sure that the M3
> compiler could take full advantage of new gcc features (mainly
> optimisation), and avoid bugs in the m3/m3cc interface (ie. bad
> optimisation hints).
> 
>  A large amount of maintenance effort actually tends to go into 
> either changing compiler functionality or maintaining the libraries.

I see. 


Mike

Re: M3 and gcc/egcs (was: Re: gcc-2.8.0 mailing list ?)

[Richard Watts]

On Sun 28 December 1997, Michael Neuffer
<neuffer@goofy.zdv.uni-mainz.de> wrote:

>On Sun, 28 Dec 1997, Richard Watts wrote:
>> >> > Does anyone know if there is anybody still working on
>> >> > SRC-Modula3 ?=20
>> >>=20
[snip]
>> available, but pm3 tend to have more effort available.=20
>
>Where can I find it ?

 Try http://www.m3.org - feel free to point them to the glibc mods
on epona - they're not particularly private: I just don't want people
using them without being aware that they're not terribly well tested
yet.

[snip]
>> get back to college - probably around the 6th or 7th: the interactive
>> performance of this 'net link is awful (mutter mutter the good old days
>> mutter mutter 2400 baud mutter mutter bloody web traffic mutter :-()
>
>I can understand your feelings. I often see >40% package drops on
>connections within Germany.=20

 :-((. It seems that demon has decided to optimise for web traffic,
so I'm getting high bandwidth, high latency connections. This is not
good for interactive editing (I can't really use off-line composition
easily 'cos the machine handling the mail is down an ssh link off
a machine I'm connecting to via SSL. The wonders of modern computer 
security...).

 OTOH, if you use their web proxy (or even if you don't), web access
is nice and fast.

[snip]
>>  Yes. It would be nice, but it would also probably be a lot of work,
>> probably wouldn't be supported (I presume the frontends need to be
>> written in C/have the same general invocation requirements/whatever
>> to be supported ?), and (more importantly) runs into copyright=20
>> difficulties: I don't want to infect the Cam3 compiler with the=20
>> GPL.=20
>
>What copyright is it under at the moment ?

 The DEC SRC Modula-3 copyright, which is basically BSD with 
extra legalese: the Cam3 site ought to have a copy: yell if it doesn't,
and I'll mail you one.

>
>>  What are the current maintenance arrangements for the multiple
>> frontends ?
>
>I=B4m not sure.=20
>
>Maybe some of the Pascal or Fortran developers could comment on that ?
>The Fortran and Pascal are definitely under GNU copyright.

 Indeed :-) - it would be nice to have some sort of formal integration
with the gcc folks, though perhaps a better solution (if it's feasable:
I haven't hacked gcc much) would be to document the API and make
the gcc backend and optimiser a library under the LGPL, but that 
would probably cause other sorts of copyright problems...

[snip]


Richard.

Re: M3 and gcc/egcs (was: Re: gcc-2.8.0 mailing list ?)

[Jeffrey A Law]

  In message <Pine.OSF.3.95.971228231257.18838K-100000@kralle.zdv.Uni-Mainz.DE> you write:
  > > >> It's not quite _that_ ancient.  The code generator is based on GCC
  > > >> 2.6.3.
  > > >
  > > >Ooops. Mea Culpa. I should have looked at it again.
  > > 
  > >  I think polymtl M3 has a more recent backend, but don't quote me on 
  > > that..
Well, gcc-2.6 is so old I can't even remember any distinguishing features...

gcc-2.7 is about 2 years old, still ancient by my standards :-)

There's probably a significant amount of work involved with just bringing
it up to a reasonable code base.  I can't take on any more work, but I am
willing to provide guidance if someone wants to start to bring M3 into
the egcs era.

  > >  Yes. It would be nice, but it would also probably be a lot of work,
Probably.

  > > probably wouldn't be supported
Depends on what state it's in and whether or not the M3 developers want
to support it.


  > > (I presume the frontends need to be
  > > written in C/have the same general invocation requirements/whatever
  > > to be supported ?),
This used to be the case, but I suspect we'll start to relax this 
restriction as we start thinking about how to integrate Ada (which
is written in Ada).

  > > and (more importantly) runs into copyright 
  > > difficulties: I don't want to infect the Cam3 compiler with the 
  > > GPL. 
Ouch.  That's a problem.


  > >  Where integration would help would be to make sure that the M3
  > > compiler could take full advantage of new gcc features (mainly
  > > optimisation), and avoid bugs in the m3/m3cc interface (ie. bad
  > > optimisation hints).
I also think that moving to egcs will reduce the long term problems with
interfaces inside the compiler changing and because we don't have prototypes
nobody finds out until the compimler mis-compiles something because some
function was missing an argument.

We're certainly not fully prototyped yet, but we are making progress.

  > >  A large amount of maintenance effort actually tends to go into 
  > > either changing compiler functionality or maintaining the libraries.
Libraries certainly require a fair amount of work, and it just gets harder
when you start having to worry about multilibs, cross compiles, etc.  We're
running into these issues with Fortran.

Much of the solution (IMHO) is to move the runtime libraries to their own
toplevel directory (ala libstdc++/libio in the egcs dist).  This really
helps chicken and the egg problems with cross compiles.

jeff

Re: M3 and gcc/egcs (was: Re: gcc-2.8.0 mailing list ?)

[Jeffrey A Law]

  In message <E0xmhcC-0002po-00@canada.cl.cam.ac.uk>you write:
  > I haven't hacked gcc much) would be to document the API and make
This certainly needs doing -- there's basically no docs for the
front-end interfaces into the compiler.

  > the gcc backend and optimiser a library under the LGPL, but that 
  > would probably cause other sorts of copyright problems...
Probably so.  I think this is a can of worms best left closed.

jeff