GCC 3.1 Release

GCC 3.1 Release

[Mark Mitchell]

We are nearing the end of the GCC 3.1 release cycle.  There are just
a couple of high-priority PRs outstanding.  We will fix them, and then
ship the release.

Therefore, as of now, I will be accepting *no* patches that do not fix
regressions.  If you want me to approve a patch for GCC 3.1, please tell
me that you know that it fixes an actual regression.

Otherwise, I will not accept the patch, even if it is trivial, obvious,
safe, and you have a note from your mother. :-)

I apologize for the delays in the release.  We've needed them in order
to get the quality up, but that reflects that we let the mainline get
too shoddy.  It also means that we started doing serious testing
too late.  Let's do better in GCC 3.2.

Thanks,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC 3.1 Release

[Florian Weimer]

Mark Mitchell <mark@codesourcery.com> writes:

> Therefore, as of now, I will be accepting *no* patches that do not fix
> regressions.

Can we change the following two things, even if they aren't
regressions?

a) Document in the build instructions that having CC = ADAC is
   required, or fix ./configure so that -Wno-long-long is not passed
   to ADAC.

b) Include the patch at:

   http://gcc.gnu.org/ml/gcc-patches/2002-05/msg00459.html

   (The patch hasn't been approved by one of the Ada maintainers yet.)

   Without that patch, the Ada front end cannot be built at all.

Re: GCC 3.1 Release

[Andreas Schwab]

Florian Weimer <fw@deneb.enyo.de> writes:

|> Mark Mitchell <mark@codesourcery.com> writes:
|> 
|> > Therefore, as of now, I will be accepting *no* patches that do not fix
|> > regressions.
|> 
|> Can we change the following two things, even if they aren't
|> regressions?

They _are_ regressions, because they cause bootstrap failures.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE GmbH, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: GCC 3.1 Release

[Mark Mitchell]

--On Monday, May 06, 2002 12:24:31 PM +0200 Andreas Schwab <schwab@suse.de> 
wrote:

> Florian Weimer <fw@deneb.enyo.de> writes:
>
> |> Mark Mitchell <mark@codesourcery.com> writes:
> |>
> |> > Therefore, as of now, I will be accepting *no* patches that do not
> fix |> > regressions.
> |>
> |> Can we change the following two things, even if they aren't
> |> regressions?
>
> They _are_ regressions, because they cause bootstrap failures.

May I have a pointer to the patches you want checked in?

Thanks,

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: GCC 3.1 Release

[Andreas Schwab]

Mark Mitchell <mark@codesourcery.com> writes:

|> --On Monday, May 06, 2002 12:24:31 PM +0200 Andreas Schwab
|>   <schwab@suse.de> wrote:
|> 
|> > Florian Weimer <fw@deneb.enyo.de> writes:
|> >
|> > |> Mark Mitchell <mark@codesourcery.com> writes:
|> > |>
|> > |> > Therefore, as of now, I will be accepting *no* patches that do not
|> > fix |> > regressions.
|> > |>
|> > |> Can we change the following two things, even if they aren't
|> > |> regressions?
|> >
|> > They _are_ regressions, because they cause bootstrap failures.
|> 
|> May I have a pointer to the patches you want checked in?

For the line-too-long problem:

http://gcc.gnu.org/ml/gcc-patches/2002-05/msg00459.html

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE GmbH, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: GCC 3.1 Release

[Mark Mitchell]

--On Monday, May 06, 2002 04:57:28 PM +0200 Andreas Schwab <schwab@suse.de> 
wrote:

> Mark Mitchell <mark@codesourcery.com> writes:
>
>|> --On Monday, May 06, 2002 12:24:31 PM +0200 Andreas Schwab
>|>   <schwab@suse.de> wrote:
>|>
>|> > Florian Weimer <fw@deneb.enyo.de> writes:
>|> >
>|> > |> Mark Mitchell <mark@codesourcery.com> writes:
>|> > |>
>|> > |> > Therefore, as of now, I will be accepting *no* patches that do
>|> > |> > not
>|> > fix |> > regressions.
>|> > |>
>|> > |> Can we change the following two things, even if they aren't
>|> > |> regressions?
>|> >
>|> > They _are_ regressions, because they cause bootstrap failures.
>|>
>|> May I have a pointer to the patches you want checked in?
>
> For the line-too-long problem:
>
> http://gcc.gnu.org/ml/gcc-patches/2002-05/msg00459.html

That patch is OK.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC 3.1 Release

[Andreas Schwab]

Mark Mitchell <mark@codesourcery.com> writes:

|> --On Monday, May 06, 2002 04:57:28 PM +0200 Andreas Schwab
|>   <schwab@suse.de> wrote:
|> 
|> > Mark Mitchell <mark@codesourcery.com> writes:
|> >
|> >|> --On Monday, May 06, 2002 12:24:31 PM +0200 Andreas Schwab
|> >|>   <schwab@suse.de> wrote:
|> >|>
|> >|> > Florian Weimer <fw@deneb.enyo.de> writes:
|> >|> >
|> >|> > |> Mark Mitchell <mark@codesourcery.com> writes:
|> >|> > |>
|> >|> > |> > Therefore, as of now, I will be accepting *no* patches that do
|> >|> > |> > not
|> >|> > fix |> > regressions.
|> >|> > |>
|> >|> > |> Can we change the following two things, even if they aren't
|> >|> > |> regressions?
|> >|> >
|> >|> > They _are_ regressions, because they cause bootstrap failures.
|> >|>
|> >|> May I have a pointer to the patches you want checked in?
|> >
|> > For the line-too-long problem:
|> >
|> > http://gcc.gnu.org/ml/gcc-patches/2002-05/msg00459.html
|> 
|> That patch is OK.

Thanks.  I checked it in and also took the liberty to check in
<http://gcc.gnu.org/ml/gcc-patches/2002-05/msg00601.html>.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE GmbH, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: GCC 3.1 Release

[Richard Kenner]

    There's also the problem that some people don't seem to want to invest
    very much effort to fix problems on platforms they don't use, even
    when it's clear they created the problem.  That's a social issue.

Not completely.  In some cases I recall, what happened was that a patch
triggered a latent bug on some machine.  Fixing that can often require
quite intimiate knowlege of the structure of that machine and/or port,
so it's not just a matter of unwillingness to fix it but it can often be
inability.  I see this as a serious problem because from a project point
of view we don't want to let a useful and totally correct improvement not be
applied because of some latent bug in a not-widely-used target.  But that
doesn't mean we want to break that target either.  I don't think there's a
good solution to this problem.

Re: GCC 3.1 Release

[Robert Dewar]

what we do with the GNAT releases, which has worked well is to issue a
candidate release. Then we encourage all customers to try out this new
release and report problems and regressions.

We fix *ONLY* regressions, and *ONLY* if the fix is safe. We do not allow
any other fixes into the final release which follows a few months later.

Re: GCC 3.1 Release

[Robert Dewar]

<<In fact what I'd really like to see is a requirement for such a
regression tester for every platform that is considered release
critical.  (I'm sure the logistics of this are difficult.)
>>

I strongly support this. It is certainly what we do at ACT (we build all
versions every night, and immediately fix or backout any changes that break
any target).

Mark> The amount of breakage since GCC 3.0 continues to amaze me.

It does not surprise me so much. At this stage, it would somewhat surprise me
if we were NOT running into this kind of breakage in the absence of systematic
multi-platform regression testing.

I know that it would be near to impossible to keep GNAT highly stable without
this kind of regression testing.

GCC 3.1 Release

[Mark Mitchell]

As should be clear at this point, there is no way that we are going
to be shipping GCC 3.1 on Monday.

The amount of breakage since GCC 3.0 continues to amaze me.

We still have about 30 open bugs that we need to try to resolve
for this release.

To that end, I'm as of now slipping the GCC 3.1 release date by two
weeks, until May 1st.

I have a proposal before the SC to slip the GCC 3.2 schedule even
further; so that the first phase of GCC 3.2 development will now end
one month  beyond the release of GCC 3.1 -- June 1st -- pushing the
GCC 3.2  release date back to October 1st so as to give people time to
work on major changes for GCC 3.2 *after* GCC 3.1 is released.

Please concentrate on GCC 3.1 to the best of your ability.  And please
think very carefully about the changes you make on the GCC 3.2 mainline.
It's really unfortunate that there have been, again, over a hundred
*regresssions from GCC 3.0* during GCC 3.1 development.

Please try to invest in infrastructure improvements that make it harder
to break the compiler.  Switching to GC is an example of this: it made
it harder to have memory errors.  Richard's verify_live_at_start stuff
is similar: it made it harder to have buggy optimizations.  The more
robust we can make our infrastructure the easier it will make it to move
forward with the new features and optimizations that everyone finds most
exciting.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC 3.1 Release

[Neil Booth]

Mark Mitchell wrote:-

> I have a proposal before the SC to slip the GCC 3.2 schedule even
> further; so that the first phase of GCC 3.2 development will now end
> one month  beyond the release of GCC 3.1 -- June 1st -- pushing the
> GCC 3.2  release date back to October 1st so as to give people time to
> work on major changes for GCC 3.2 *after* GCC 3.1 is released.

IMO this is still too short; I think there should be two months after
the previous release for the first phase, giving us an 8-month cycle
instead of a 6-month one.

Neil.

Re: GCC 3.1 Release

[Toon Moene]

Neil Booth wrote:

> Mark Mitchell wrote:-

> > I have a proposal before the SC to slip the GCC 3.2 schedule even
> > further; so that the first phase of GCC 3.2 development will now end
> > one month  beyond the release of GCC 3.1 -- June 1st -- pushing the
> > GCC 3.2  release date back to October 1st so as to give people time to
> > work on major changes for GCC 3.2 *after* GCC 3.1 is released.
> 
> IMO this is still too short; I think there should be two months after
> the previous release for the first phase, giving us an 8-month cycle
> instead of a 6-month one.

The problem with Mark's "mental model" of the release process is that
bug fixing doesn't screech to a grinding halt the moment 3.1 is out.

Because then a whole group of "new" testers comes along and finds new
bugs that we (and our "regular" testers) haven't found.  For 3.0 this
effect was so bad that basically only the 3.0.4 release can be described
as "generally useful".

I do not have a good solution to that problem.

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)

Re: GCC 3.1 Release

[Tim Prince]

On Saturday 13 April 2002 05:25, Toon Moene wrote:
> Neil Booth wrote:
> > Mark Mitchell wrote:-
> >
> > > I have a proposal before the SC to slip the GCC 3.2 schedule even
> > > further; so that the first phase of GCC 3.2 development will now end
> > > one month  beyond the release of GCC 3.1 -- June 1st -- pushing the
> > > GCC 3.2  release date back to October 1st so as to give people time to
> > > work on major changes for GCC 3.2 *after* GCC 3.1 is released.
> >
> > IMO this is still too short; I think there should be two months after
> > the previous release for the first phase, giving us an 8-month cycle
> > instead of a 6-month one.
>
> The problem with Mark's "mental model" of the release process is that
> bug fixing doesn't screech to a grinding halt the moment 3.1 is out.
>
> Because then a whole group of "new" testers comes along and finds new
> bugs that we (and our "regular" testers) haven't found.  For 3.0 this
> effect was so bad that basically only the 3.0.4 release can be described
> as "generally useful".
>
Perhaps I misunderstand, but it appears that the primary effort with gcc-3.1 
is to cut down the regressions from earlier versions.  After release, more 
testers will be seeing the bugs in the new features, including those which 
are already reported but not fixed because they are not regressions.

-- 
Tim Prince

Re: GCC 3.1 Release

[Bryce McKinlay]

Toon Moene wrote:

>>>I have a proposal before the SC to slip the GCC 3.2 schedule even
>>>further; so that the first phase of GCC 3.2 development will now end
>>>one month  beyond the release of GCC 3.1 -- June 1st -- pushing the
>>>GCC 3.2  release date back to October 1st so as to give people time to
>>>work on major changes for GCC 3.2 *after* GCC 3.1 is released.
>>>
>>IMO this is still too short; I think there should be two months after
>>the previous release for the first phase, giving us an 8-month cycle
>>instead of a 6-month one.
>>

One could argue that the long cycle between 3.0 and 3.1 is partly 
responsible for the 3.1 release problems, by allowing a longer period 
for bugs to creep in before developer focus shifted to fixing them. I 
think we should try for at least one release on the shorter cycle, with 
an option to re-evaluate its effectiveness as the 3.2 release approaches 
or after it is made.

For GCJ, having more than 6 months between major releases is (IMO) an 
uncomfortably long time, given the rate at which it is moving. We find 
that a lot of bugs only get discovered after releases, but it becomes 
impractical to continue applying fixes to release branches because the 
mainline diverges quickly. Perhaps we should try to keep applying GCJ 
changes to release branches for longer, but to be always committing 
patches to two trees is quite time-consuming.

>Because then a whole group of "new" testers comes along and finds new
>bugs that we (and our "regular" testers) haven't found.  For 3.0 this
>effect was so bad that basically only the 3.0.4 release can be described
>as "generally useful".
>
>I do not have a good solution to that problem.
>

Perhaps we could go by a stable/unstable release cycle, similar to 
Linux. Unstable releases would follow a shorter period of 
stabilization/freezing/testing/branching than is done for a full, stable 
release. This would give users wanting to test and play with new 
features something which is known to be better tested than the average 
snapshot, but without the pain and major disruption to development that 
full releases seem to require.

regards

Bryce.

Re: GCC 3.1 Release

[David Edelsohn]

>>>>> Bryce McKinlay writes:

Bryce> One could argue that the long cycle between 3.0 and 3.1 is partly 
Bryce> responsible for the 3.1 release problems, by allowing a longer period 
Bryce> for bugs to creep in before developer focus shifted to fixing them. I 
Bryce> think we should try for at least one release on the shorter cycle, with 
Bryce> an option to re-evaluate its effectiveness as the 3.2 release approaches
Bryce> or after it is made.

	One can arbitrarily divide the bugs into two categories:
regressions with testcases in the "torture" suite and regressions reported
through Gnats.  For the former, we all need to do better to fix
regressions as they occur.  For the latter, we sometimes do not get
immediate feedback about the failures or the failures are latent bugs not
directly caused by a change.

	Regressions and bugs are a byproduct of invasive changes to the
compiler.  If we are not creating and/or exposing bugs, we probably are
not improving the compiler substantially.

Bryce> Perhaps we could go by a stable/unstable release cycle, similar to 
Bryce> Linux. Unstable releases would follow a shorter period of 
Bryce> stabilization/freezing/testing/branching than is done for a full, stable
Bryce> release. This would give users wanting to test and play with new 
Bryce> features something which is known to be better tested than the average 
Bryce> snapshot, but without the pain and major disruption to development that 
Bryce> full releases seem to require.

	We are working on many different areas of the compiler
simultaneously.  Clearly new languages (such as Java and GCJ) would like
to have the rest of the compiler remain stable while it rapidly pushes
forward with more complete language support and ports to more platforms.
Other users want to see optimization improvements for existing languages.
Another community wants greater standards conformance for existing
languages.  It is hard to strike the right balance.  We need an open,
inclusive, constructive discussion to navigate a reasonable course.

	I conducted a survey about the GCC release schedule.  *NONE* of
the companies (Linux distributors, free software and open source projects,
embedded systems companies) wanted a release on a six month cycle.  No one
wants to have to transition and re-validate their software and repackage a
new distribution with great frequency.  Nine to twelve months is the
soonest that bulk end-users who create the dependence on GCC versions want
to be burdened with updating.

	If we want to remain on a six month cycle, alternating between
"technology preview" releases and "production" releases (e.g., GCC 3.0 and
GCC 3.1) would be a good plan, IMHO.  For that type of approach to work, I
think that we need to make every effort to ensure that radical, invasive
changes are merged into the mainline for even numbered releases so that
odd numbered releases are not substantially destabilized and developers do
not need to wait 18 months for their contributions to be accepted.  We
have a lot of good technology ready on branches and being offered by
developers that we need to figure out how to merge into the trunk for GCC
3.2.

Thanks, David

Re: GCC 3.1 Release

[David O'Brien]

On Sun, Apr 14, 2002 at 06:26:30PM -0400, David Edelsohn wrote:
> 	I conducted a survey about the GCC release schedule.  *NONE* of
> the companies (Linux distributors, free software and open source projects,
> embedded systems companies) wanted a release on a six month cycle.  No one
> wants to have to transition and re-validate their software and repackage a
> new distribution with great frequency.  Nine to twelve months is the
> soonest that bulk end-users who create the dependence on GCC versions want
> to be burdened with updating.
> 
> 	If we want to remain on a six month cycle, alternating between
> "technology preview" releases and "production" releases (e.g., GCC 3.0 and
> GCC 3.1) would be a good plan, IMHO.  For that type of approach to work, I
> think that we need to make every effort to ensure that radical, invasive
> changes are merged into the mainline for even numbered releases so that
> odd numbered releases are not substantially destabilized and developers do
> not need to wait 18 months for their contributions to be accepted.  We

Waiting 18 months for the next major stable usable compiler release would
be hard for FreeBSD.  As I mentioned, nine months is perfect for us.

I strongly feel the GCC SC needs to take a stronger look at following the
FreeBSD (and now OpenBSD) model of treating the release branch as not
cast in stone.  A lot more things could be merged from 3.2 to 3.1 than I
know will be.  It just takes creating the culture where committers are
socially pressured to "merge from maintain" their changes where safe.
IMHO too many changes are labeled "unsafe to merge" just so no one has to
think about or deal with the merge.

Re: GCC 3.1 Release

[David Edelsohn]

>>>>> David O'Brien writes:

David> Waiting 18 months for the next major stable usable compiler release would
David> be hard for FreeBSD.  As I mentioned, nine months is perfect for us.

	I think that you misunderstood my previous message.  I was not
suggesting an 18 month cycle for major stable releases.  I was suggesting
that a six month cycle of releases alternating between "technology
preview" and "production" releases would require 18 months for a new,
major feature to appear in a GCC release if a proposal missed the
"technology preview" cutoff date.

David

Re: GCC 3.1 Release

[Marc Espie]

In article <20020415171448.C1064@dragon.nuxi.com> you write:
>I strongly feel the GCC SC needs to take a stronger look at following the
>FreeBSD (and now OpenBSD) model of treating the release branch as not
>cast in stone.  A lot more things could be merged from 3.2 to 3.1 than I
>know will be.  It just takes creating the culture where committers are
>socially pressured to "merge from maintain" their changes where safe.
>IMHO too many changes are labeled "unsafe to merge" just so no one has to
>think about or deal with the merge.

Huh? What you describe is not OpenBSD's model at all.

We don't have branches. We have current, and every six months, we 
slow down, we stop development, we stabilize things, and we get out
a new release. In fact, it's probably 5 months devel/1 month bug-fix,
on average.

This works because of a few things:
- attention to detail,
- no excessive paperwork and rules (you had better not make a change
in an area that you don't own),
- a chief who can arbitrate conflicts,
- not too many bugs in the first place.

All these points are important. There is also a perceived quality
of the result that `tweaks' the development process: more time is
spent in fixing bugs if the release strays from our quality standards.

As far as the stable branch goes, we only commit very, very few
careful patches to it, and we NEVER add functionality to an old release.

Re: GCC 3.1 Release

[David O'Brien]

On Sun, Apr 14, 2002 at 05:33:49PM +1200, Bryce McKinlay wrote:
> One could argue that the long cycle between 3.0 and 3.1 is partly 
> responsible for the 3.1 release problems, by allowing a longer period 

The time between 3.0 and 3.1 is very quick.  2.95 -> 3.0 was where the
long cycle was.
At this point 3.1 looks to be the best GCC compiler post EGCS-1.1.2.


> mainline diverges quickly. Perhaps we should try to keep applying GCJ 
> changes to release branches for longer, but to be always committing 
> patches to two trees is quite time-consuming.

IMHO more things should be committed to the release branch.
Everything is "time-consuming", there isn't much one can do about it when
making releases of software.  Only toy, personal hacks are
"time-consuming" and require effort.


> Perhaps we could go by a stable/unstable release cycle, similar to 
> Linux.

Please no.  I really feel this will make it harder for those producing
products that need to include a compiler.

Re: GCC 3.1 Release

[Bryce McKinlay]

David O'Brien wrote:

>>mainline diverges quickly. Perhaps we should try to keep applying GCJ 
>>changes to release branches for longer, but to be always committing 
>>patches to two trees is quite time-consuming.
>>
>
>IMHO more things should be committed to the release branch.
>Everything is "time-consuming", there isn't much one can do about it when
>making releases of software.  Only toy, personal hacks are
>"time-consuming" and require effort.
>

I am speaking from a maintainer perspective. As long as we are 
maintaining a branch I have to maintain a separate branch tree and 
apply, build, test, and commit each patch independently. This is partly 
CVS's fault for not making it easier to merge changesets between branch 
sets. It also doesn't help that CVS runs so slow when working with the 
branch (btw why does it take < 30 sec to do a full "cvs update" on the 
mainline, but sometimes up to half an hour on the branch?)

But, I totally agree with you that more stuff should go on the branch 
and this is something I think us GCJ developers are going to try and do 
this time around, despite the hassle involved.

>>Perhaps we could go by a stable/unstable release cycle, similar to 
>>Linux.
>>
>
>Please no.  I really feel this will make it harder for those producing
>products that need to include a compiler.
>

Why? Presumably, BSD and Linux distributions would stick with the stable 
releases for their default compilers. The unstable releases would be for 
people who want to try out new features and optimizations without having 
to deal with CVS trees and snapshots which may not work at any given 
moment. It would be very nice to point people who are looking for new 
Java features (for example) at something that is known to at least 
somewhat work.

regards

Bryce.

Re: GCC 3.1 Release

[David O'Brien]

On Tue, Apr 23, 2002 at 02:43:23PM +1200, Bryce McKinlay wrote:
> >>Perhaps we could go by a stable/unstable release cycle, similar to 
> >>Linux.
> >
> >Please no.  I really feel this will make it harder for those producing
> >products that need to include a compiler.
> 
> Why? Presumably, BSD and Linux distributions would stick with the stable 
> releases for their default compilers. The unstable releases would be for 
> people who want to try out new features and optimizations without having 

We already saw with Red Hat and the H.J.Lu Binutils releases that people
are not willing to wait for things to hit the "stable" releases.

I feer that with the divergent stable/unstable release cycle less GCC
developers will spend time on the stable releases -- instead wanting to
do fresh development/changes/enhancements to the unstable release.  And
also that doing a stable/unstable release cycle will create longer times
between when large changes can happen, thus pusuring the RE more to give
less attention to the stable release cycle as it is "holding back
development".

Re: GCC 3.1 Release

[Bryce McKinlay]

David O'Brien wrote:

>I feer that with the divergent stable/unstable release cycle less GCC
>developers will spend time on the stable releases -- instead wanting to
>do fresh development/changes/enhancements to the unstable release.  And
>also that doing a stable/unstable release cycle will create longer times
>between when large changes can happen
>

I don't think that has to be the case. Full, stable releases could be 
handled largely the same as they are now. The only difference is that 
there would be one or more shorter (perhaps 1-2 weeks) stabilization 
periods between each major release, during which the tree would be 
closed to major changes. If anything there would be _more_ time for 
major changes to land, since I think it would be more reasonable to 
extend the stable release cycle out to say 8 or 10 months if there were 
unstable releases as well.

regards

Bryce.

Re: GCC 3.1 Release

[Kaveh R. Ghazi]

 > From: Bryce McKinlay <bryce@waitaki.otago.ac.nz> 
 > 
 > (btw why does it take < 30 sec to do a full "cvs update" on the
 > mainline, but sometimes up to half an hour on the branch?)

See: http://gcc.gnu.org/ml/gcc/2002-03/msg01741.html

--
Kaveh R. Ghazi			Director of Systems Architecture
ghazi@caip.rutgers.edu		Qwest Global Services

Re: GCC 3.1 Release

[H . J . Lu]

On Sat, Apr 13, 2002 at 02:25:04PM +0200, Toon Moene wrote:
> Neil Booth wrote:
> 
> > Mark Mitchell wrote:-
> 
> > > I have a proposal before the SC to slip the GCC 3.2 schedule even
> > > further; so that the first phase of GCC 3.2 development will now end
> > > one month  beyond the release of GCC 3.1 -- June 1st -- pushing the
> > > GCC 3.2  release date back to October 1st so as to give people time to
> > > work on major changes for GCC 3.2 *after* GCC 3.1 is released.
> > 
> > IMO this is still too short; I think there should be two months after
> > the previous release for the first phase, giving us an 8-month cycle
> > instead of a 6-month one.
> 
> The problem with Mark's "mental model" of the release process is that
> bug fixing doesn't screech to a grinding halt the moment 3.1 is out.
> 
> Because then a whole group of "new" testers comes along and finds new
> bugs that we (and our "regular" testers) haven't found.  For 3.0 this
> effect was so bad that basically only the 3.0.4 release can be described
> as "generally useful".
> 
> I do not have a good solution to that problem.

Let's face it. It is next to impossible to make a major gcc release
without regressions or other serious bugs. The question is how the
gcc developers deal with it. I think a quick bug fix minor release
should be put out every week or two after a major release. That may
mean the gcc developers may not be able to run regression tests
themselves on all platforms. But it won't be a big problem as long as
some regressions known after the major release are fixed in each minor
release. The reason I like frequent releases is it is easier to track
down and fix regressions. You always get a better gcc in each minor
release.


H.J.

Re: GCC 3.1 Release

[Marc Espie]

In article <3CB823A0.136EF4E3@moene.indiv.nluug.nl> you write:
>Neil Booth wrote:

>> Mark Mitchell wrote:-

>> > I have a proposal before the SC to slip the GCC 3.2 schedule even
>> > further; so that the first phase of GCC 3.2 development will now end
>> > one month  beyond the release of GCC 3.1 -- June 1st -- pushing the
>> > GCC 3.2  release date back to October 1st so as to give people time to
>> > work on major changes for GCC 3.2 *after* GCC 3.1 is released.

>> IMO this is still too short; I think there should be two months after
>> the previous release for the first phase, giving us an 8-month cycle
>> instead of a 6-month one.

>The problem with Mark's "mental model" of the release process is that
>bug fixing doesn't screech to a grinding halt the moment 3.1 is out.

>Because then a whole group of "new" testers comes along and finds new
>bugs that we (and our "regular" testers) haven't found.  For 3.0 this
>effect was so bad that basically only the 3.0.4 release can be described
>as "generally useful".

>I do not have a good solution to that problem.

A large of the problem is the perceived quality of gcc releases.

If you can manage to deliver a rock-stable compiler or two, that works
on a reasonable set of architectures, you will suddenly see lots more
tests coming in.

Let's look at gcc 3.0. Who actually uses it ? None of the BSD has imported
it (judging from personal experience, I have seen enough `small issues' in
it that don't make it worth it from 2.95: doesn't fix code too much, doesn't
work way better on the architectures OpenBSD supports, and is slower).

Yes, it has better C++ support. But, between the KDE project who still
recommend gcc 2.95 on their web page, and our developers who in a large
majority don't care for C++, what do you think is going to happen.

I wish I had more time to spend to work on gcc, and to fix bugs.
But I am facing the same problem you are: I can't import the compiler
into OpenBSD until it's stable enough, and I can't get enough help to
get it stable because it's not in OpenBSD yet.

I like the move to shorter releases schedules, it means less time to
go off-track.

It's to be expected that the release slips at first. The only way
to correct that is probably to do less sexy work, and more working
compiler.

I don't want to sound too pessimistic, but if things don't improve,
a large subset of people are not going to want to update beyond gcc 2.95,
especially the guys who are not running on i386/linux.

Re: GCC 3.1 Release

[Gerald Pfeifer]

On Wed, 17 Apr 2002, Marc Espie wrote:
> I don't want to sound too pessimistic, but if things don't improve,
> a large subset of people are not going to want to update beyond gcc 2.95,
> especially the guys who are not running on i386/linux.

FWIW, FreeBSD is adopting GCC 3.1 as system compiler for -CURRENT which
will become FreeBSD 5.0 later this year.

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: GCC 3.1 Release

[Marc Espie]

On Wed, Apr 17, 2002 at 10:58:51AM +0200, Gerald Pfeifer wrote:
> On Wed, 17 Apr 2002, Marc Espie wrote:
> > I don't want to sound too pessimistic, but if things don't improve,
> > a large subset of people are not going to want to update beyond gcc 2.95,
> > especially the guys who are not running on i386/linux.
> 
> FWIW, FreeBSD is adopting GCC 3.1 as system compiler for -CURRENT which
> will become FreeBSD 5.0 later this year.
> 

Does look like a bad idea...

A quick test with the new gcc 3.1 shows that the compiler itself is about 
twice as slow as gcc 2.95.3... ouch.

make  3.72s user 0.53s system 94% cpu 4.495 total
CC=egcc make  6.75s user 0.71s system 93% cpu 7.986 total

Totally unacceptable on slow machines.

Re: GCC 3.1 Release

[Loren James Rittle]

In article <20020517140210.A16176@tetto.liafa.jussieu.fr> you write:
>>> I don't want to sound too pessimistic, but if things don't improve,

>> FWIW, FreeBSD is adopting GCC 3.1 as system compiler for -CURRENT which
>> will become FreeBSD 5.0 later this year.

> Does look like a bad idea...

It is a great idea.  Please stop being a pessimistic obstructionist (esp.
regarding a system you don't even use ;-).

For some very short contrived tests, the C compiler may look much slower.
Have you actually compared the bootstrap time for FreeBSD 5.X just before
the change in compiler to just after?  I have not personally tested it
but perhaps David could post the exact time difference he saw when he
made this change.

Regards,
Loren

Re: GCC 3.1 Release

[David O'Brien]

On Fri, May 17, 2002 at 05:04:18PM -0500, Loren James Rittle wrote:
> >> FWIW, FreeBSD is adopting GCC 3.1 as system compiler for -CURRENT which
> >> will become FreeBSD 5.0 later this year.
...
> I have not personally tested it
> but perhaps David could post the exact time difference he saw when he
> made this change.

I really don't have any machines to compare with.  My own went from 2.95
to 3.1 in a peice meal fashion as I tested various things.  Sorry.

Re: GCC 3.1 Release

[Marc Espie]

On Fri, May 17, 2002 at 04:35:00PM -0700, David O'Brien wrote:
> On Fri, May 17, 2002 at 05:04:18PM -0500, Loren James Rittle wrote:
> > >> FWIW, FreeBSD is adopting GCC 3.1 as system compiler for -CURRENT which
> > >> will become FreeBSD 5.0 later this year.
> ...
> > I have not personally tested it
> > but perhaps David could post the exact time difference he saw when he
> > made this change.
> 
> I really don't have any machines to compare with.  My own went from 2.95
> to 3.1 in a peice meal fashion as I tested various things.  Sorry.

Well, unless you run tests, I will tend to assume you have the same
catastrophic behavior that I see.

Of course, since FreeBSD only targets fast architectures, this is less of
a problem...

For that matter, this is a mistake we've made once, between gcc 2.8 and
gcc 2.95 (which was already a slowdown), which is the reason why we are
much more careful when doing compiler upgrades now.

Re: GCC 3.1 Release

[Tom Tromey]

>>>>> "Mark" == Mark Mitchell <mark@codesourcery.com> writes:

Mark> The amount of breakage since GCC 3.0 continues to amaze me.

Me too.

Mark> It's really unfortunate that there have been, again, over a
Mark> hundred *regresssions from GCC 3.0* during GCC 3.1 development.

For gcj the main developers seem to all use Linux; x86 and PPC seem to
be the most popular.  During the 3.1 process we've gotten a lot of bug
reports about platforms that aren't ordinarily tested.  In none of
these cases did we consciously break gcj on a given platform.

What I'd like to see in the future is for people to set up automated
regression testers, say like Geoff's, that test these platforms.  Then
we simply won't introduce problems in the first place.

In fact what I'd really like to see is a requirement for such a
regression tester for every platform that is considered release
critical.  (I'm sure the logistics of this are difficult.)

For gcj at least it would also help if we greatly expanded the test
suite.  Even simply requiring a Mauve run before a commit (or after,
in the regression tester) would have helped us a great deal.  Now,
Mauve is automated in our test suite, but other useful things like
Classpath, rhug, kawa, etc, are not.  So this is something we can do
pretty easily that will help reliability.  Still, the big thing is
getting this automated so that regressions are short-lived.

Another thing that has happened is that the impending release brought
all kinds of new gcj ports out of the woodwork.  It would be nice if
these weren't all batched at one point in the process.  I'm not sure
what, if anything, we can do about this.  Perhaps this phenomenon is
unique to this release.

I'd say most of the time I've spent on 3.1 (and it is a fair amount of
time, at least 2 full weeks) has been spent handling ports which
worked in 3.0 and stopped working somewhere along the line.  It isn't
exactly fun work, and it has even perhaps blocked me from fixing a
non-port-related gcj bug.  This sort of thing is preventable, so let's
prevent it.

Tom

Re: GCC 3.1 Release

[Jason Merrill]

>>>>> "Tom" == Tom Tromey <tromey@redhat.com> writes:

> What I'd like to see in the future is for people to set up automated
> regression testers, say like Geoff's, that test these platforms.  Then
> we simply won't introduce problems in the first place.

> In fact what I'd really like to see is a requirement for such a
> regression tester for every platform that is considered release
> critical.  (I'm sure the logistics of this are difficult.)

Absolutely.  Geoff, how hard would it be for someone on the net to set up a
slave tester to improve coverage?  I'd like to keep the bookkeeping
centralized, but the actual testing work can and should be distributed.

Jason

Re: GCC 3.1 Release

[Andreas Jaeger]

Jason Merrill <jason@redhat.com> writes:

>>>>>> "Tom" == Tom Tromey <tromey@redhat.com> writes:
>
>> What I'd like to see in the future is for people to set up automated
>> regression testers, say like Geoff's, that test these platforms.  Then
>> we simply won't introduce problems in the first place.
>
>> In fact what I'd really like to see is a requirement for such a
>> regression tester for every platform that is considered release
>> critical.  (I'm sure the logistics of this are difficult.)
>
> Absolutely.  Geoff, how hard would it be for someone on the net to set up a
> slave tester to improve coverage?  I'd like to keep the bookkeeping
> centralized, but the actual testing work can and should be distributed.

What do you mean with slave tester?

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: GCC 3.1 Release

[Jason Merrill]

>>>>> "Andreas" == Andreas Jaeger <aj@suse.de> writes:

> Jason Merrill <jason@redhat.com> writes:
>>>>>>> "Tom" == Tom Tromey <tromey@redhat.com> writes:
>> 
>>> What I'd like to see in the future is for people to set up automated
>>> regression testers, say like Geoff's, that test these platforms.  Then
>>> we simply won't introduce problems in the first place.
>> 
>>> In fact what I'd really like to see is a requirement for such a
>>> regression tester for every platform that is considered release
>>> critical.  (I'm sure the logistics of this are difficult.)
>> 
>> Absolutely.  Geoff, how hard would it be for someone on the net to set up a
>> slave tester to improve coverage?  I'd like to keep the bookkeeping
>> centralized, but the actual testing work can and should be distributed.

> What do you mean with slave tester?

Another computer somewhere on the net, running tests as controlled by the
current system.

Jason

Re: GCC 3.1 Release

[Geoff Keating]

> Cc: Mark Mitchell <mark@codesourcery.com>, gcc@gcc.gnu.org
> From: Jason Merrill <jason@redhat.com>
> Date: Sun, 14 Apr 2002 14:05:55 +0100
> User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.1 (i686-pc-linux-gnu)
> 
> >>>>> "Tom" == Tom Tromey <tromey@redhat.com> writes:
> 
> > What I'd like to see in the future is for people to set up automated
> > regression testers, say like Geoff's, that test these platforms.  Then
> > we simply won't introduce problems in the first place.
> 
> > In fact what I'd really like to see is a requirement for such a
> > regression tester for every platform that is considered release
> > critical.  (I'm sure the logistics of this are difficult.)
> 
> Absolutely.  Geoff, how hard would it be for someone on the net to set up a
> slave tester to improve coverage?  I'd like to keep the bookkeeping
> centralized, but the actual testing work can and should be distributed.

Once sufficiently fast hardware is available, setting up a slave
tester should be very easy.  I think it should go like this:

1. Set up a tester with some reasonably reproducible software
   configuration (so that others can reproduce bugs).  For example,
   the current tester is configured as "Red Hat Linux 7 from CD plus
   all updates so far".

2. Make GCC mainline bootstrap on this machine, preferably using the
   scripts in gcc/contrib/regression.  Check that the bootstrap & test
   takes less than about 3 hours.  [For reference, a single 800Mhz
   Pentium III can do this.  A two-processor 450Mhz machine should
   also be able to do it.  Old obsolete hardware from the early 90s
   certainly can't do it; if it turns out that all we can get is old
   obsolete hardware, I'll have to change the tester so that it
   doesn't have to wait for all the builds to finish, but this will
   take some time.]

3. Set up an account so that the regression tester can log in,
   preferably using SSH.

4. Then I'll check that everything works and add the new target to the
   tester.

Typically, I find step 2 to be the tricky bit for new targets---often,
the new target doesn't build.

-- 
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>

Re: GCC 3.1 Release

[H . J . Lu]

On Mon, Apr 15, 2002 at 10:50:52AM -0700, Geoff Keating wrote:
> > Cc: Mark Mitchell <mark@codesourcery.com>, gcc@gcc.gnu.org
> > From: Jason Merrill <jason@redhat.com>
> > Date: Sun, 14 Apr 2002 14:05:55 +0100
> > User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.1 (i686-pc-linux-gnu)
> > 
> > >>>>> "Tom" == Tom Tromey <tromey@redhat.com> writes:
> > 
> > > What I'd like to see in the future is for people to set up automated
> > > regression testers, say like Geoff's, that test these platforms.  Then
> > > we simply won't introduce problems in the first place.
> > 
> > > In fact what I'd really like to see is a requirement for such a
> > > regression tester for every platform that is considered release
> > > critical.  (I'm sure the logistics of this are difficult.)
> > 
> > Absolutely.  Geoff, how hard would it be for someone on the net to set up a
> > slave tester to improve coverage?  I'd like to keep the bookkeeping
> > centralized, but the actual testing work can and should be distributed.
> 
> Once sufficiently fast hardware is available, setting up a slave
> tester should be very easy.  I think it should go like this:
> 
> 1. Set up a tester with some reasonably reproducible software
>    configuration (so that others can reproduce bugs).  For example,
>    the current tester is configured as "Red Hat Linux 7 from CD plus
>    all updates so far".
> 
> 2. Make GCC mainline bootstrap on this machine, preferably using the
>    scripts in gcc/contrib/regression.  Check that the bootstrap & test
>    takes less than about 3 hours.  [For reference, a single 800Mhz
>    Pentium III can do this.  A two-processor 450Mhz machine should
>    also be able to do it.  Old obsolete hardware from the early 90s
>    certainly can't do it; if it turns out that all we can get is old
>    obsolete hardware, I'll have to change the tester so that it
>    doesn't have to wait for all the builds to finish, but this will
>    take some time.]
> 

I have found the current gcc regression test far from ideal. The main
problem for me is shared library and thread aren't enabled by default
on platforms where shared library and thread are used. As the result,
PIC and thread aren't tested in many reports, like

http://gcc.gnu.org/ml/gcc-testresults/2002-04/msg00466.html
http://gcc.gnu.org/ml/gcc-testresults/2002-04/msg00520.html

which may lead to under reported PIC and/or thread bugs.



H.J.

Re: GCC 3.1 Release

[mark]

Hi,

On Mon, Apr 15, 2002 at 11:04:22AM -0700, H . J . Lu wrote:
> 
> I have found the current gcc regression test far from ideal. The main
> problem for me is shared library and thread aren't enabled by default
> on platforms where shared library and thread are used. As the result,
> PIC and thread aren't tested in many reports, like
> 
> http://gcc.gnu.org/ml/gcc-testresults/2002-04/msg00466.html
> http://gcc.gnu.org/ml/gcc-testresults/2002-04/msg00520.html
> 
> which may lead to under reported PIC and/or thread bugs.

One of the test results referenced was posted by me.
I am posting test results for i686-pc-linux-gnu by hand after testing new
patches that are about to be committed or that have just been committed.
And I have setup an automatic test machine on powerpc-unknown-linux-gnu to
track progress of the mauve testsuite results for gcj.
(See http://sources.redhat.com/mauve/)
Results for x86 already look very decent but powerpc still has many failures.

Please let me know what configuration flags would give better test coverage
so that I can try to change my defaults. (The powerpc machine is a bit slow
and doesn't have that much disk space which is why --disable-multilib is
used at the moment.)

Cheers,

Mark

Re: GCC 3.1 Release

[H . J . Lu]

On Wed, Apr 17, 2002 at 12:09:15AM +0200, mark@klomp.org wrote:
> Hi,
> 
> Please let me know what configuration flags would give better test coverage
> so that I can try to change my defaults. (The powerpc machine is a bit slow
> and doesn't have that much disk space which is why --disable-multilib is
> used at the moment.)

On Linux, --enable-clocale=gnu --enable-shared --enable-threads=posix
should be used if they aren't the default.



H.J.

Re: GCC 3.1 Release

[Andreas Schwab]

"H . J . Lu" <hjl@lucon.org> writes:

|> On Wed, Apr 17, 2002 at 12:09:15AM +0200, mark@klomp.org wrote:
|> > Hi,
|> > 
|> > Please let me know what configuration flags would give better test coverage
|> > so that I can try to change my defaults. (The powerpc machine is a bit slow
|> > and doesn't have that much disk space which is why --disable-multilib is
|> > used at the moment.)
|> 
|> On Linux, --enable-clocale=gnu --enable-shared --enable-threads=posix
|> should be used if they aren't the default.

For glibc >= 2.2 on linux/gnu the first is the default already.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE GmbH, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: GCC 3.1 Release

[Andreas Jaeger]

Geoff Keating <geoffk@geoffk.org> writes:

>> Cc: Mark Mitchell <mark@codesourcery.com>, gcc@gcc.gnu.org
>> From: Jason Merrill <jason@redhat.com>
>> Date: Sun, 14 Apr 2002 14:05:55 +0100
>> User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.1 (i686-pc-linux-gnu)
>> 
>> >>>>> "Tom" == Tom Tromey <tromey@redhat.com> writes:
>> 
>> > What I'd like to see in the future is for people to set up automated
>> > regression testers, say like Geoff's, that test these platforms.  Then
>> > we simply won't introduce problems in the first place.
>> 
>> > In fact what I'd really like to see is a requirement for such a
>> > regression tester for every platform that is considered release
>> > critical.  (I'm sure the logistics of this are difficult.)
>> 
>> Absolutely.  Geoff, how hard would it be for someone on the net to set up a
>> slave tester to improve coverage?  I'd like to keep the bookkeeping
>> centralized, but the actual testing work can and should be distributed.
>
> Once sufficiently fast hardware is available, setting up a slave
> tester should be very easy.  I think it should go like this:
>
> 1. Set up a tester with some reasonably reproducible software
>    configuration (so that others can reproduce bugs).  For example,
>    the current tester is configured as "Red Hat Linux 7 from CD plus
>    all updates so far".
>
> 2. Make GCC mainline bootstrap on this machine, preferably using the
>    scripts in gcc/contrib/regression.  Check that the bootstrap & test
>    takes less than about 3 hours.  [For reference, a single 800Mhz
>    Pentium III can do this.  A two-processor 450Mhz machine should
>    also be able to do it.  Old obsolete hardware from the early 90s
>    certainly can't do it; if it turns out that all we can get is old
>    obsolete hardware, I'll have to change the tester so that it
>    doesn't have to wait for all the builds to finish, but this will
>    take some time.]
>
> 3. Set up an account so that the regression tester can log in,
>    preferably using SSH.

This is not possible for people that are behind a firewall...

Would the main tester run a script on the slave and connect to it via
ssh?  Or would it be possible to work the other way round: The slave
asking the master whether there's work to do?

> 4. Then I'll check that everything works and add the new target to the
>    tester.
>
> Typically, I find step 2 to be the tricky bit for new targets---often,
> the new target doesn't build.

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: GCC 3.1 Release

[Joe Buck]

...
> > 3. Set up an account so that the regression tester can log in,
> >    preferably using SSH.

Andreas writes:

> This is not possible for people that are behind a firewall...

Even for folks without a firewall, it's a security risk that many people
won't want to take (granting the regression tester the ability to log in).

> Would the main tester run a script on the slave and connect to it via
> ssh?  Or would it be possible to work the other way round: The slave
> asking the master whether there's work to do?

It would be best for the "slave" (rather, the contributor's machines) to
poll the "master".

Re: GCC 3.1 Release

[Geoff Keating]

> From: Andreas Jaeger <aj@suse.de>
> Date: Mon, 15 Apr 2002 20:15:05 +0200
> User-Agent: Gnus/5.090006 (Oort Gnus v0.06) XEmacs/21.4 (Artificial
>  Intelligence, i386-suse-linux)
> 
> Geoff Keating <geoffk@geoffk.org> writes:

> > 3. Set up an account so that the regression tester can log in,
> >    preferably using SSH.
> 
> This is not possible for people that are behind a firewall...
> 
> Would the main tester run a script on the slave and connect to it via
> ssh?  Or would it be possible to work the other way round: The slave
> asking the master whether there's work to do?

Unfortunately, the regression tester here just got renumbered into
private address space :-(.  I could possibly get it moved out again,
or a tunnel created for it.  If anyone actually has this situation,
I'll talk about our networking people about the best way to handle it;
I expect it would depend on precisely what kind of machine is on the
other end.

> From: Joe Buck <Joe.Buck@synopsys.com>

> Even for folks without a firewall, it's a security risk that many people
> won't want to take (granting the regression tester the ability to log in).

This can be dealt with, for instance by giving the tester permission
to only run a few commands; of course, it's more work for the person
setting up the slave machine.

-- 
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>

Re: GCC 3.1 Release

[Andreas Jaeger]

Mark Mitchell <mark@codesourcery.com> writes:

[...]

> I have a proposal before the SC to slip the GCC 3.2 schedule even
> further; so that the first phase of GCC 3.2 development will now end
> one month  beyond the release of GCC 3.1 -- June 1st -- pushing the
> GCC 3.2  release date back to October 1st so as to give people time to
> work on major changes for GCC 3.2 *after* GCC 3.1 is released.

This means 5 month for GCC 3.2 after GCC 3.1 is released?  I though we
had a 6 month cycle - and the point was to *extend* the period not to
shorten it,

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: GCC 3.1 Release

[Mark Mitchell]

--On Monday, April 15, 2002 08:56:20 PM +0200 Andreas Jaeger <aj@suse.de> 
wrote:

> Mark Mitchell <mark@codesourcery.com> writes:
>
> [...]
>
>> I have a proposal before the SC to slip the GCC 3.2 schedule even
>> further; so that the first phase of GCC 3.2 development will now end
>> one month  beyond the release of GCC 3.1 -- June 1st -- pushing the
>> GCC 3.2  release date back to October 1st so as to give people time to
>> work on major changes for GCC 3.2 *after* GCC 3.1 is released.
>
> This means 5 month for GCC 3.2 after GCC 3.1 is released?  I though we
> had a 6 month cycle - and the point was to *extend* the period not to
> shorten it,

I was unclear.  The proposal the SC is voting on is to create a 7-month
cycle, as opposed to our current 6-month cycle.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC 3.1 Release

[Michael Matz]

Hi,

On Mon, 15 Apr 2002, Mark Mitchell wrote:

> > This means 5 month for GCC 3.2 after GCC 3.1 is released?  I though we
> > had a 6 month cycle - and the point was to *extend* the period not to
> > shorten it,
>
> I was unclear.  The proposal the SC is voting on is to create a 7-month
> cycle, as opposed to our current 6-month cycle.

So, you meant actually to push back the _release_ of 3.2 to january 1st,
right? (June + 7 == 13)  Or you already included the month from May to
June into those 7 months?  Then you meant december 1st?  But certainly not
october, right?


Ciao,
Michael.

Re: GCC 3.1 Release

[Mark Mitchell]

--On Monday, April 15, 2002 09:11:02 PM +0200 Michael Matz 
<matzmich@cs.tu-berlin.de> wrote:

> Hi,
>
> On Mon, 15 Apr 2002, Mark Mitchell wrote:
>
>> > This means 5 month for GCC 3.2 after GCC 3.1 is released?  I though we
>> > had a 6 month cycle - and the point was to *extend* the period not to
>> > shorten it,
>>
>> I was unclear.  The proposal the SC is voting on is to create a 7-month
>> cycle, as opposed to our current 6-month cycle.
>
> So, you meant actually to push back the _release_ of 3.2 to january 1st,
> right? (June + 7 == 13)  Or you already included the month from May to
> June into those 7 months?  Then you meant december 1st?  But certainly not
> october, right?

By the time we hit June 1, we will already be three months into the 3.2
release cycle.

Under my proposal to the SC, June 1 will be the end of Stage 1, August
1 will be the end of Stage 2, October 1 will be end of Stage 3, and the
3.2 release will appear December 1.

So, you're right -- I cannot count.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC 3.1 Release

[Geoff Keating]

Mark Mitchell <mark@codesourcery.com> writes:

> As should be clear at this point, there is no way that we are going
> to be shipping GCC 3.1 on Monday.
> 
> The amount of breakage since GCC 3.0 continues to amaze me.
> 
> We still have about 30 open bugs that we need to try to resolve
> for this release.
> 
> To that end, I'm as of now slipping the GCC 3.1 release date by two
> weeks, until May 1st.

Hi Mark,

Can you say roughly what proportion of the problems (in your
subjective judgement, 'percentage of reason why I delayed the
release') were:

1 Problems visible on x86-linux but not visible to the regression testsuite?
2 Problems visible only on non-free platforms (eg. solaris, AIX, cygwin)?
3 Problems visible on non-x86 free platforms (eg. alpha)?
4 Problems introduced by previous fixes made to the branch? 

[At the time the branch was cut, the testsuite was pretty much 0
failures on x86-linux, so 'failures on x86-linux visible to the
regression testsuite' is not a category.]

The solutions that would work for these are different.  (1) means we
need a better regression testsuite.  (2) and (3) mean we need
more/better testing, perhaps an expanded regression tester, or to drop
some platforms---it may be that, say, Irix is just too hard to do
unless more volunteers can be found who are willing to maintain it.
(4) means we need better moderation and regression testing of the
branch, perhaps requiring that a patch be tested for regressions on
all the important platforms before it is committed; we do something
like that at Red Hat for our general-use native releases.

-- 
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>
[Who is happy that he has two more weeks to try to get at least some
of the PCH branch stuff into the mainline.]

Re: GCC 3.1 Release

[Mark Mitchell]

> Can you say roughly what proportion of the problems (in your
> subjective judgement, 'percentage of reason why I delayed the
> release') were:

Sure -- but do note that this really is subjective.  I have no numbers.

> 1 Problems visible on x86-linux but not visible to the regression
> testsuite?

25%.  Most front end bugs are in this category.

> 2 Problems visible only on non-free platforms (eg. solaris,
> AIX, cygwin)?

25%.  These aren't really too common; there are now free OS's for
most chips and I'm seeing more chip bugs than OS bugs.

> 3 Problems visible on non-x86 free platforms (eg. alpha)?

40%.

>4 Problems introduced by previous fixes made to the branch?

Small, less than 10%.

> The solutions that would work for these are different.  (1) means we
> need a better regression testsuite.  (2) and (3) mean we need
> more/better testing, perhaps an expanded regression tester, or to drop
> some platforms---it may be that, say, Irix is just too hard to do
> unless more volunteers can be found who are willing to maintain it.
> (4) means we need better moderation and regression testing of the
> branch, perhaps requiring that a patch be tested for regressions on
> all the important platforms before it is committed; we do something
> like that at Red Hat for our general-use native releases.

Thanks for thinking about this and trying so hard to improve the
testing system.

I'd say the majority of the problems were not things covered by any
regression test; they were bugs filed in GNATS.  Obviously, we keep
improving the regression testsuite over time, but unfortunately users
are infinitely clever and keep trying to compile new programs.  (It
would be much easier if they would politely only compile a small
finite set of programs...)

I see two major ways to make progress: more testing (which you are
thankfully working particularly hard on) and better internal
infrastructure -- clearer interfaces, better documentation,
higher-level abstractions -- which we are all working on.  A lot of
what's going on is that a change that looks just fine for C++ on x86
turns out to break Fortran on alpha -- and that almost shouldn't
be possible if we were to do our job right.

I do think that regression testers like your across a wide variety
of platforms might eliminate as many as half of all bugs.  There's
also the problem that some people don't seem to want to invest very
much effort to fix problems on platforms they don't use, even when
it's clear they created the problem.  That's a social issue.

Thanks,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC 3.1 Release

[John David Anglin]

> On Wed, Apr 03, 2002 at 04:01:34PM -0800, Joe Buck wrote:
> > > 4260 -- Is it HPUX?  Is it libtool?  Is it libstdc++?  Is it collect2?
> > 
> > No idea.  But is this issue even relevant for the 3.1 release, where minor
> > ABI breakage is *planned*?  (to fix some ABI conformance bugs).  If not,
> > then it's not a blocker for the release.
> 
> That's my opinion also, but I'm not a HPUX user.

I'd scratch HPUX and libstdc++ from the above list based on the analysis
that I have done.

It's not a blocker for the release since since the library internal name
and global constructor names are changing.  However, a solution needs to
be found if and when a minor release occurs that changes these names
incompatibly.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: GCC 3.1 Release

[Reichelt]

Hello,

Mark Mitchell wrote:

> Now that Richard has made GNATS immune to random new bugs being classified
> as "high" priority, it makes sense to go back to using high-priority bugs
> in GNATS -- rather than an external issuse list -- as our way to measure
> what needs to be done before the release.
>
> To that end, I've made sure that everything on the issues list is marked
> "high" in GNATS, and checked in a new copy of the issues list that
> indicates it is no longer in use.
>
> Now we need to weed out any not-really-high-priority bugs in GNATS, and
> fix what's there.

Last month I posted a list with several regressions from gcc 3.0.x and 2.95.x,
see http://gcc.gnu.org/ml/gcc/2002-03/msg00387.html

For some reason however, the bugs never made it to the 3.1-issues list.
Maybe it would be a good idea to mark some of them "high priority" in GNATS
(at least those that are not ice-on-illegal-code).

A slightly updated list for your convenience:

* Regressions from 3.0.4:
5078      ice-on-legal-code
5565      ice-on-illegal-code
5656      ice-on-illegal-code
5657      ice-on-illegal-code
5666      ice-on-illegal-code
5921      ice-on-illegal-code (wasn't included in the original list -
                               might be worth a "high priority" mark although
                               it is an ice-on-illegal-code, see
                               http://gcc.gnu.org/ml/gcc/2002-03/msg00449.html
                               for more information)

* Regressions from 2.95.3 that haven't been fixed in 3.0.x and are
  still present in the 3.1 branch:
4934      ice-on-legal-code
4954/5052 ice-on-legal-code
4979      ice-on-legal-code
5189      ice-on-legal-code
5571      ice-on-legal-code


I removed PR 4757 from the list because the bug was already present in gcc 2.95.2.

Greetings,
Volker Reichelt

Re: GCC 3.1 Release

[Mark Mitchell]

> A slightly updated list for your convenience:

Thanks.  I'll process those shortly.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

GCC 3.1 Release

[Mark Mitchell]

Now that Richard has made GNATS immune to random new bugs being classified
as "high" priority, it makes sense to go back to using high-priority bugs
in GNATS -- rather than an external issuse list -- as our way to measure
what needs to be done before the release.

To that end, I've made sure that everything on the issues list is marked
"high" in GNATS, and checked in a new copy of the issues list that
indicates it is no longer in use.

Now we need to weed out any not-really-high-priority bugs in GNATS, and
fix what's there.

Thanks,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC 3.1 Release

[Tom Tromey]

>>>>> "Mark" == Mark Mitchell <mark@codesourcery.com> writes:

Mark> Now we need to weed out any not-really-high-priority bugs in
Mark> GNATS, and fix what's there.

FYI, this has already been done for the java and libgcj categories.

Tom

Re: GCC 3.1 Release

[Phil Edwards]

On Tue, Apr 02, 2002 at 02:23:00PM -0800, Mark Mitchell wrote:
> Now we need to weed out any not-really-high-priority bugs in GNATS, and
> fix what's there.

There are four hi-pri reports for libstdc++.  They may or may not qualify as
"not really," if you and Benjamin would like to make that call.


3759 -- basically fallout from the committee LWG's DR 225 and 229.  I vote
        that this PR be suspended until those DRs get resolved, just because
        there doesn't seem to be anything effective we can do until then.

3628 -- the std::rel_ops operators cause ambiguous overloads with vector
        and string iterators.

4260 -- Is it HPUX?  Is it libtool?  Is it libstdc++?  Is it collect2?

5396 -- This is one of those PRs that got set to high by the submitter.
        I plan to test this myself as soon as I get a working build
        on solaris.  Debugging this kind of thing is a nightmare, since
        printing out local and member variables in gdb fails with some
        kind of RTTI error, so stepping through the I/O library doesn't
        really gain anything.


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: GCC 3.1 Release

[Joe Buck]

> On Tue, Apr 02, 2002 at 02:23:00PM -0800, Mark Mitchell wrote:
> > Now we need to weed out any not-really-high-priority bugs in GNATS, and
> > fix what's there.
> 
> There are four hi-pri reports for libstdc++.  They may or may not qualify as
> "not really," if you and Benjamin would like to make that call.
> 
> 
> 3759 -- basically fallout from the committee LWG's DR 225 and 229.  I vote
>         that this PR be suspended until those DRs get resolved, just because
>         there doesn't seem to be anything effective we can do until then.

This one should not be high priority, since the standards committee is
battling it out.  Certainly given the April 15th schedule, we should punt.

> 3628 -- the std::rel_ops operators cause ambiguous overloads with vector
>         and string iterators.

I'd really like to see this one fixed.  IMHO, the fixing isn't hard, it's the
arguments between the contributors that seem to get in the way (some going
so far as to try to deprecate std::rel_ops so we don't have to think about
a fix).  This causes portability problems so bad that I wound up turning
all the !='s into !(... == ...) in a big hunk of code that successfully
ran on about six compilers (including gcc 2.95.x and the very nitpicky
HP aCC).

> 4260 -- Is it HPUX?  Is it libtool?  Is it libstdc++?  Is it collect2?

No idea.  But is this issue even relevant for the 3.1 release, where minor
ABI breakage is *planned*?  (to fix some ABI conformance bugs).  If not,
then it's not a blocker for the release.

> 5396 -- This is one of those PRs that got set to high by the submitter.
>         I plan to test this myself as soon as I get a working build
>         on solaris.  Debugging this kind of thing is a nightmare, since
>         printing out local and member variables in gdb fails with some
>         kind of RTTI error, so stepping through the I/O library doesn't
>         really gain anything.

Is this a sync-with-stdio issue?  Does turning off synchronization make
the performance bug go away?

Re: GCC 3.1 Release

[Phil Edwards]

On Wed, Apr 03, 2002 at 04:01:34PM -0800, Joe Buck wrote:
> > 4260 -- Is it HPUX?  Is it libtool?  Is it libstdc++?  Is it collect2?
> 
> No idea.  But is this issue even relevant for the 3.1 release, where minor
> ABI breakage is *planned*?  (to fix some ABI conformance bugs).  If not,
> then it's not a blocker for the release.

That's my opinion also, but I'm not a HPUX user.


> > 5396 -- This is one of those PRs that got set to high by the submitter.
> >         I plan to test this myself as soon as I get a working build
> >         on solaris.  Debugging this kind of thing is a nightmare, since
> >         printing out local and member variables in gdb fails with some
> >         kind of RTTI error, so stepping through the I/O library doesn't
> >         really gain anything.
> 
> Is this a sync-with-stdio issue?  Does turning off synchronization make
> the performance bug go away?

The submitter's testcase is using fstreams, so it doesn't look to be s-w-s.

I started a solaris bootstrap just before I posted my summary, and it's still
going, so I haven't had a chance to poke at it yet.


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: GCC 3.1 Release

[Mark Mitchell]

--On Wednesday, April 03, 2002 04:01:34 PM -0800 Joe Buck 
<Joe.Buck@synopsys.com> wrote:

>> On Tue, Apr 02, 2002 at 02:23:00PM -0800, Mark Mitchell wrote:
>> > Now we need to weed out any not-really-high-priority bugs in GNATS, and
>> > fix what's there.
>>
>> There are four hi-pri reports for libstdc++.  They may or may not
>> qualify as "not really," if you and Benjamin would like to make that
>> call.
>>
>>
>> 3759 -- basically fallout from the committee LWG's DR 225 and 229.  I
>> vote that this PR be suspended until those DRs get resolved, just because
>>         there doesn't seem to be anything effective we can do until then.
>
> This one should not be high priority, since the standards committee is
> battling it out.  Certainly given the April 15th schedule, we should punt.

Agreed, I've downgraded it.

>> 3628 -- the std::rel_ops operators cause ambiguous overloads with vector
>>         and string iterators.
=
> I'd really like to see this one fixed.  IMHO, the fixing isn't hard

Do you have a patch?  Is the problem the result of a compiler bug, or
a library bug?

>> 4260 -- Is it HPUX?  Is it libtool?  Is it libstdc++?  Is it collect2?

> No idea.  But is this issue even relevant for the 3.1 release, where minor
> ABI breakage is *planned*?  (to fix some ABI conformance bugs).  If not,
> then it's not a blocker for the release.

I've closed this issue.  As you say, we know there is ABI breakage.

Thanks,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC 3.1 Release

[Joe Buck]

> >> 3628 -- the std::rel_ops operators cause ambiguous overloads with vector
> >>         and string iterators.
> =
> > I'd really like to see this one fixed.  IMHO, the fixing isn't hard
> 
> Do you have a patch?  Is the problem the result of a compiler bug, or
> a library bug?

It's a library bug.  It can be fixed by adding explicit comparison
operators for the vector and string iterators.

The downside of that is that it adds a bit of extra bloat.

Re: GCC 3.1 Release

[Benjamin Kosnik]

> It's a library bug.  It can be fixed by adding explicit comparison
> operators for the vector and string iterators.

Enough talk. Let's see the patch.

:)

-benjamin

Re: GCC 3.1 Release

[Gabriel Dos Reis]

Joe Buck <Joe.Buck@synopsys.com> writes:

| > >> 3628 -- the std::rel_ops operators cause ambiguous overloads with vector
| > >>         and string iterators.
| > =
| > > I'd really like to see this one fixed.  IMHO, the fixing isn't hard
| > 
| > Do you have a patch?  Is the problem the result of a compiler bug, or
| > a library bug?
| 
| It's a library bug. 

Well, I'm not at all convinced that this is a library bug.  But I
guess we'll just restart an old discussion.

| It can be fixed by adding explicit comparison
| operators for the vector and string iterators.

Huh?!?

-- Gaby

Re: GCC 3.1 Release

[Mark Mitchell]

> It's a library bug.  It can be fixed by adding explicit comparison
> operators for the vector and string iterators.
>
> The downside of that is that it adds a bit of extra bloat.

If you can produce a patch for the problem, the I will review it --
and I'm sure the V3 folks will be happy to do so as well.  It sounds
like you're in the best position to produce the patch.

Thanks,

--
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

Re: GCC 3.1 Release

[Joe Buck]

> > It's a library bug.  It can be fixed by adding explicit comparison
> > operators for the vector and string iterators.
> >
> > The downside of that is that it adds a bit of extra bloat.
> 
> If you can produce a patch for the problem, the I will review it --
> and I'm sure the V3 folks will be happy to do so as well.  It sounds
> like you're in the best position to produce the patch.

I'm going to give you a partial patch.  The reason is that I still
haven't won my battle with a company lawyer who doesn't like the FSF's
patent clause in the contribution document.  So instead I'll show you
how to fix the bug by giving one of the four new templates needed.
That way the size of my contribution will be smaller than the limit
RMS feels comfortable with for folks with no papers on file.

The issue is that, for std::rel_ops::operator!=, the types of the two
arguments are constrained to be the same, while in stl_iterator.h, we
define another operator!= template that allows the two arguments to be
different.  The solution is to add another template definition, as
follows:

*** /u/jbuck/gcc-3.1-pre/include/g++-v3/bits/stl_iterator.h~	Wed Apr 10
13:26:51 2002
--- /u/jbuck/gcc-3.1-pre/include/g++-v3/bits/stl_iterator.h	Wed Apr 10
16:43:56 2002
***************
*** 645,650 ****
--- 645,657 ----
	     const __normal_iterator<_IteratorR, _Container>& __rhs)
    { return !(__lhs == __rhs); }
  
+   // the following is to avoid conflict with std::rel_ops::operator!=
+   template<typename _Iterator, typename _Container>
+   inline bool
+   operator!=(const __normal_iterator<_Iterator, _Container>& __lhs,
+	     const __normal_iterator<_Iterator, _Container>& __rhs)
+   { return !(__lhs == __rhs); }
+ 
    // Random access iterator requirements
    template<typename _IteratorL, typename _IteratorR, typename
_Container>
    inline bool 

---------------------------------
This removes the ambiguity: in all cases where the new template can
be used, it wins over the one from rel_ops because it is more specific,
as well as the alternative template in stl_iterator.h.

In addition to the above, we also need the corresponding operator>,
operator>=, and operator<=.

Re: GCC 3.1 Release

[Gabriel Dos Reis]

Joe Buck <Joe.Buck@synopsys.com> writes:

[...]

| I'm going to give you a partial patch.  The reason is that I still
| haven't won my battle with a company lawyer who doesn't like the FSF's
| patent clause in the contribution document.  So instead I'll show you
| how to fix the bug by giving one of the four new templates needed.
| That way the size of my contribution will be smaller than the limit
| RMS feels comfortable with for folks with no papers on file.
| 
| The issue is that, for std::rel_ops::operator!=, the types of the two
| arguments are constrained to be the same, while in stl_iterator.h, we
| define another operator!= template that allows the two arguments to be
| different.  The solution is to add another template definition, as
| follows:

A better solution is to move all those things that have no business in
std:: into __gnu_cxx::.  If we don't do it now we can't do it in a dot
release as it would be an ABI change -- and I would hate to maintain
two different versions.

-- Gaby

Re: GCC 3.1 Release

[Joe Buck]

I wrote:
> | The issue is that, for std::rel_ops::operator!=, the types of the two
> | arguments are constrained to be the same, while in stl_iterator.h, we
> | define another operator!= template that allows the two arguments to be
> | different.  The solution is to add another template definition, as
> | follows:

Gaby writes:
> A better solution is to move all those things that have no business in
> std:: into __gnu_cxx::.  If we don't do it now we can't do it in a dot
> release as it would be an ABI change -- and I would hate to maintain
> two different versions.

I don't understand.  Do you mean that you want to move __normal_iterator
to a different namespace?

In any case, a decision to move things around seems to me to be orthogonal
to the operator!= issue.

Re: GCC 3.1 Release

[Mark Mitchell]

--On Wednesday, April 10, 2002 7:55 AM -0700 Joe Buck 
<Joe.Buck@synopsys.com> wrote:

>
>> > It's a library bug.  It can be fixed by adding explicit comparison
>> > operators for the vector and string iterators.
>> >
>> > The downside of that is that it adds a bit of extra bloat.
>>
>> If you can produce a patch for the problem, the I will review it --
>> and I'm sure the V3 folks will be happy to do so as well.  It sounds
>> like you're in the best position to produce the patch.
>
> I'm going to give you a partial patch.

OK, I understand your situtation.

I think your patch makes sense.  Benjamin what do you think?

Gaby, if we can do something like this, it will definitely make things
easier for users.  The standard specifies that std::rel_ops exists, and
it also specifies that iterators have an operator==, and it certainly
makes sense to make those two things work together if at all possible.

Joe's patch looks logical; do you have an alternative patch that you
think would be a cleaner solution?

--
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

Re: GCC 3.1 Release

[Benjamin Kosnik]

> I think your patch makes sense.  Benjamin what do you think?

Seems fine. I'm interested in seeing a complete patch. Perhaps somebody 
could take Joe's sketched solution and make it complete, and add a testcase?

I'm in the middle of other issues, so I can't be more hands-on on this, 
sorry. 

-benjamin

Re: GCC 3.1 Release

[Paolo Carlini]

Benjamin Kosnik wrote:

>>I think your patch makes sense.  Benjamin what do you think?
>>
>Seems fine. I'm interested in seeing a complete patch. Perhaps somebody 
>could take Joe's sketched solution and make it complete, and add a testcase?
>
I can do this in the next two hours.

Ciao, Paolo.

Re: GCC 3.1 Release

[Paolo Carlini]

Gabriel Dos Reis wrote:

>Please, if you're going to do this, don't add yet another non-standard
>operator in std::.  Consider moving the __normal_iterator bits in
>__gnu_cxx::.
>
Gaby, thanks for your feedback. However, consider that here in Italy is 
already evening and don't expect too much from me before tomorrow :-)

Seriously, I have no problem implementing, completing with a testcase 
and testing the solution sketched by Joe, and I'm indeed pleased to do 
that, but if you think something different is in order, please explain 
it in little more detail and, in any case, I cannot make promises on 
when I will be able to complete the task...

Ciao, Paolo.

Re: GCC 3.1 Release

[Gabriel Dos Reis]

Paolo Carlini <pcarlini@unitus.it> writes:

[...]

| Seriously, I have no problem implementing, completing with a testcase 
| and testing the solution sketched by Joe, and I'm indeed pleased to do 
| that, but if you think something different is in order, please explain 
| it in little more detail

I just realized that my replies to Mark and Joe didn't show up :-(

Yes, I meant moving the __normal_iterator<> definition into
__gnu_cxx:: with accompanying helper functions.  And also, Joe patch
should be put in that namespace also (since that is where Koenig
lookup should find them).

-- Gaby

Re: GCC 3.1 Release

[Joe Buck]

Gaby writes:

> Yes, I meant moving the __normal_iterator<> definition into
> __gnu_cxx:: with accompanying helper functions.  And also, Joe patch
> should be put in that namespace also (since that is where Koenig
> lookup should find them).

OK, so you're proposing the move to a different namespace in addition
to my patch, rather than instead of.  That's doable, but is there
really a strong reason to do the move?  What's the harm in having
additional __ names in std?

Re: GCC 3.1 Release

[Gabriel Dos Reis]

Joe Buck <Joe.Buck@synopsys.com> writes:

| Gaby writes:
| 
| > Yes, I meant moving the __normal_iterator<> definition into
| > __gnu_cxx:: with accompanying helper functions.  And also, Joe patch
| > should be put in that namespace also (since that is where Koenig
| > lookup should find them).
| 
| OK, so you're proposing the move to a different namespace in addition
| to my patch, rather than instead of.  That's doable, but is there
| really a strong reason to do the move?  What's the harm in having
| additional __ names in std?

No, you aren't having a __ name in std::.  You're defining another
user visible visible (operator==) in std::.  

-- Gaby

Re: GCC 3.1 Release

[Gabriel Dos Reis]

Mark Mitchell <mark@codesourcery.com> writes:

[...]

| I think your patch makes sense.  Benjamin what do you think?
| 
| Gaby, if we can do something like this, it will definitely make things
| easier for users.  The standard specifies that std::rel_ops exists, and
| it also specifies that iterators have an operator==, and it certainly
| makes sense to make those two things work together if at all possible.


Mark,

  Here is a patch to move the __normal_iterator<> bits into
__gnu_cxx:: along with the patch suggested by Joe.  It also
incorporates Paolo's test.  Bootstrapped and tested on
i686-pc-linux-gnu (3.1 branch).

I'll apply the same thing to mainline.  Branch requires your approval
if I understand correctly.

-- Gaby

Index: ChangeLog
===================================================================
RCS file: /cvs/gcc/gcc/libstdc++-v3/ChangeLog,v
retrieving revision 1.1057.2.73
diff -p -r1.1057.2.73 ChangeLog
*** ChangeLog	15 Apr 2002 20:35:46 -0000	1.1057.2.73
--- ChangeLog	16 Apr 2002 00:42:15 -0000
***************
*** 1,3 ****
--- 1,19 ----
+ 2002-04-16  Paolo Carlini <pcarlini@unitus.it>
+ 	* testsuite/24_iterators/rel_ops.cc: New test.
+ 	
+ 2002-04-16  Gabriel Dos Reis  <gdr@merlin.codesourcery.com>
+ 
+ 	* include/bits/type_traits.h (__normal_iterator): Declare in
+ 	__gnu_cxx.  Adjust use at global namespace.
+ 	* include/bits/stl_iterator.h (__normal_iterator): Move definition
+ 	into __gnu_cxx::. Add more operator overloads.  Tidy existing ones.
+ 	* include/bits/basic_string.h (basic_string): Adjust use of
+ 	__normal_iterator.
+ 	* include/bits/stl_vector.h (_Alloc>): Likewise.
+ 	* src/concept-inst.cc (__gnu_cxx): __normal_iterator<> is now here.
+ 	* src/locale-inst.cc (__gnu_cxx): Likewise.
+ 	* src/string-inst.cc (operator==): Instantiate in __gnu_cxx.
+ 
  2002-04-15  Steve Ellcey  <sje@cup.hp.com>
  
  	* gcc/libstdc++-v3/config/os/hpux/bits/os_defines.h
Index: include/bits/basic_string.h
===================================================================
RCS file: /cvs/gcc/gcc/libstdc++-v3/include/bits/basic_string.h,v
retrieving revision 1.19.2.2
diff -p -r1.19.2.2 basic_string.h
*** include/bits/basic_string.h	1 Apr 2002 18:56:28 -0000	1.19.2.2
--- include/bits/basic_string.h	16 Apr 2002 00:42:16 -0000
*************** namespace std
*** 99,106 ****
        typedef typename _Alloc::const_reference 		    const_reference;
        typedef typename _Alloc::pointer 			    pointer;
        typedef typename _Alloc::const_pointer 	   	    const_pointer;
!       typedef __normal_iterator<pointer, basic_string> 	    iterator;
!       typedef __normal_iterator<const_pointer, basic_string> const_iterator;
        typedef reverse_iterator<const_iterator> 	const_reverse_iterator;
        typedef reverse_iterator<iterator> 		    reverse_iterator;
      
--- 99,107 ----
        typedef typename _Alloc::const_reference 		    const_reference;
        typedef typename _Alloc::pointer 			    pointer;
        typedef typename _Alloc::const_pointer 	   	    const_pointer;
!       typedef __gnu_cxx::__normal_iterator<pointer, basic_string>  iterator;
!       typedef __gnu_cxx::__normal_iterator<const_pointer, basic_string>
!                                                             const_iterator;
        typedef reverse_iterator<const_iterator> 	const_reverse_iterator;
        typedef reverse_iterator<iterator> 		    reverse_iterator;
      
Index: include/bits/stl_iterator.h
===================================================================
RCS file: /cvs/gcc/gcc/libstdc++-v3/include/bits/stl_iterator.h,v
retrieving revision 1.19
diff -p -r1.19 stl_iterator.h
*** include/bits/stl_iterator.h	8 Feb 2002 07:34:54 -0000	1.19
--- include/bits/stl_iterator.h	16 Apr 2002 00:42:16 -0000
*************** namespace std
*** 548,554 ****
        return insert_iterator<_Container>(__x, 
  					 typename _Container::iterator(__i));
      }
!   
    // This iterator adapter is 'normal' in the sense that it does not
    // change the semantics of any of the operators of its iterator
    // parameter.  Its primary purpose is to convert an iterator that is
--- 548,557 ----
        return insert_iterator<_Container>(__x, 
  					 typename _Container::iterator(__i));
      }
! } // namespace std
! 
! namespace __gnu_cxx
! {  
    // This iterator adapter is 'normal' in the sense that it does not
    // change the semantics of any of the operators of its iterator
    // parameter.  Its primary purpose is to convert an iterator that is
*************** namespace std
*** 556,561 ****
--- 559,566 ----
    // The _Container parameter exists solely so that different containers
    // using this template can instantiate different types, even if the
    // _Iterator parameter is the same.
+   using std::iterator_traits;
+   using std::iterator;
    template<typename _Iterator, typename _Container>
      class __normal_iterator
        : public iterator<typename iterator_traits<_Iterator>::iterator_category,
*************** namespace std
*** 632,637 ****
--- 637,650 ----
        base() const { return _M_current; }
      };
  
+   // Note: In what follows, the left- and right-hand-side iterators are
+   // allowed to vary in types (conceptually in cv-qualification) so that
+   // comparaison between cv-qualified and non-cv-qualified iterators be
+   // valid.  However, the greedy and unfriendly operators in std::rel_ops
+   // will make overload resolution ambiguous (when in scope) if we don't
+   // provide overloads whose operands are of the same type.  Can someone
+   // remind me what generic programming is about? -- Gaby
+   
    // Forward iterator requirements
    template<typename _IteratorL, typename _IteratorR, typename _Container>
    inline bool
*************** namespace std
*** 639,649 ****
  	     const __normal_iterator<_IteratorR, _Container>& __rhs)
    { return __lhs.base() == __rhs.base(); }
  
    template<typename _IteratorL, typename _IteratorR, typename _Container>
    inline bool
    operator!=(const __normal_iterator<_IteratorL, _Container>& __lhs,
  	     const __normal_iterator<_IteratorR, _Container>& __rhs)
!   { return !(__lhs == __rhs); }
  
    // Random access iterator requirements
    template<typename _IteratorL, typename _IteratorR, typename _Container>
--- 652,674 ----
  	     const __normal_iterator<_IteratorR, _Container>& __rhs)
    { return __lhs.base() == __rhs.base(); }
  
+   template<typename _Iterator, typename _Container>
+   inline bool
+   operator==(const __normal_iterator<_Iterator, _Container>& __lhs,
+              const __normal_iterator<_Iterator, _Container>& __rhs)
+   { return __lhs.base() == __rhs.base(); }
+ 
    template<typename _IteratorL, typename _IteratorR, typename _Container>
    inline bool
    operator!=(const __normal_iterator<_IteratorL, _Container>& __lhs,
  	     const __normal_iterator<_IteratorR, _Container>& __rhs)
!   { return __lhs.base() != __rhs.base(); }
! 
!   template<typename _Iterator, typename _Container>
!   inline bool
!   operator!=(const __normal_iterator<_Iterator, _Container>& __lhs,
!              const __normal_iterator<_Iterator, _Container>& __rhs)
!   { return __lhs.base() != __rhs.base(); }
  
    // Random access iterator requirements
    template<typename _IteratorL, typename _IteratorR, typename _Container>
*************** namespace std
*** 652,681 ****
  	    const __normal_iterator<_IteratorR, _Container>& __rhs)
    { return __lhs.base() < __rhs.base(); }
  
    template<typename _IteratorL, typename _IteratorR, typename _Container>
    inline bool
    operator>(const __normal_iterator<_IteratorL, _Container>& __lhs,
  	    const __normal_iterator<_IteratorR, _Container>& __rhs)
!   { return __rhs < __lhs; }
  
    template<typename _IteratorL, typename _IteratorR, typename _Container>
    inline bool
    operator<=(const __normal_iterator<_IteratorL, _Container>& __lhs,
  	     const __normal_iterator<_IteratorR, _Container>& __rhs)
!   { return !(__rhs < __lhs); }
  
    template<typename _IteratorL, typename _IteratorR, typename _Container>
    inline bool
    operator>=(const __normal_iterator<_IteratorL, _Container>& __lhs,
  	     const __normal_iterator<_IteratorR, _Container>& __rhs)
!   { return !(__lhs < __rhs); }
  
    template<typename _Iterator, typename _Container>
    inline __normal_iterator<_Iterator, _Container>
    operator+(typename __normal_iterator<_Iterator, _Container>::difference_type __n,
  	    const __normal_iterator<_Iterator, _Container>& __i)
    { return __normal_iterator<_Iterator, _Container>(__i.base() + __n); }
! } // namespace std
  
  #endif 
  
--- 677,730 ----
  	    const __normal_iterator<_IteratorR, _Container>& __rhs)
    { return __lhs.base() < __rhs.base(); }
  
+   template<typename _Iterator, typename _Container>
+   inline bool
+   operator<(const __normal_iterator<_Iterator, _Container>& __lhs,
+              const __normal_iterator<_Iterator, _Container>& __rhs)
+   { return __lhs.base() < __rhs.base(); }
+ 
    template<typename _IteratorL, typename _IteratorR, typename _Container>
    inline bool
    operator>(const __normal_iterator<_IteratorL, _Container>& __lhs,
  	    const __normal_iterator<_IteratorR, _Container>& __rhs)
!   { return __lhs.base() > __rhs.base(); }
! 
!   template<typename _Iterator, typename _Container>
!   inline bool
!   operator>(const __normal_iterator<_Iterator, _Container>& __lhs,
! 	    const __normal_iterator<_Iterator, _Container>& __rhs)
!   { return __lhs.base() > __rhs.base(); }
  
    template<typename _IteratorL, typename _IteratorR, typename _Container>
    inline bool
    operator<=(const __normal_iterator<_IteratorL, _Container>& __lhs,
  	     const __normal_iterator<_IteratorR, _Container>& __rhs)
!   { return __lhs.base() <= __rhs.base(); }
! 
!   template<typename _Iterator, typename _Container>
!   inline bool
!   operator<=(const __normal_iterator<_Iterator, _Container>& __lhs,
! 	     const __normal_iterator<_Iterator, _Container>& __rhs)
!   { return __lhs.base() <= __rhs.base(); }
  
    template<typename _IteratorL, typename _IteratorR, typename _Container>
    inline bool
    operator>=(const __normal_iterator<_IteratorL, _Container>& __lhs,
  	     const __normal_iterator<_IteratorR, _Container>& __rhs)
!   { return __lhs.base() >= __rhs.base(); }
! 
!   template<typename _Iterator, typename _Container>
!   inline bool
!   operator>=(const __normal_iterator<_Iterator, _Container>& __lhs,
! 	     const __normal_iterator<_Iterator, _Container>& __rhs)
!   { return __lhs.base() >= __rhs.base(); }
  
    template<typename _Iterator, typename _Container>
    inline __normal_iterator<_Iterator, _Container>
    operator+(typename __normal_iterator<_Iterator, _Container>::difference_type __n,
  	    const __normal_iterator<_Iterator, _Container>& __i)
    { return __normal_iterator<_Iterator, _Container>(__i.base() + __n); }
! } // namespace __gnu_cxx
  
  #endif 
  
Index: include/bits/stl_vector.h
===================================================================
RCS file: /cvs/gcc/gcc/libstdc++-v3/include/bits/stl_vector.h,v
retrieving revision 1.17.2.2
diff -p -r1.17.2.2 stl_vector.h
*** include/bits/stl_vector.h	27 Mar 2002 21:54:38 -0000	1.17.2.2
--- include/bits/stl_vector.h	16 Apr 2002 00:42:17 -0000
*************** public:
*** 175,182 ****
    typedef _Tp 						value_type;
    typedef value_type* 					pointer;
    typedef const value_type* 				const_pointer;
!   typedef __normal_iterator<pointer, vector_type> 	iterator;
!   typedef __normal_iterator<const_pointer, vector_type> const_iterator;
    typedef value_type& 					reference;
    typedef const value_type& 				const_reference;
    typedef size_t 					size_type;
--- 175,183 ----
    typedef _Tp 						value_type;
    typedef value_type* 					pointer;
    typedef const value_type* 				const_pointer;
!   typedef __gnu_cxx::__normal_iterator<pointer, vector_type> 	iterator;
!   typedef __gnu_cxx::__normal_iterator<const_pointer, vector_type>
!                                                         const_iterator;
    typedef value_type& 					reference;
    typedef const value_type& 				const_reference;
    typedef size_t 					size_type;
Index: include/bits/type_traits.h
===================================================================
RCS file: /cvs/gcc/gcc/libstdc++-v3/include/bits/type_traits.h,v
retrieving revision 1.11
diff -p -r1.11 type_traits.h
*** include/bits/type_traits.h	2 Nov 2001 22:31:02 -0000	1.11
--- include/bits/type_traits.h	16 Apr 2002 00:42:17 -0000
*************** template<typename _Tp> struct _Is_normal
*** 322,334 ****
  };
  
  // Forward declaration hack, should really include this from somewhere.
! namespace std 
  {
    template<typename _Iterator, typename _Container> class __normal_iterator;
  }
  
  template<typename _Iterator, typename _Container>
! struct _Is_normal_iterator< std::__normal_iterator<_Iterator, _Container> > {
     typedef __true_type _Normal;
  };
  
--- 322,334 ----
  };
  
  // Forward declaration hack, should really include this from somewhere.
! namespace __gnu_cxx
  {
    template<typename _Iterator, typename _Container> class __normal_iterator;
  }
  
  template<typename _Iterator, typename _Container>
! struct _Is_normal_iterator< __gnu_cxx::__normal_iterator<_Iterator, _Container> > {
     typedef __true_type _Normal;
  };
  
Index: src/concept-inst.cc
===================================================================
RCS file: /cvs/gcc/gcc/libstdc++-v3/src/concept-inst.cc,v
retrieving revision 1.3
diff -p -r1.3 concept-inst.cc
*** src/concept-inst.cc	4 Jan 2002 21:27:35 -0000	1.3
--- src/concept-inst.cc	16 Apr 2002 00:42:17 -0000
*************** namespace __gnu_cxx
*** 50,60 ****
    template void __aux_require_boolean_expr<bool>(bool const&);
  
    _Instantiate(_BidirectionalIteratorConcept<
!     std::__normal_iterator< std::locale::facet**,
      std::vector<std::locale::facet*,std::allocator<std::locale::facet*> > > > );
  
    _Instantiate(_BidirectionalIteratorConcept<
!     std::__normal_iterator< unsigned*,
      std::vector<unsigned, std::allocator<unsigned> > > > );
  
    _Instantiate(_ConvertibleConcept<std::locale::facet*, std::locale::facet*> );
--- 50,60 ----
    template void __aux_require_boolean_expr<bool>(bool const&);
  
    _Instantiate(_BidirectionalIteratorConcept<
!     __normal_iterator< std::locale::facet**,
      std::vector<std::locale::facet*,std::allocator<std::locale::facet*> > > > );
  
    _Instantiate(_BidirectionalIteratorConcept<
!     __normal_iterator< unsigned*,
      std::vector<unsigned, std::allocator<unsigned> > > > );
  
    _Instantiate(_ConvertibleConcept<std::locale::facet*, std::locale::facet*> );
*************** namespace __gnu_cxx
*** 68,82 ****
    _Instantiate(_InputIteratorConcept<std::locale::facet**> );
  
    _Instantiate(_InputIteratorConcept<
!     std::__normal_iterator< std::locale::facet* const*,
      std::vector<std::locale::facet*,std::allocator<std::locale::facet*> > > > );
  
    _Instantiate(_InputIteratorConcept<
!     std::__normal_iterator< std::locale::facet**,
      std::vector<std::locale::facet*,std::allocator<std::locale::facet*> > > > );
  
    _Instantiate(_InputIteratorConcept<
!     std::__normal_iterator< unsigned*,
      std::vector<unsigned, std::allocator<unsigned> > > > );
  
  #ifdef _GLIBCPP_USE_WCHAR_T
--- 68,82 ----
    _Instantiate(_InputIteratorConcept<std::locale::facet**> );
  
    _Instantiate(_InputIteratorConcept<
!     __normal_iterator< std::locale::facet* const*,
      std::vector<std::locale::facet*,std::allocator<std::locale::facet*> > > > );
  
    _Instantiate(_InputIteratorConcept<
!     __normal_iterator< std::locale::facet**,
      std::vector<std::locale::facet*,std::allocator<std::locale::facet*> > > > );
  
    _Instantiate(_InputIteratorConcept<
!     __normal_iterator< unsigned*,
      std::vector<unsigned, std::allocator<unsigned> > > > );
  
  #ifdef _GLIBCPP_USE_WCHAR_T
*************** namespace __gnu_cxx
*** 98,123 ****
    _Instantiate(_LessThanComparableConcept<unsigned> );
  
    _Instantiate(_Mutable_BidirectionalIteratorConcept<
!     std::__normal_iterator< std::locale::facet**,
      std::vector<std::locale::facet*,std::allocator<std::locale::facet*> > > > );
  
    _Instantiate(_Mutable_BidirectionalIteratorConcept<
!     std::__normal_iterator< unsigned*,
      std::vector<unsigned, std::allocator<unsigned> > > > );
  
    _Instantiate(_Mutable_ForwardIteratorConcept<
!     std::__normal_iterator< std::locale::facet**,
      std::vector<std::locale::facet*,std::allocator<std::locale::facet*> > > > );
  
    _Instantiate(_OutputIteratorConcept<
      std::locale::facet**, std::locale::facet*> );
  
    _Instantiate(_OutputIteratorConcept<
!     std::__normal_iterator< std::locale::facet**,
        std::vector<std::locale::facet*, std::allocator<std::locale::facet* > > >,
      std::locale::facet* > );
  
!   _Instantiate(_OutputIteratorConcept<std::__normal_iterator<
      unsigned*, std::vector<unsigned, std::allocator<unsigned> > >, unsigned> );
  
    _Instantiate(_OutputIteratorConcept<std::ostreambuf_iterator<
--- 98,123 ----
    _Instantiate(_LessThanComparableConcept<unsigned> );
  
    _Instantiate(_Mutable_BidirectionalIteratorConcept<
!     __normal_iterator< std::locale::facet**,
      std::vector<std::locale::facet*,std::allocator<std::locale::facet*> > > > );
  
    _Instantiate(_Mutable_BidirectionalIteratorConcept<
!     __normal_iterator< unsigned*,
      std::vector<unsigned, std::allocator<unsigned> > > > );
  
    _Instantiate(_Mutable_ForwardIteratorConcept<
!     __normal_iterator< std::locale::facet**,
      std::vector<std::locale::facet*,std::allocator<std::locale::facet*> > > > );
  
    _Instantiate(_OutputIteratorConcept<
      std::locale::facet**, std::locale::facet*> );
  
    _Instantiate(_OutputIteratorConcept<
!     __normal_iterator< std::locale::facet**,
        std::vector<std::locale::facet*, std::allocator<std::locale::facet* > > >,
      std::locale::facet* > );
  
!   _Instantiate(_OutputIteratorConcept<__normal_iterator<
      unsigned*, std::vector<unsigned, std::allocator<unsigned> > >, unsigned> );
  
    _Instantiate(_OutputIteratorConcept<std::ostreambuf_iterator<
*************** namespace __gnu_cxx
*** 133,151 ****
    _Instantiate(_RandomAccessIteratorConcept<char const*> );
  
    _Instantiate(_RandomAccessIteratorConcept<
!     std::__normal_iterator<char const*, std::string> > );
  
    _Instantiate(_RandomAccessIteratorConcept<
!     std::__normal_iterator<char*, std::string> > );
  
  #ifdef _GLIBCPP_USE_WCHAR_T
    _Instantiate(_RandomAccessIteratorConcept<
!     std::__normal_iterator<wchar_t const*,
      std::basic_string<wchar_t, std::char_traits<wchar_t>,
                                 std::allocator<wchar_t> > > > );
  
    _Instantiate(_RandomAccessIteratorConcept<
!     std::__normal_iterator<wchar_t*,
      std::basic_string<wchar_t, std::char_traits<wchar_t>,
                                 std::allocator<wchar_t> > > > );
  
--- 133,151 ----
    _Instantiate(_RandomAccessIteratorConcept<char const*> );
  
    _Instantiate(_RandomAccessIteratorConcept<
!     __normal_iterator<char const*, std::string> > );
  
    _Instantiate(_RandomAccessIteratorConcept<
!     __normal_iterator<char*, std::string> > );
  
  #ifdef _GLIBCPP_USE_WCHAR_T
    _Instantiate(_RandomAccessIteratorConcept<
!     __normal_iterator<wchar_t const*,
      std::basic_string<wchar_t, std::char_traits<wchar_t>,
                                 std::allocator<wchar_t> > > > );
  
    _Instantiate(_RandomAccessIteratorConcept<
!     __normal_iterator<wchar_t*,
      std::basic_string<wchar_t, std::char_traits<wchar_t>,
                                 std::allocator<wchar_t> > > > );
  
Index: src/locale-inst.cc
===================================================================
RCS file: /cvs/gcc/gcc/libstdc++-v3/src/locale-inst.cc,v
retrieving revision 1.29.2.2
diff -p -r1.29.2.2 locale-inst.cc
*** src/locale-inst.cc	25 Mar 2002 21:49:09 -0000	1.29.2.2
--- src/locale-inst.cc	16 Apr 2002 00:42:17 -0000
*************** namespace std
*** 410,422 ****
      has_facet<messages<wchar_t> >(const locale&);
  #endif
  
-   // iterator
-   typedef vector<locale::facet*> vec_pfacet;
    template class vector<locale::facet*>;
!   template class __normal_iterator<locale::facet**, vector<locale::facet*> >;
!   template class __normal_iterator<locale::facet* const*,
!                                    vector<locale::facet*> >;
  
    // locale
    template
      char*
--- 410,428 ----
      has_facet<messages<wchar_t> >(const locale&);
  #endif
  
    template class vector<locale::facet*>;
! } // namespace std
! 
! namespace __gnu_cxx
! {
!   // iterator
!   typedef std::vector<std::locale::facet*> vec_pfacet;
!   template class __normal_iterator<std::locale::facet**, vec_pfacet >;
!   template class __normal_iterator<std::locale::facet* const*, vec_pfacet>;
! } // namespace __gnu_cxx
  
+ namespace std
+ {
    // locale
    template
      char*
*************** namespace std
*** 490,495 ****
--- 496,502 ----
      fill_n<locale::facet**, size_t, locale::facet*>
      (locale::facet**, size_t, locale::facet* const&);
  
+   using __gnu_cxx::__normal_iterator;
    template
      __normal_iterator<locale::facet**, vector<locale::facet*> >
      fill_n(__normal_iterator<locale::facet**, vector<locale::facet*> >,
Index: src/string-inst.cc
===================================================================
RCS file: /cvs/gcc/gcc/libstdc++-v3/src/string-inst.cc,v
retrieving revision 1.24
diff -p -r1.24 string-inst.cc
*** src/string-inst.cc	16 Feb 2002 00:19:13 -0000	1.24
--- src/string-inst.cc	16 Apr 2002 00:42:17 -0000
*************** namespace std 
*** 48,56 ****
--- 48,64 ----
    template class basic_string<C>;
    template S operator+(const C*, const S&);
    template S operator+(C, const S&);
+ } // namespace std
+ 
+ namespace __gnu_cxx
+ {
+   using std::S;
    template bool operator==(const S::iterator&, const S::iterator&);
    template bool operator==(const S::const_iterator&, const S::const_iterator&);
+ }
  
+ namespace std
+ {
    // Only one template keyword allowed here. 
    // See core issue #46 (NAD)
    // http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_closed.html#46
Index: testsuite/24_iterators/rel_ops.cc
===================================================================
RCS file: testsuite/24_iterators/rel_ops.cc
diff -N testsuite/24_iterators/rel_ops.cc
*** /dev/null	1 Jan 1970 00:00:00 -0000
--- testsuite/24_iterators/rel_ops.cc	16 Apr 2002 00:42:17 -0000
***************
*** 0 ****
--- 1,45 ----
+ // 2002-04-13  Paolo Carlini  <pcarlini@unitus.it>
+ 
+ // Copyright (C) 2002 Free Software Foundation, Inc.
+ //
+ // This file is part of the GNU ISO C++ Library.  This library is free
+ // software; you can redistribute it and/or modify it under the
+ // terms of the GNU General Public License as published by the
+ // Free Software Foundation; either version 2, or (at your option)
+ // any later version.
+ 
+ // This library is distributed in the hope that it will be useful,
+ // but WITHOUT ANY WARRANTY; without even the implied warranty of
+ // MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ // GNU General Public License for more details.
+ 
+ // You should have received a copy of the GNU General Public License along
+ // with this library; see the file COPYING.  If not, write to the Free
+ // Software Foundation, 59 Temple Place - Suite 330, Boston, MA 02111-1307,
+ // USA.
+ 
+ // 20.2.1 Operators
+ 
+ #include <utility>
+ #include <vector>
+ 
+ using namespace std::rel_ops;
+ 
+ // libstdc++/3628
+ void test01()
+ {
+   std::vector<int> v;
+   std::vector<int>::iterator vi;
+ 
+   vi != v.begin();
+   vi > v.begin();
+   vi <= v.begin();
+   vi >= v.begin();
+ }
+ 
+ int main()
+ {
+   test01();
+   return 0;
+ }
+ 

Re: GCC 3.1 Release

[Gabriel Dos Reis]

Gabriel Dos Reis <gdr@codesourcery.com> writes:

[...]

| Mark,
| 
|   Here is a patch to move the __normal_iterator<> bits into
| __gnu_cxx:: along with the patch suggested by Joe.  It also
| incorporates Paolo's test.  Bootstrapped and tested on
| i686-pc-linux-gnu (3.1 branch).
| 
| I'll apply the same thing to mainline.

Done.

-- Gaby

Re: GCC 3.1 Release

[Mark Mitchell]

> I'll apply the same thing to mainline.  Branch requires your approval
> if I understand correctly.

Do it.  And thank you.  And please close the high-priority PR. :-)

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC 3.1 Release

[Gabriel Dos Reis]

Mark Mitchell <mark@codesourcery.com> writes:

| > I'll apply the same thing to mainline.  Branch requires your approval
| > if I understand correctly.
| 
| Do it.  And thank you.  And please close the high-priority PR. :-)

Done.  Thanks.

-- Gaby

Re: GCC 3.1 Release

[Jason Merrill]

BTW, I notice that most of the current high-priority c++ PRs are classified
as ice-on-illegal-code.  I don't think such bugs merit high priority, even
if they are regressions.

Jason

Re: GCC 3.1 Release

[Janis Johnson]

On Tue, Apr 02, 2002 at 02:23:00PM -0800, Mark Mitchell wrote:
> Now that Richard has made GNATS immune to random new bugs being classified
> as "high" priority, it makes sense to go back to using high-priority bugs
> in GNATS -- rather than an external issuse list -- as our way to measure
> what needs to be done before the release.
> 
> To that end, I've made sure that everything on the issues list is marked
> "high" in GNATS, and checked in a new copy of the issues list that
> indicates it is no longer in use.

What's the right way to ask for bugs to be high priority?

PR optimization/6177 (ia64 ICE with single-element complex array in
LAPACK) describes a bug introduced on April 2.  It affects i686 also.
An update to the PR includes a six line Fortran test case.

Janis

Re: GCC 3.1 Release

[Mark Mitchell]

> What's the right way to ask for bugs to be high priority?

You just did it.  It's probably best to copy me directly.

> PR optimization/6177 (ia64 ICE with single-element complex array in
> LAPACK) describes a bug introduced on April 2.  It affects i686 also.
> An update to the PR includes a six line Fortran test case.

OK, I've updated the bug list.

--
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

Re: GCC 3.1 Release

[Christian Jönsson]

On Wed, Apr 10, 2002 at 10:14:39AM -0700, Janis Johnson wrote:

> An update to the PR includes a six line Fortran test case.

Is this tested by the g77 testsuite? If not, can't we incorporate the
PR's test case in g77's testsuite?

Cheers,

/ChJ