[gpc] Re: GCC integration?

[gpc] Re: GCC integration?

[Thorsten Glaser]

Waldek Hebisch dixit:

(cross-posted to gcc list, please reply to
 the gpc list)

>   appling the patch form `diffs' subdirectory. Going beyond that
>   would be mostly wasted effort, because gcc-3.4.x and coming 4.x
>   are different enough (so one would have to re-do the work for

Exactly this is the cause for the following
request of mine:

Since gcc 4.0 will be out of the door not in less
than two months from now, and given that gcc 4.1,
which ought to solve at least the basic problems
with tree-ssa etc. is not even in sight yet, I
propose that there will be a gcc-3.5 release with
support for Pascal, based upon gcc-3.4, current
gpc and Waldek's patches.

This would be great since we already had the new
directory layout (what I would greatly like to
see for Ada and Pascal is that their RTS moves
from gcc/p/ to libgpc/ ASAP), and the gcc-3.4/3.5
specific diffs integrated into the core, while the
backend patches for gcc 3.3 and older are still
available (I don't think Frank is going to throw
them away after the integration), and so, if you
do _not_ remove the ifdefs from gcc/p/*, you could
do another standalone GPC release based upon the
code in the gcc-3.5 development tree.

While it might also be worthwhile to integrate
Hiroaki Etoh's ProPolice SSP, and probably other
fixes (Apple stuff?), this would mean gcc 3.5
must be an "official" release. If the SC really
is reluctant to do so, it might be feasible to
do a "gpc+gcc 3.5" version, developed as a branch
in the gcc cvs, but not endorsed by the SC.
(Of course, if there'd be interest, one could add
ProPolice to that branch as well, unless you really
want it to be only for your gpc-specific work. If
there is interest, I myself could try to get cvs ci
access to gcc.gnu.org - I've already signed the
relevant forms, and etoh has, too - and integrate
the current propolice; I'm already doing this for
the gcc contained in my OS at the moment).

For others, developers, especially OS vendors, this
would also be great, because history has shown that
gcc 3.x branches tend to end after 3.x.3 or 3.x.4,
and for the aforementioned reasons 4.0/4.1 will not
gain wide acceptance outside of Gentoo (j/k) soon;
if one were to incorporate generic 3.x bugfixes and
maybe backport 4.x bugfixes into a 3.5 series, this
could not only get much adoption, but maybe support
from the large (e.g.) GNU/Linux vendors (Novell?).

This support would lead to a faster distribution of
gpc to "the masses" than releasing a standalone gpc
version now and then integrating it into 4.1/4.2
ever could. Besides, support for 3.4 is "almost" done
for the more common platforms; I doubt gpc will make
it into mainline before it runs on almost all platforms,
and having it in gcc cvs will surely help to both get
more eyes on the code (Nathanael said something like
this IIRC) and get these who do changes to the backend
more aware of gpc.

Just my 0.02 EUR,
//mirabile

Re: [gpc] Re: GCC integration?

[Steven Bosscher]

On Friday 17 December 2004 08:14, Thorsten Glaser wrote:

> Since gcc 4.0 will be out of the door not in less
> than two months from now, and given that gcc 4.1,
> which ought to solve at least the basic problems
> with tree-ssa etc. is not even in sight yet, I
> propose that there will be a gcc-3.5 release with
> support for Pascal, based upon gcc-3.4, current
> gpc and Waldek's patches.

What basic problems with tree-ssa do you see?  As far as I can tell it
pretty much works for everyone now.  You have to be more specific than
this.  Same for Waldek's patches.  If you mean the patches against the
backends, I think you'll find it hard to get them accepted.


> While it might also be worthwhile to integrate
> Hiroaki Etoh's ProPolice SSP, and probably other
> fixes (Apple stuff?), this would mean gcc 3.5
> must be an "official" release.

The problem with ProPolice is not on the GCC side, the maintainer of
that patch is simply not willing to address the comments and concerns
that have been expressed over and again.  And what "Apple stuff" are
you talking about.  And who, do you think, will want to spend effort
on backporting whatever it is you have in mind?


> For others, developers, especially OS vendors, this
> would also be great, because history has shown that
> gcc 3.x branches tend to end after 3.x.3 or 3.x.4,

For GCC 3.3 at least this is not true.  GCC 3.3 is really the first of
the GCC3 series that received wide acceptance.  For the other ones,
apparently nobody was interested in continuing the release branch.

I don't know why you think your idea is great for OS vendors.  As far
as I can tell they're pretty happy with GCC 3.3 (only Fedora Core 3 is
based on GCC 3.4, as far as I can tell), everyone appears to be aiming
for GCC4 for the next major release.


> and for the aforementioned reasons 4.0/4.1 will not
> gain wide acceptance outside of Gentoo (j/k) soon;

What is this assumption based on?  I don't see any "aforementioned"
reasons.


> if one were to incorporate generic 3.x bugfixes and
> maybe backport 4.x bugfixes into a 3.5 series,

GCC 3.x and GCC 4.0 are internally so very different already that you
will find very few bugfixes for GCC 4.0 that you can backport to any
of the GCC 3.x releases.


> this
> could not only get much adoption, but maybe support
> from the large (e.g.) GNU/Linux vendors (Novell?).

If we could fly with the speed of light, and got the support of NASA,
we could visit our friends on Centauri Alpha.  But that's just as
unlikely and hypothetical as your claim here.  ;-)

If any of the large vendors would have been interested in a new GCC3
based release, they would have asked by now.


> This support would lead to a faster distribution of
> gpc to "the masses" than releasing a standalone gpc
> version now and then integrating it into 4.1/4.2
> ever could.

Except that you'd be integrating with an end-of-life infrastructure.
So, one, two years from now when the GCC4 series will be mainstream
compilers, you have to start over with your integration work to keep
gpc available to the masses.


> Besides, support for 3.4 is "almost" done 
> for the more common platforms; I doubt gpc will make
> it into mainline before it runs on almost all platforms,

You could make it so much easier for yourselves if you'd just skip
GCC 3.4 and work against mainline instead.  When you do that, you can
generate target independent code (namely functions as trees, not RTL),
and *poof* gpc would work on all targets, just like that.  The only
concern would be the runtime library, but if it's portable to POSIX-
like targets, that's not such a big concern either.

Of course this also causes other challenges for gpc.  Things like the
SET_TYPE are gone, you'll have to produce code for that yourself in
the front end.  There probably are other things like that which need
rethinking.  On the other hand, the Ada crew (GNAT) managed to do it,
so why not gpc.


> and having it in gcc cvs will surely help to both get
> more eyes on the code (Nathanael said something like
> this IIRC) and get these who do changes to the backend
> more aware of gpc.

IMHO it's those hacking gpc that need to be more aware of GCC ;-)

I'm also a bit puzzled why you'd want a GCC 3.5 based on GCC 3.4 now,
just to get gpc integrated, when for years gpc has hardly tried to be
integrated at all.  Having a GCC 3.5 as you suggests seems to me like
a waste of effort.  Why not just work against GCC 3.4 if you really
want to stay GCC3-based? 

Gr.
Steven

Re: [gpc] Re: GCC integration?

[Steven Bosscher]

On Friday 17 December 2004 08:14, Thorsten Glaser wrote:
> Waldek Hebisch dixit:
>
> (cross-posted to gcc list, please reply to
>  the gpc list)

Nice, but

"Your message to the gpc list has been denied
for the following reason(s):"

(no reason given).

Gr.
Steven

Re: [gpc] Re: GCC integration?

[Robert Dewar]

Steven Bosscher wrote:

> I don't know why you think your idea is great for OS vendors.  As far
> as I can tell they're pretty happy with GCC 3.3 (only Fedora Core 3 is
> based on GCC 3.4, as far as I can tell), everyone appears to be aiming
> for GCC4 for the next major release.

Just for information, the forthcoming release of GNAT Pro is 3.4 based.
It's too early for us to go for GCC 4, though we are certainly working
towards this goal.

Re: [gpc] Re: GCC integration?

[Joseph S. Myers]

On Fri, 17 Dec 2004, Thorsten Glaser wrote:

> Since gcc 4.0 will be out of the door not in less
> than two months from now, and given that gcc 4.1,
> which ought to solve at least the basic problems
> with tree-ssa etc. is not even in sight yet, I
> propose that there will be a gcc-3.5 release with
> support for Pascal, based upon gcc-3.4, current
> gpc and Waldek's patches.

The benefits of integrating gpc into GCC would arise from its inclusion in 
mainline and so in ordinary GCC development, not from its inclusion in old 
release branches.  All new features need to go on mainline before they can 
appear in any release branch.

> This would be great since we already had the new
> directory layout (what I would greatly like to
> see for Ada and Pascal is that their RTS moves
> from gcc/p/ to libgpc/ ASAP), and the gcc-3.4/3.5

I'd consider getting the directory structure right in this way to be 
something that should be done before integration in CVS.  In general front 
ends which are gratuitously different from the rest of those in CVS cause 
trouble.  Similarly all the criteria in sourcebuild.texi should be met, 
and account should be taken of all the cleanups and consistency 
improvements that have gone into GCC CVS in recent years, though we can 
always help with cleanups, consistency and removal of obsolete code only 
relevant for older GCC versions after it goes into CVS.  (But do at least 
compare files such as Make-lang.in with versions from newer front ends 
such as gfortran and give specific justification where things are done 
differently from the usual way in GCC, and update the coding style to that 
now used in GCC, e.g. ISO C90 can be presumed so there should be new-style 
function definitions and unconditional use of prototypes; ` should no 
longer be used as a left quote in diagnostics; generated files in CVS 
should be avoided where possible, with the release script generating those 
needed in releases and update_web_docs generating those needed to build 
the online manuals.  When you actually have a version that works with 
mainline CVS ready to integrate, plenty of people will be willing to help 
with finding such issues.)

The gpc testsuite should also move to under gcc/testsuite.

> them away after the integration), and so, if you
> do _not_ remove the ifdefs from gcc/p/*, you could
> do another standalone GPC release based upon the
> code in the gcc-3.5 development tree.

When code is in GCC mainline people will do global cleanups which will 
include removing code that isn't relevant for mainline.  If you want to do 
releases of GPC with newer GPC code and older GCC code, how you do so is 
up to you, but it will need to be off branches or other development trees.  
(In the case of Ada, the code that depends on the GCC back end is very 
localised in gigi.)

> While it might also be worthwhile to integrate
> Hiroaki Etoh's ProPolice SSP, and probably other

Again, features cannot be integrated in release branches before they are 
in mainline, and they cannot go in mainline if their developers will not 
discuss, explain and adapt them in accordance with the usual development 
procedures.  You will need to be familiar with these procedures 
(develop.html, contribute.html, codingconventions.html and much of the 
rest of the GCC website) to include GPC within GCC development.

> if one were to incorporate generic 3.x bugfixes and
> maybe backport 4.x bugfixes into a 3.5 series, this
> could not only get much adoption, but maybe support
> from the large (e.g.) GNU/Linux vendors (Novell?).

Distributors do backport fixes where appropriate.  They also integrate GPC 
into their releases in some cases.

> for the more common platforms; I doubt gpc will make
> it into mainline before it runs on almost all platforms,

You can put

build_by_default=no

in p/config-lang.in until it is sufficiently ready.

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
    jsm@polyomino.org.uk (personal mail)
    joseph@codesourcery.com (CodeSourcery mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)

Re: [gpc] GCC integration?

[Thorsten Glaser]

Joseph S. Myers dixit:

(gpc, SSP)

>Again, features cannot be integrated in release branches before they are 
>in mainline, and they cannot go in mainline if their developers will not 
>discuss, explain and adapt them in accordance with the usual development 
>procedures.

What about a gcc3-mainline? Development starting from 3.4
and heading towards 3.5, until gpc is mainline-ready and
etoh-san has redesigned SSP for working with tree-ssa?

Not having SSP for gcc4 e.g. is for the BSDs a showstopper.

bye,
//mirabile

Re: [gpc] Re: GCC integration?

[Eric Botcazou]

> I don't know why you think your idea is great for OS vendors.  As far
> as I can tell they're pretty happy with GCC 3.3 (only Fedora Core 3 is
> based on GCC 3.4, as far as I can tell), everyone appears to be aiming
> for GCC4 for the next major release.

Not sure what is your sampling base, but the latest Mandrake is 3.4-based for 
example.

-- 
Eric Botcazou

Re: [gpc] GCC integration?

[Marcel Cox]

Thorsten Glaser wrote:

> 
> What about a gcc3-mainline? Development starting from 3.4
> and heading towards 3.5, until gpc is mainline-ready and
> etoh-san has redesigned SSP for working with tree-ssa?


I think this would be a double bad idea:

1) It would be very bad to have a GCC labeled 3.5. This would just
create the same (or even worse) confusion as when Redhat created their
GCC 2.96

2) I think doing major GPC integration work now based on GCC 3.x is
just a waste of resources and will keep GPC exactly where it is now,
e.g. always one or two versions behind GCC. The only way once and for
all get rid of this running behind is start working based on a *future*
version of GCC now so that once the integration is finished, you have a
current GCC version of GPC integrated.

-- 
Marcel Cox

Re: [gpc] Re: GCC integration?

[Steven Bosscher]

On Dec 17, 2004 12:37 PM, Eric Botcazou <ebotcazou@libertysurf.fr> wrote:

> Not sure what is your sampling base,

Apparently one that's not very representative.  I looked
at a bunch of distro home pages and used Google.

> but the latest Mandrake is 3.4-based for 
> example.

Cool.

Gr.
Steven

Re: [gpc] GCC integration?

[Steven Bosscher]

On Dec 17, 2004 01:00 PM, Marcel Cox <cimetmc@myrealbox.com> wrote:

> 2) I think doing major GPC integration work now based on GCC 3.x is
> just a waste of resources and will keep GPC exactly where it is now,
> e.g. always one or two versions behind GCC. The only way once and for
> all get rid of this running behind is start working based on a *future*
> version of GCC now so that once the integration is finished, you have a
> current GCC version of GPC integrated.

I agree, but some GNU Pascal maintainers apparently don't like
the idea of being an integral part of GCC much.  See this mail
here: http://www.gnu-pascal.de/crystal/gpc/en/mail11128.html
for example.

Gr.
Steven

RE: [gpc] Re: GCC integration?

[Dave Korn]

> -----Original Message-----
> From: gcc-owner On Behalf Of Steven Bosscher
> Sent: 17 December 2004 12:02

> On Dec 17, 2004 12:37 PM, Eric Botcazou wrote:
> 
> > Not sure what is your sampling base,
> 
> Apparently one that's not very representative.  I looked
> at a bunch of distro home pages and used Google.
> 
> > but the latest Mandrake is 3.4-based for 
> > example.
> 
> Cool.
> 
> Gr.
> Steven


  Cygwin is currently in the process of migrating from 3.3 -> 3.4 as well.


    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today.... 

Re: [gpc] Re: GCC integration?

[Gerald Pfeifer]

On Fri, 17 Dec 2004, Steven Bosscher wrote:
> For GCC 3.3 at least this is not true.  GCC 3.3 is really the first of
> the GCC3 series that received wide acceptance.

Both Red Hat and SUSE based their previous enterprise distributions
on 3.2.

> I don't know why you think your idea is great for OS vendors.  As far
> as I can tell they're pretty happy with GCC 3.3 (only Fedora Core 3 is
> based on GCC 3.4, as far as I can tell)

FreeBSD 5.x is using GCC 3.4...

> everyone appears to be aiming for GCC4 for the next major release.

...but I guess FreeBSD 6.x will be based on GCC 4.x.

> If any of the large vendors would have been interested in a new GCC3 
> based release, they would have asked by now.

I fully agree with that.  Now is not the time to ask for GCC 3.5.

Gerald

Re: [gpc] GCC integration?

[Thorsten Glaser]

Marcel Cox dixit:

>2) I think doing major GPC integration work now based on GCC 3.x is
>just a waste of resources

There is not much to do. I integrated gpc into a
BSD in-tree gcc once, and besides having to
rewrite some stuff for BSD make and applying the
diffs correctly, there was next to no work involved.

//mirabile

Re: [gpc] GCC integration?

[Thorsten Glaser]

Dave Korn dixit:

>> > but the latest Mandrake is 3.4-based for 
>> > example.

>  Cygwin is currently in the process of migrating from 3.3 -> 3.4 as well.

MirOS too (from 3.2). OpenBSD seems to stay with 3.3,
and even uses 2.95 for most arches (eg. i386).

Can't comment on other OSes except Windows (using Interix 3.5)
since I don't even have machines to use them ;)

bye,
//mirabile

Re: [gpc] Re: GCC integration?

[Joel Sherrill <joel@OARcorp.com>]

Dave Korn wrote:
>>-----Original Message-----
>>From: gcc-owner On Behalf Of Steven Bosscher
>>Sent: 17 December 2004 12:02
> 
> 
>>On Dec 17, 2004 12:37 PM, Eric Botcazou wrote:
>>
>>
>>>Not sure what is your sampling base,
>>
>>Apparently one that's not very representative.  I looked
>>at a bunch of distro home pages and used Google.
>>
>>
>>>but the latest Mandrake is 3.4-based for 
>>>example.
>>
>>Cool.
>>
>>Gr.
>>Steven
> 
> 
> 
>   Cygwin is currently in the process of migrating from 3.3 -> 3.4 as well.

The last release branch of RTEMS used 3.2 but the development head
is in the process of moving to 3.4 with some testing against the
head.

The tighter warning and error checks have resulted in work to
get rid of warnings.  We try very hard to be warning free.

>     cheers, 
>       DaveK


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985

Re: [gpc] GCC integration?

[Joseph S. Myers]

On Fri, 17 Dec 2004, Thorsten Glaser wrote:

> What about a gcc3-mainline? Development starting from 3.4
> and heading towards 3.5, until gpc is mainline-ready and
> etoh-san has redesigned SSP for working with tree-ssa?

SSP is entirely unrelated to GPC.  The issue for SSP isn't a redesign for 
working with tree-ssa, it's that the author has been generally unreceptive 
to comments, not adapted or split the patch as suggested and only 
infrequently sends monolithic patches against old versions.  If he wants 
it considered then during the next Stage 1 he should send minimal 
components of a version updated to mainline (there was at least one 
suggestion in the past of how it might be split up) with answers to all 
the various past comments making clear how they have been addressed and 
that he has become willing to engage in the normal development and 
discussion process.  (It would also be possible for someone other than the 
author of the patch to do this - split out and rework parts for submission 
- if they feel the patch is important and are more willing to engage in 
the normal discussion.)

If GPC maintainers want GPC integrated, start working now towards basing 
it on the current mainline infrastructure with the same directory 
structure and infrastructure and coding style and conventions as other 
front ends and runtime libraries use and then submit a detailed proposal 
for integration when Mark posts his call for 4.1 projects to the gcc list.

In any case, where back-end patches are required, submit them now if they 
fix regressions from any previous GCC release (and be sure that PRs are 
open in Bugzilla), or when mainline opens for non-regression fixes 
otherwise (but if they fix bugs, again ensure that bugs are open in 
Bugzilla with the "patch" keyword).  Of course, expect to discuss the 
patches and create new revisions of them.

> Not having SSP for gcc4 e.g. is for the BSDs a showstopper.

In that case BSD people might wish to read all the past comments on SSP 
and submit reworked patches themselves, the original author having gained 
such a reputation for not engaging with the normal process that his 
patches are now simply ignored.  Patches do not need to be integrated by 
their original authors if someone else can do the job better.

Is GPC CVS available?  A repository was announced some time ago 
<http://www.gnu-pascal.org/crystal/gpc-announce/en/mail-10.html> but 
doesn't seem to be working at that location at present.

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
    jsm@polyomino.org.uk (personal mail)
    joseph@codesourcery.com (CodeSourcery mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)

Re: [gpc] Re: GCC integration?

[Gabriel Dos Reis]

Releasing a 3.5.x compiler with Pascal support and a 4.0 series
without does not make any sense to me.  I would strongly urge that
people inetrested in integrating gpc ini FSF GCC work hard on 4.1.x.
Resources will be best spent there.


[...]

| > For others, developers, especially OS vendors, this
| > would also be great, because history has shown that
| > gcc 3.x branches tend to end after 3.x.3 or 3.x.4,

But we got 3.3.5 and we're going to get 3.3.5


Steven Bosscher <stevenb@suse.de> writes:

| For GCC 3.3 at least this is not true.  GCC 3.3 is really the first of
| the GCC3 series that received wide acceptance.  For the other ones,
| apparently nobody was interested in continuing the release branch.

Ending 3.2.x series at 3.2.3 was a decision made after 3.3.x had been
released and people shifting there.  I did not see any wide need to
continue releasing from that series.  The situation for 3.3.x is
radically different from that of 3.2.x.

-- Gaby

Re: [gpc] GCC integration?

[Gabriel Dos Reis]

Thorsten Glaser <tg@66h.42h.de> writes:

| Joseph S. Myers dixit:
| 
| (gpc, SSP)
| 
| >Again, features cannot be integrated in release branches before they are 
| >in mainline, and they cannot go in mainline if their developers will not 
| >discuss, explain and adapt them in accordance with the usual development 
| >procedures.
| 
| What about a gcc3-mainline? Development starting from 3.4
| and heading towards 3.5, 

A GCC-3.5 with Pascal and a GCC-4.0 does nto make any sense to me.

What about spending the resources on 4.1?

| until gpc is mainline-ready and
| etoh-san has redesigned SSP for working with tree-ssa?
| 
| Not having SSP for gcc4 e.g. is for the BSDs a showstopper.
| 
| bye,
| //mirabile

-- 
                                                       Gabriel Dos Reis 
                                           gdr@integrable-solutions.net

Re: [gpc] Re: GCC integration?

[Mike Stump]

On Thursday, December 16, 2004, at 11:14  PM, Thorsten Glaser wrote:
> Since gcc 4.0 will be out of the door not in less than two months from 
> now, and given that gcc 4.1, which ought to solve at least the basic 
> problems with tree-ssa etc. is not even in sight yet, I propose that 
> there will be a gcc-3.5 release with support for Pascal, based upon 
> gcc-3.4, current gpc and Waldek's patches.

I propose that Pascal be put into 4.0, and after that works, then we 
consider what is next.  Personally I wouldn't mind seeing it in 4.0, 
assuming you don't need large or complex or destabilizing or dangerous 
or gross changes to the non-gcc/gpc files; otherwise 4.1.

This is just how we do engineering work, first, fix mainline, then, if 
important enough and safe enough, then fix older release branches.

Re: [gpc] Re: GCC integration?

[Joel Sherrill <joel@OARcorp.com>]

Joel Sherrill <joel@OARcorp.com> wrote:
> Dave Korn wrote:
> 
>>> -----Original Message-----
>>> From: gcc-owner On Behalf Of Steven Bosscher
>>> Sent: 17 December 2004 12:02
>>
>>
>>
>>> On Dec 17, 2004 12:37 PM, Eric Botcazou wrote:
>>>
>>>
>>>> Not sure what is your sampling base,
>>>
>>>
>>> Apparently one that's not very representative.  I looked
>>> at a bunch of distro home pages and used Google.
>>>
>>>
>>>> but the latest Mandrake is 3.4-based for example.
>>>
>>>
>>> Cool.
>>>
>>> Gr.
>>> Steven
>>
>>
>>
>>
>>   Cygwin is currently in the process of migrating from 3.3 -> 3.4 as 
>> well.
> 
> 
> The last release branch of RTEMS used 3.2 but the development head
> is in the process of moving to 3.4 with some testing against the
> head.
> 
> The tighter warning and error checks have resulted in work to
> get rid of warnings.  We try very hard to be warning free.

I should have also mentioned that gcc 3.3.4 isn't error free
from our perspective.  The ARM soft-float issue, C++ on
MIPS doesn't honor the same Gn setting as C defaults to,
and a couple of compilation problems.

And our perspective is strictly on C and C++.  Building Ada
has had its own set of issues that haven't bubbled to the top
of our worries.

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985

Re: [gpc] Re: GCC integration?

[Gabriel Dos Reis]

What is the point of sending me an email with a CC: to a list that is
closed and that rejects answers from me?

Thorsten Glaser <tg@66h.42h.de> writes:

| Gabriel Dos Reis dixit:
| 
| >The situation for 3.3.x is
| >radically different from that of 3.2.x.
| 
| The files in gcc/gcc/config/ from 3.3 are radically different
| from 3.2, which made it
|  a) not feasible for MirOS to upgrade to 3.3
|  b) not easy for gpc (if I remember the mailing list stuff correctly).

I don't see what you're talking about but it is certainly true that
you've taken my sentence out of context and make it say anything you
want.  Is that the usual working procedure for GPC?

-- Gaby

Re: [gpc] GCC integration?

[Marc Espie]

OpenBSD is slowly migrating to gcc 3.3.x.

We have a 3.3.2 -> 3.3.5 patch getting tested... yeah, I know, it's a
bit late, but we've got a LOT of other things happening.`

Arches are slowly going over from gcc 2.95 to gcc 3.3...

We don't think we will go to gcc 3.4 until we need it. There's the
daunting task of fixing even more C++ issues (which is great on one
hand, because the C++ compiler is clearly improving, but still a
nightmare from a port maintainer's perspective).

I'm trying to find someone to prod Etoh to try and get propolice
seriously integrated.  


I'm still a bit surprised.  After all, we managed to do it in OpenBSD,
and we're not generally a group that is known for its GREAT
communication skills.  Could it be that the GCC developpers are even
worse ? ;-)

Re: [gpc] GCC integration?

[Florian Weimer]

* Marc Espie:

> I'm still a bit surprised.  After all, we managed to do it in OpenBSD,
> and we're not generally a group that is known for its GREAT
> communication skills.  Could it be that the GCC developpers are even
> worse ? ;-)

Currently, GCC and GPC are separate projects which share some code,
much like the BSDs. 8-)