* Re: GCC 3.1 Release
@ 2002-04-13 13:51 Robert Dewar
0 siblings, 0 replies; 80+ messages in thread
From: Robert Dewar @ 2002-04-13 13:51 UTC (permalink / raw)
To: mark, tromey; +Cc: gcc
<<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.
^ permalink raw reply [flat|nested] 80+ messages in thread
* GCC 3.1 Release @ 2002-05-05 11:37 Mark Mitchell 2002-05-05 15:00 ` Florian Weimer 0 siblings, 1 reply; 80+ messages in thread From: Mark Mitchell @ 2002-05-05 11:37 UTC (permalink / raw) To: gcc 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release 2002-05-05 11:37 Mark Mitchell @ 2002-05-05 15:00 ` Florian Weimer 2002-05-06 3:24 ` Andreas Schwab 0 siblings, 1 reply; 80+ messages in thread From: Florian Weimer @ 2002-05-05 15:00 UTC (permalink / raw) To: Mark Mitchell; +Cc: gcc, dewar 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. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release 2002-05-05 15:00 ` Florian Weimer @ 2002-05-06 3:24 ` Andreas Schwab 2002-05-06 7:54 ` Mark Mitchell 0 siblings, 1 reply; 80+ messages in thread From: Andreas Schwab @ 2002-05-06 3:24 UTC (permalink / raw) To: Mark Mitchell; +Cc: gcc, dewar 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." ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release 2002-05-06 3:24 ` Andreas Schwab @ 2002-05-06 7:54 ` Mark Mitchell 2002-05-06 7:57 ` Andreas Schwab 0 siblings, 1 reply; 80+ messages in thread From: Mark Mitchell @ 2002-05-06 7:54 UTC (permalink / raw) To: Andreas Schwab; +Cc: gcc, dewar --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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release 2002-05-06 7:54 ` Mark Mitchell @ 2002-05-06 7:57 ` Andreas Schwab 2002-05-06 15:16 ` Mark Mitchell 0 siblings, 1 reply; 80+ messages in thread From: Andreas Schwab @ 2002-05-06 7:57 UTC (permalink / raw) To: Mark Mitchell; +Cc: gcc, dewar 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." ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release 2002-05-06 7:57 ` Andreas Schwab @ 2002-05-06 15:16 ` Mark Mitchell 2002-05-07 1:43 ` Andreas Schwab 0 siblings, 1 reply; 80+ messages in thread From: Mark Mitchell @ 2002-05-06 15:16 UTC (permalink / raw) To: Andreas Schwab; +Cc: gcc, dewar --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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release 2002-05-06 15:16 ` Mark Mitchell @ 2002-05-07 1:43 ` Andreas Schwab 0 siblings, 0 replies; 80+ messages in thread From: Andreas Schwab @ 2002-05-07 1:43 UTC (permalink / raw) To: Mark Mitchell; +Cc: gcc, dewar 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." ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release @ 2002-04-15 15:06 Richard Kenner 0 siblings, 0 replies; 80+ messages in thread From: Richard Kenner @ 2002-04-15 15:06 UTC (permalink / raw) To: mark; +Cc: gcc 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. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release @ 2002-04-14 10:34 Robert Dewar 0 siblings, 0 replies; 80+ messages in thread From: Robert Dewar @ 2002-04-14 10:34 UTC (permalink / raw) To: hjl, toon; +Cc: gcc, mark, neil 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. ^ permalink raw reply [flat|nested] 80+ messages in thread
* GCC 3.1 Release @ 2002-04-12 18:51 Mark Mitchell 2002-04-13 2:21 ` Neil Booth ` (3 more replies) 0 siblings, 4 replies; 80+ messages in thread From: Mark Mitchell @ 2002-04-12 18:51 UTC (permalink / raw) To: gcc 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release 2002-04-12 18:51 Mark Mitchell @ 2002-04-13 2:21 ` Neil Booth 2002-04-13 7:50 ` Toon Moene 2002-04-13 13:18 ` Tom Tromey ` (2 subsequent siblings) 3 siblings, 1 reply; 80+ messages in thread From: Neil Booth @ 2002-04-13 2:21 UTC (permalink / raw) To: Mark Mitchell; +Cc: gcc 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. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release 2002-04-13 2:21 ` Neil Booth @ 2002-04-13 7:50 ` Toon Moene 2002-04-13 8:40 ` Tim Prince ` (3 more replies) 0 siblings, 4 replies; 80+ messages in thread From: Toon Moene @ 2002-04-13 7:50 UTC (permalink / raw) To: Neil Booth; +Cc: Mark Mitchell, gcc 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) ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release 2002-04-13 7:50 ` Toon Moene @ 2002-04-13 8:40 ` Tim Prince 2002-04-13 23:07 ` Bryce McKinlay ` (2 subsequent siblings) 3 siblings, 0 replies; 80+ messages in thread From: Tim Prince @ 2002-04-13 8:40 UTC (permalink / raw) To: Toon Moene, Neil Booth; +Cc: Mark Mitchell, gcc 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release 2002-04-13 7:50 ` Toon Moene 2002-04-13 8:40 ` Tim Prince @ 2002-04-13 23:07 ` Bryce McKinlay 2002-04-14 17:04 ` David Edelsohn 2002-04-22 19:44 ` David O'Brien 2002-04-14 1:33 ` H . J . Lu 2002-04-16 17:00 ` Marc Espie 3 siblings, 2 replies; 80+ messages in thread From: Bryce McKinlay @ 2002-04-13 23:07 UTC (permalink / raw) To: Toon Moene; +Cc: Neil Booth, Mark Mitchell, gcc 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. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release 2002-04-13 23:07 ` Bryce McKinlay @ 2002-04-14 17:04 ` David Edelsohn 2002-04-15 17:19 ` David O'Brien 2002-04-22 19:44 ` David O'Brien 1 sibling, 1 reply; 80+ messages in thread From: David Edelsohn @ 2002-04-14 17:04 UTC (permalink / raw) To: Bryce McKinlay; +Cc: Toon Moene, Neil Booth, Mark Mitchell, gcc >>>>> 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release 2002-04-14 17:04 ` David Edelsohn @ 2002-04-15 17:19 ` David O'Brien 2002-04-15 18:02 ` David Edelsohn 2002-04-16 17:06 ` Marc Espie 0 siblings, 2 replies; 80+ messages in thread From: David O'Brien @ 2002-04-15 17:19 UTC (permalink / raw) To: David Edelsohn; +Cc: Bryce McKinlay, Toon Moene, Neil Booth, Mark Mitchell, gcc 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. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release 2002-04-15 17:19 ` David O'Brien @ 2002-04-15 18:02 ` David Edelsohn 2002-04-16 17:06 ` Marc Espie 1 sibling, 0 replies; 80+ messages in thread From: David Edelsohn @ 2002-04-15 18:02 UTC (permalink / raw) To: obrien; +Cc: Bryce McKinlay, Toon Moene, Neil Booth, Mark Mitchell, gcc >>>>> 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release 2002-04-15 17:19 ` David O'Brien 2002-04-15 18:02 ` David Edelsohn @ 2002-04-16 17:06 ` Marc Espie 1 sibling, 0 replies; 80+ messages in thread From: Marc Espie @ 2002-04-16 17:06 UTC (permalink / raw) To: obrien; +Cc: gcc 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. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release 2002-04-13 23:07 ` Bryce McKinlay 2002-04-14 17:04 ` David Edelsohn @ 2002-04-22 19:44 ` David O'Brien 2002-04-22 20:11 ` Bryce McKinlay 2002-04-22 22:25 ` Kaveh R. Ghazi 1 sibling, 2 replies; 80+ messages in thread From: David O'Brien @ 2002-04-22 19:44 UTC (permalink / raw) To: Bryce McKinlay; +Cc: Toon Moene, Neil Booth, Mark Mitchell, gcc 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. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release 2002-04-22 19:44 ` David O'Brien @ 2002-04-22 20:11 ` Bryce McKinlay 2002-04-23 11:04 ` David O'Brien 2002-04-22 22:25 ` Kaveh R. Ghazi 1 sibling, 1 reply; 80+ messages in thread From: Bryce McKinlay @ 2002-04-22 20:11 UTC (permalink / raw) To: obrien; +Cc: Toon Moene, Neil Booth, Mark Mitchell, gcc 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. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release 2002-04-22 20:11 ` Bryce McKinlay @ 2002-04-23 11:04 ` David O'Brien 2002-04-23 16:15 ` Bryce McKinlay 0 siblings, 1 reply; 80+ messages in thread From: David O'Brien @ 2002-04-23 11:04 UTC (permalink / raw) To: Bryce McKinlay; +Cc: Toon Moene, Neil Booth, Mark Mitchell, gcc 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". ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release 2002-04-23 11:04 ` David O'Brien @ 2002-04-23 16:15 ` Bryce McKinlay 0 siblings, 0 replies; 80+ messages in thread From: Bryce McKinlay @ 2002-04-23 16:15 UTC (permalink / raw) To: obrien; +Cc: Toon Moene, Neil Booth, Mark Mitchell, gcc 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. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release 2002-04-22 19:44 ` David O'Brien 2002-04-22 20:11 ` Bryce McKinlay @ 2002-04-22 22:25 ` Kaveh R. Ghazi 1 sibling, 0 replies; 80+ messages in thread From: Kaveh R. Ghazi @ 2002-04-22 22:25 UTC (permalink / raw) To: bryce; +Cc: gcc, mark, neil, toon > 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release 2002-04-13 7:50 ` Toon Moene 2002-04-13 8:40 ` Tim Prince 2002-04-13 23:07 ` Bryce McKinlay @ 2002-04-14 1:33 ` H . J . Lu 2002-04-16 17:00 ` Marc Espie 3 siblings, 0 replies; 80+ messages in thread From: H . J . Lu @ 2002-04-14 1:33 UTC (permalink / raw) To: Toon Moene; +Cc: Neil Booth, Mark Mitchell, gcc 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. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release 2002-04-13 7:50 ` Toon Moene ` (2 preceding siblings ...) 2002-04-14 1:33 ` H . J . Lu @ 2002-04-16 17:00 ` Marc Espie 2002-04-17 2:08 ` Gerald Pfeifer 3 siblings, 1 reply; 80+ messages in thread From: Marc Espie @ 2002-04-16 17:00 UTC (permalink / raw) To: toon; +Cc: gcc 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. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release 2002-04-16 17:00 ` Marc Espie @ 2002-04-17 2:08 ` Gerald Pfeifer 2002-05-17 5:42 ` Marc Espie 0 siblings, 1 reply; 80+ messages in thread From: Gerald Pfeifer @ 2002-04-17 2:08 UTC (permalink / raw) To: Marc Espie; +Cc: toon, gcc 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/ ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release 2002-04-17 2:08 ` Gerald Pfeifer @ 2002-05-17 5:42 ` Marc Espie 2002-05-17 16:19 ` Loren James Rittle 0 siblings, 1 reply; 80+ messages in thread From: Marc Espie @ 2002-05-17 5:42 UTC (permalink / raw) To: Gerald Pfeifer; +Cc: toon, gcc 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. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release 2002-05-17 5:42 ` Marc Espie @ 2002-05-17 16:19 ` Loren James Rittle 2002-05-17 17:07 ` David O'Brien 0 siblings, 1 reply; 80+ messages in thread From: Loren James Rittle @ 2002-05-17 16:19 UTC (permalink / raw) To: gcc; +Cc: espie, obrien 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release 2002-05-17 16:19 ` Loren James Rittle @ 2002-05-17 17:07 ` David O'Brien 2002-05-17 17:08 ` Marc Espie 0 siblings, 1 reply; 80+ messages in thread From: David O'Brien @ 2002-05-17 17:07 UTC (permalink / raw) To: Loren James Rittle; +Cc: gcc, espie 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. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release 2002-05-17 17:07 ` David O'Brien @ 2002-05-17 17:08 ` Marc Espie 0 siblings, 0 replies; 80+ messages in thread From: Marc Espie @ 2002-05-17 17:08 UTC (permalink / raw) To: David O'Brien; +Cc: Loren James Rittle, gcc 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. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release 2002-04-12 18:51 Mark Mitchell 2002-04-13 2:21 ` Neil Booth @ 2002-04-13 13:18 ` Tom Tromey 2002-04-14 6:59 ` Jason Merrill 2002-04-15 12:00 ` Andreas Jaeger 2002-04-15 14:52 ` Geoff Keating 3 siblings, 1 reply; 80+ messages in thread From: Tom Tromey @ 2002-04-13 13:18 UTC (permalink / raw) To: Mark Mitchell; +Cc: gcc >>>>> "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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release 2002-04-13 13:18 ` Tom Tromey @ 2002-04-14 6:59 ` Jason Merrill 2002-04-14 7:25 ` Andreas Jaeger 2002-04-15 10:56 ` Geoff Keating 0 siblings, 2 replies; 80+ messages in thread From: Jason Merrill @ 2002-04-14 6:59 UTC (permalink / raw) To: Geoffrey Keating; +Cc: Mark Mitchell, gcc >>>>> "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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release 2002-04-14 6:59 ` Jason Merrill @ 2002-04-14 7:25 ` Andreas Jaeger 2002-04-14 8:16 ` Jason Merrill 2002-04-15 10:56 ` Geoff Keating 1 sibling, 1 reply; 80+ messages in thread From: Andreas Jaeger @ 2002-04-14 7:25 UTC (permalink / raw) To: Jason Merrill; +Cc: Geoffrey Keating, Mark Mitchell, gcc 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release 2002-04-14 7:25 ` Andreas Jaeger @ 2002-04-14 8:16 ` Jason Merrill 0 siblings, 0 replies; 80+ messages in thread From: Jason Merrill @ 2002-04-14 8:16 UTC (permalink / raw) Cc: gcc >>>>> "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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release 2002-04-14 6:59 ` Jason Merrill 2002-04-14 7:25 ` Andreas Jaeger @ 2002-04-15 10:56 ` Geoff Keating 2002-04-15 11:19 ` H . J . Lu 2002-04-15 11:36 ` Andreas Jaeger 1 sibling, 2 replies; 80+ messages in thread From: Geoff Keating @ 2002-04-15 10:56 UTC (permalink / raw) To: jason; +Cc: mark, gcc > 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> ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release 2002-04-15 10:56 ` Geoff Keating @ 2002-04-15 11:19 ` H . J . Lu 2002-04-16 15:16 ` mark 2002-04-15 11:36 ` Andreas Jaeger 1 sibling, 1 reply; 80+ messages in thread From: H . J . Lu @ 2002-04-15 11:19 UTC (permalink / raw) To: Geoff Keating; +Cc: jason, mark, gcc 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. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release 2002-04-15 11:19 ` H . J . Lu @ 2002-04-16 15:16 ` mark 2002-04-16 15:23 ` H . J . Lu 0 siblings, 1 reply; 80+ messages in thread From: mark @ 2002-04-16 15:16 UTC (permalink / raw) To: H . J . Lu; +Cc: Geoff Keating, jason, mark, gcc 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release 2002-04-16 15:16 ` mark @ 2002-04-16 15:23 ` H . J . Lu 2002-04-17 2:54 ` Andreas Schwab 0 siblings, 1 reply; 80+ messages in thread From: H . J . Lu @ 2002-04-16 15:23 UTC (permalink / raw) To: mark; +Cc: Geoff Keating, jason, mark, gcc 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. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release 2002-04-16 15:23 ` H . J . Lu @ 2002-04-17 2:54 ` Andreas Schwab 0 siblings, 0 replies; 80+ messages in thread From: Andreas Schwab @ 2002-04-17 2:54 UTC (permalink / raw) To: H . J . Lu; +Cc: mark, Geoff Keating, jason, mark, gcc "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." ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release 2002-04-15 10:56 ` Geoff Keating 2002-04-15 11:19 ` H . J . Lu @ 2002-04-15 11:36 ` Andreas Jaeger 2002-04-15 11:37 ` Joe Buck 2002-04-15 13:13 ` Geoff Keating 1 sibling, 2 replies; 80+ messages in thread From: Andreas Jaeger @ 2002-04-15 11:36 UTC (permalink / raw) To: Geoff Keating; +Cc: jason, mark, gcc 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release 2002-04-15 11:36 ` Andreas Jaeger @ 2002-04-15 11:37 ` Joe Buck 2002-04-15 13:13 ` Geoff Keating 1 sibling, 0 replies; 80+ messages in thread From: Joe Buck @ 2002-04-15 11:37 UTC (permalink / raw) To: Andreas Jaeger; +Cc: Geoff Keating, jason, mark, gcc ... > > 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". ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release 2002-04-15 11:36 ` Andreas Jaeger 2002-04-15 11:37 ` Joe Buck @ 2002-04-15 13:13 ` Geoff Keating 1 sibling, 0 replies; 80+ messages in thread From: Geoff Keating @ 2002-04-15 13:13 UTC (permalink / raw) To: aj, Joe Buck; +Cc: jason, mark, gcc > 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> ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release 2002-04-12 18:51 Mark Mitchell 2002-04-13 2:21 ` Neil Booth 2002-04-13 13:18 ` Tom Tromey @ 2002-04-15 12:00 ` Andreas Jaeger 2002-04-15 12:01 ` Mark Mitchell 2002-04-15 14:52 ` Geoff Keating 3 siblings, 1 reply; 80+ messages in thread From: Andreas Jaeger @ 2002-04-15 12:00 UTC (permalink / raw) To: Mark Mitchell; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release 2002-04-15 12:00 ` Andreas Jaeger @ 2002-04-15 12:01 ` Mark Mitchell 2002-04-15 12:13 ` Michael Matz 0 siblings, 1 reply; 80+ messages in thread From: Mark Mitchell @ 2002-04-15 12:01 UTC (permalink / raw) To: Andreas Jaeger; +Cc: gcc --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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release 2002-04-15 12:01 ` Mark Mitchell @ 2002-04-15 12:13 ` Michael Matz 2002-04-15 12:22 ` Mark Mitchell 0 siblings, 1 reply; 80+ messages in thread From: Michael Matz @ 2002-04-15 12:13 UTC (permalink / raw) To: Mark Mitchell; +Cc: Andreas Jaeger, gcc 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. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release 2002-04-15 12:13 ` Michael Matz @ 2002-04-15 12:22 ` Mark Mitchell 0 siblings, 0 replies; 80+ messages in thread From: Mark Mitchell @ 2002-04-15 12:22 UTC (permalink / raw) To: Michael Matz; +Cc: Andreas Jaeger, gcc --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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release 2002-04-12 18:51 Mark Mitchell ` (2 preceding siblings ...) 2002-04-15 12:00 ` Andreas Jaeger @ 2002-04-15 14:52 ` Geoff Keating 2002-04-15 15:01 ` Mark Mitchell 3 siblings, 1 reply; 80+ messages in thread From: Geoff Keating @ 2002-04-15 14:52 UTC (permalink / raw) To: Mark Mitchell; +Cc: gcc 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.] ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release 2002-04-15 14:52 ` Geoff Keating @ 2002-04-15 15:01 ` Mark Mitchell 0 siblings, 0 replies; 80+ messages in thread From: Mark Mitchell @ 2002-04-15 15:01 UTC (permalink / raw) To: Geoff Keating; +Cc: gcc > 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release
@ 2002-04-03 23:20 John David Anglin
0 siblings, 0 replies; 80+ messages in thread
From: John David Anglin @ 2002-04-03 23:20 UTC (permalink / raw)
To: gcc
> 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)
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release
@ 2002-04-03 2:38 Reichelt
2002-04-03 13:21 ` Mark Mitchell
0 siblings, 1 reply; 80+ messages in thread
From: Reichelt @ 2002-04-03 2:38 UTC (permalink / raw)
To: mark, gcc
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
^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release 2002-04-03 2:38 Reichelt @ 2002-04-03 13:21 ` Mark Mitchell 0 siblings, 0 replies; 80+ messages in thread From: Mark Mitchell @ 2002-04-03 13:21 UTC (permalink / raw) To: Reichelt, gcc > A slightly updated list for your convenience: Thanks. I'll process those shortly. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 80+ messages in thread
* GCC 3.1 Release @ 2002-04-02 14:38 Mark Mitchell 2002-04-02 14:47 ` Tom Tromey ` (3 more replies) 0 siblings, 4 replies; 80+ messages in thread From: Mark Mitchell @ 2002-04-02 14:38 UTC (permalink / raw) To: gcc 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release 2002-04-02 14:38 Mark Mitchell @ 2002-04-02 14:47 ` Tom Tromey 2002-04-03 15:06 ` Phil Edwards ` (2 subsequent siblings) 3 siblings, 0 replies; 80+ messages in thread From: Tom Tromey @ 2002-04-02 14:47 UTC (permalink / raw) To: Mark Mitchell; +Cc: gcc >>>>> "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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release 2002-04-02 14:38 Mark Mitchell 2002-04-02 14:47 ` Tom Tromey @ 2002-04-03 15:06 ` Phil Edwards 2002-04-03 16:08 ` Joe Buck 2002-04-06 7:47 ` Jason Merrill 2002-04-10 10:17 ` Janis Johnson 3 siblings, 1 reply; 80+ messages in thread From: Phil Edwards @ 2002-04-03 15:06 UTC (permalink / raw) To: Mark Mitchell; +Cc: gcc, bkoz 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release 2002-04-03 15:06 ` Phil Edwards @ 2002-04-03 16:08 ` Joe Buck 2002-04-03 17:57 ` Phil Edwards 2002-04-04 10:17 ` Mark Mitchell 0 siblings, 2 replies; 80+ messages in thread From: Joe Buck @ 2002-04-03 16:08 UTC (permalink / raw) To: Phil Edwards; +Cc: Mark Mitchell, gcc, bkoz > 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? ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release 2002-04-03 16:08 ` Joe Buck @ 2002-04-03 17:57 ` Phil Edwards 2002-04-04 10:17 ` Mark Mitchell 1 sibling, 0 replies; 80+ messages in thread From: Phil Edwards @ 2002-04-03 17:57 UTC (permalink / raw) To: Joe Buck; +Cc: Mark Mitchell, gcc, bkoz 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release 2002-04-03 16:08 ` Joe Buck 2002-04-03 17:57 ` Phil Edwards @ 2002-04-04 10:17 ` Mark Mitchell 2002-04-09 9:48 ` Joe Buck 1 sibling, 1 reply; 80+ messages in thread From: Mark Mitchell @ 2002-04-04 10:17 UTC (permalink / raw) To: Joe Buck, Phil Edwards; +Cc: gcc, bkoz --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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release 2002-04-04 10:17 ` Mark Mitchell @ 2002-04-09 9:48 ` Joe Buck 2002-04-09 10:44 ` Benjamin Kosnik ` (2 more replies) 0 siblings, 3 replies; 80+ messages in thread From: Joe Buck @ 2002-04-09 9:48 UTC (permalink / raw) To: Mark Mitchell; +Cc: Joe Buck, Phil Edwards, gcc, bkoz > >> 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. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release 2002-04-09 9:48 ` Joe Buck @ 2002-04-09 10:44 ` Benjamin Kosnik 2002-04-09 11:35 ` Gabriel Dos Reis 2002-04-10 2:37 ` Mark Mitchell 2 siblings, 0 replies; 80+ messages in thread From: Benjamin Kosnik @ 2002-04-09 10:44 UTC (permalink / raw) To: Joe Buck; +Cc: Mark Mitchell, Joe Buck, Phil Edwards, gcc > 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release 2002-04-09 9:48 ` Joe Buck 2002-04-09 10:44 ` Benjamin Kosnik @ 2002-04-09 11:35 ` Gabriel Dos Reis 2002-04-10 2:37 ` Mark Mitchell 2 siblings, 0 replies; 80+ messages in thread From: Gabriel Dos Reis @ 2002-04-09 11:35 UTC (permalink / raw) To: Joe Buck; +Cc: Mark Mitchell, Phil Edwards, gcc, bkoz 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release 2002-04-09 9:48 ` Joe Buck 2002-04-09 10:44 ` Benjamin Kosnik 2002-04-09 11:35 ` Gabriel Dos Reis @ 2002-04-10 2:37 ` Mark Mitchell 2002-04-10 7:59 ` Joe Buck 2 siblings, 1 reply; 80+ messages in thread From: Mark Mitchell @ 2002-04-10 2:37 UTC (permalink / raw) To: Joe Buck; +Cc: Phil Edwards, gcc, bkoz > 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release 2002-04-10 2:37 ` Mark Mitchell @ 2002-04-10 7:59 ` Joe Buck 2002-04-10 8:17 ` Gabriel Dos Reis 2002-04-10 10:14 ` Mark Mitchell 0 siblings, 2 replies; 80+ messages in thread From: Joe Buck @ 2002-04-10 7:59 UTC (permalink / raw) To: Mark Mitchell; +Cc: Joe Buck, Phil Edwards, gcc, bkoz > > 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<=. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release 2002-04-10 7:59 ` Joe Buck @ 2002-04-10 8:17 ` Gabriel Dos Reis 2002-04-10 8:22 ` Joe Buck 2002-04-10 10:14 ` Mark Mitchell 1 sibling, 1 reply; 80+ messages in thread From: Gabriel Dos Reis @ 2002-04-10 8:17 UTC (permalink / raw) To: Joe Buck; +Cc: Mark Mitchell, Phil Edwards, gcc, bkoz 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release 2002-04-10 8:17 ` Gabriel Dos Reis @ 2002-04-10 8:22 ` Joe Buck 0 siblings, 0 replies; 80+ messages in thread From: Joe Buck @ 2002-04-10 8:22 UTC (permalink / raw) To: Gabriel Dos Reis; +Cc: Joe Buck, Mark Mitchell, Phil Edwards, gcc, bkoz 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. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release 2002-04-10 7:59 ` Joe Buck 2002-04-10 8:17 ` Gabriel Dos Reis @ 2002-04-10 10:14 ` Mark Mitchell 2002-04-10 11:39 ` Benjamin Kosnik 2002-04-15 17:51 ` Gabriel Dos Reis 1 sibling, 2 replies; 80+ messages in thread From: Mark Mitchell @ 2002-04-10 10:14 UTC (permalink / raw) To: Joe Buck; +Cc: Phil Edwards, gcc, bkoz, gdr --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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release 2002-04-10 10:14 ` Mark Mitchell @ 2002-04-10 11:39 ` Benjamin Kosnik 2002-04-10 11:47 ` Paolo Carlini 2002-04-15 17:51 ` Gabriel Dos Reis 1 sibling, 1 reply; 80+ messages in thread From: Benjamin Kosnik @ 2002-04-10 11:39 UTC (permalink / raw) To: Mark Mitchell; +Cc: Joe Buck, Phil Edwards, gcc, gdr > 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release 2002-04-10 11:39 ` Benjamin Kosnik @ 2002-04-10 11:47 ` Paolo Carlini [not found] ` <flwuvfqrme.fsf@jambon.cmla.ens-cachan.fr> 0 siblings, 1 reply; 80+ messages in thread From: Paolo Carlini @ 2002-04-10 11:47 UTC (permalink / raw) To: Benjamin Kosnik; +Cc: Mark Mitchell, Joe Buck, Phil Edwards, gcc, gdr 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. ^ permalink raw reply [flat|nested] 80+ messages in thread
[parent not found: <flwuvfqrme.fsf@jambon.cmla.ens-cachan.fr>]
* Re: GCC 3.1 Release [not found] ` <flwuvfqrme.fsf@jambon.cmla.ens-cachan.fr> @ 2002-04-12 5:12 ` Paolo Carlini 2002-04-10 13:01 ` Gabriel Dos Reis 0 siblings, 1 reply; 80+ messages in thread From: Paolo Carlini @ 2002-04-12 5:12 UTC (permalink / raw) To: Gabriel Dos Reis; +Cc: gcc 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. ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release 2002-04-12 5:12 ` Paolo Carlini @ 2002-04-10 13:01 ` Gabriel Dos Reis 2002-04-11 6:02 ` Joe Buck 0 siblings, 1 reply; 80+ messages in thread From: Gabriel Dos Reis @ 2002-04-10 13:01 UTC (permalink / raw) To: Paolo Carlini; +Cc: Gabriel Dos Reis, gcc 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release 2002-04-10 13:01 ` Gabriel Dos Reis @ 2002-04-11 6:02 ` Joe Buck 2002-04-11 14:58 ` Gabriel Dos Reis 0 siblings, 1 reply; 80+ messages in thread From: Joe Buck @ 2002-04-11 6:02 UTC (permalink / raw) To: Gabriel Dos Reis; +Cc: Paolo Carlini, Gabriel Dos Reis, gcc 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? ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release 2002-04-11 6:02 ` Joe Buck @ 2002-04-11 14:58 ` Gabriel Dos Reis 0 siblings, 0 replies; 80+ messages in thread From: Gabriel Dos Reis @ 2002-04-11 14:58 UTC (permalink / raw) To: Joe Buck; +Cc: Gabriel Dos Reis, Paolo Carlini, gcc 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release 2002-04-10 10:14 ` Mark Mitchell 2002-04-10 11:39 ` Benjamin Kosnik @ 2002-04-15 17:51 ` Gabriel Dos Reis 2002-04-15 19:36 ` Gabriel Dos Reis 2002-04-15 19:43 ` Mark Mitchell 1 sibling, 2 replies; 80+ messages in thread From: Gabriel Dos Reis @ 2002-04-15 17:51 UTC (permalink / raw) To: Mark Mitchell; +Cc: Joe Buck, Phil Edwards, gcc, bkoz, libstdc++ 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; + } + ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release 2002-04-15 17:51 ` Gabriel Dos Reis @ 2002-04-15 19:36 ` Gabriel Dos Reis 2002-04-15 19:43 ` Mark Mitchell 1 sibling, 0 replies; 80+ messages in thread From: Gabriel Dos Reis @ 2002-04-15 19:36 UTC (permalink / raw) To: Gabriel Dos Reis Cc: Mark Mitchell, Joe Buck, Phil Edwards, gcc, bkoz, libstdc++ 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release 2002-04-15 17:51 ` Gabriel Dos Reis 2002-04-15 19:36 ` Gabriel Dos Reis @ 2002-04-15 19:43 ` Mark Mitchell 2002-04-15 20:03 ` Gabriel Dos Reis 1 sibling, 1 reply; 80+ messages in thread From: Mark Mitchell @ 2002-04-15 19:43 UTC (permalink / raw) To: Gabriel Dos Reis; +Cc: Joe Buck, Phil Edwards, gcc, bkoz, libstdc++ > 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release 2002-04-15 19:43 ` Mark Mitchell @ 2002-04-15 20:03 ` Gabriel Dos Reis 0 siblings, 0 replies; 80+ messages in thread From: Gabriel Dos Reis @ 2002-04-15 20:03 UTC (permalink / raw) To: Mark Mitchell Cc: Gabriel Dos Reis, Joe Buck, Phil Edwards, gcc, bkoz, libstdc++ 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release 2002-04-02 14:38 Mark Mitchell 2002-04-02 14:47 ` Tom Tromey 2002-04-03 15:06 ` Phil Edwards @ 2002-04-06 7:47 ` Jason Merrill 2002-04-10 10:17 ` Janis Johnson 3 siblings, 0 replies; 80+ messages in thread From: Jason Merrill @ 2002-04-06 7:47 UTC (permalink / raw) To: Mark Mitchell; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release 2002-04-02 14:38 Mark Mitchell ` (2 preceding siblings ...) 2002-04-06 7:47 ` Jason Merrill @ 2002-04-10 10:17 ` Janis Johnson 2002-04-10 10:24 ` Mark Mitchell 2002-04-10 10:35 ` Christian Jönsson 3 siblings, 2 replies; 80+ messages in thread From: Janis Johnson @ 2002-04-10 10:17 UTC (permalink / raw) To: Mark Mitchell; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release 2002-04-10 10:17 ` Janis Johnson @ 2002-04-10 10:24 ` Mark Mitchell 2002-04-10 10:35 ` Christian Jönsson 1 sibling, 0 replies; 80+ messages in thread From: Mark Mitchell @ 2002-04-10 10:24 UTC (permalink / raw) To: Janis Johnson; +Cc: gcc > 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
* Re: GCC 3.1 Release 2002-04-10 10:17 ` Janis Johnson 2002-04-10 10:24 ` Mark Mitchell @ 2002-04-10 10:35 ` Christian Jönsson 1 sibling, 0 replies; 80+ messages in thread From: Christian Jönsson @ 2002-04-10 10:35 UTC (permalink / raw) To: gcc 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 ^ permalink raw reply [flat|nested] 80+ messages in thread
end of thread, other threads:[~2002-05-17 23:38 UTC | newest] Thread overview: 80+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-04-13 13:51 GCC 3.1 Release Robert Dewar -- strict thread matches above, loose matches on Subject: below -- 2002-05-05 11:37 Mark Mitchell 2002-05-05 15:00 ` Florian Weimer 2002-05-06 3:24 ` Andreas Schwab 2002-05-06 7:54 ` Mark Mitchell 2002-05-06 7:57 ` Andreas Schwab 2002-05-06 15:16 ` Mark Mitchell 2002-05-07 1:43 ` Andreas Schwab 2002-04-15 15:06 Richard Kenner 2002-04-14 10:34 Robert Dewar 2002-04-12 18:51 Mark Mitchell 2002-04-13 2:21 ` Neil Booth 2002-04-13 7:50 ` Toon Moene 2002-04-13 8:40 ` Tim Prince 2002-04-13 23:07 ` Bryce McKinlay 2002-04-14 17:04 ` David Edelsohn 2002-04-15 17:19 ` David O'Brien 2002-04-15 18:02 ` David Edelsohn 2002-04-16 17:06 ` Marc Espie 2002-04-22 19:44 ` David O'Brien 2002-04-22 20:11 ` Bryce McKinlay 2002-04-23 11:04 ` David O'Brien 2002-04-23 16:15 ` Bryce McKinlay 2002-04-22 22:25 ` Kaveh R. Ghazi 2002-04-14 1:33 ` H . J . Lu 2002-04-16 17:00 ` Marc Espie 2002-04-17 2:08 ` Gerald Pfeifer 2002-05-17 5:42 ` Marc Espie 2002-05-17 16:19 ` Loren James Rittle 2002-05-17 17:07 ` David O'Brien 2002-05-17 17:08 ` Marc Espie 2002-04-13 13:18 ` Tom Tromey 2002-04-14 6:59 ` Jason Merrill 2002-04-14 7:25 ` Andreas Jaeger 2002-04-14 8:16 ` Jason Merrill 2002-04-15 10:56 ` Geoff Keating 2002-04-15 11:19 ` H . J . Lu 2002-04-16 15:16 ` mark 2002-04-16 15:23 ` H . J . Lu 2002-04-17 2:54 ` Andreas Schwab 2002-04-15 11:36 ` Andreas Jaeger 2002-04-15 11:37 ` Joe Buck 2002-04-15 13:13 ` Geoff Keating 2002-04-15 12:00 ` Andreas Jaeger 2002-04-15 12:01 ` Mark Mitchell 2002-04-15 12:13 ` Michael Matz 2002-04-15 12:22 ` Mark Mitchell 2002-04-15 14:52 ` Geoff Keating 2002-04-15 15:01 ` Mark Mitchell 2002-04-03 23:20 John David Anglin 2002-04-03 2:38 Reichelt 2002-04-03 13:21 ` Mark Mitchell 2002-04-02 14:38 Mark Mitchell 2002-04-02 14:47 ` Tom Tromey 2002-04-03 15:06 ` Phil Edwards 2002-04-03 16:08 ` Joe Buck 2002-04-03 17:57 ` Phil Edwards 2002-04-04 10:17 ` Mark Mitchell 2002-04-09 9:48 ` Joe Buck 2002-04-09 10:44 ` Benjamin Kosnik 2002-04-09 11:35 ` Gabriel Dos Reis 2002-04-10 2:37 ` Mark Mitchell 2002-04-10 7:59 ` Joe Buck 2002-04-10 8:17 ` Gabriel Dos Reis 2002-04-10 8:22 ` Joe Buck 2002-04-10 10:14 ` Mark Mitchell 2002-04-10 11:39 ` Benjamin Kosnik 2002-04-10 11:47 ` Paolo Carlini [not found] ` <flwuvfqrme.fsf@jambon.cmla.ens-cachan.fr> 2002-04-12 5:12 ` Paolo Carlini 2002-04-10 13:01 ` Gabriel Dos Reis 2002-04-11 6:02 ` Joe Buck 2002-04-11 14:58 ` Gabriel Dos Reis 2002-04-15 17:51 ` Gabriel Dos Reis 2002-04-15 19:36 ` Gabriel Dos Reis 2002-04-15 19:43 ` Mark Mitchell 2002-04-15 20:03 ` Gabriel Dos Reis 2002-04-06 7:47 ` Jason Merrill 2002-04-10 10:17 ` Janis Johnson 2002-04-10 10:24 ` Mark Mitchell 2002-04-10 10:35 ` Christian Jönsson
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).