* 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; 101+ 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] 101+ messages in thread
* Re: GCC 3.1 Release 2002-04-02 14:38 GCC 3.1 Release Mark Mitchell @ 2002-04-02 14:47 ` Tom Tromey 2002-04-03 15:06 ` Phil Edwards ` (2 subsequent siblings) 3 siblings, 0 replies; 101+ 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] 101+ messages in thread
* Re: GCC 3.1 Release 2002-04-02 14:38 GCC 3.1 Release 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 ` GCC 3.1 Release Jason Merrill 2002-04-10 10:17 ` Janis Johnson 3 siblings, 1 reply; 101+ 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] 101+ 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; 101+ 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] 101+ 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; 101+ 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] 101+ 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; 101+ 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] 101+ 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; 101+ 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] 101+ 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; 101+ 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] 101+ 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; 101+ 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] 101+ 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; 101+ 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] 101+ 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; 101+ 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] 101+ 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; 101+ 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] 101+ 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; 101+ 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] 101+ 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 ` GCC 3.1 Release Gabriel Dos Reis 1 sibling, 2 replies; 101+ 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] 101+ 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-10 15:44 ` Fixing libstdc++/3628 (was: Re: GCC 3.1 Release) Paolo Carlini 2002-04-15 17:51 ` GCC 3.1 Release Gabriel Dos Reis 1 sibling, 2 replies; 101+ 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] 101+ 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> 2002-04-10 15:44 ` Fixing libstdc++/3628 (was: Re: GCC 3.1 Release) Paolo Carlini 1 sibling, 1 reply; 101+ 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] 101+ 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; 101+ 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] 101+ 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; 101+ 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] 101+ 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; 101+ 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] 101+ 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; 101+ 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] 101+ messages in thread
* Fixing libstdc++/3628 (was: Re: GCC 3.1 Release) 2002-04-10 11:39 ` Benjamin Kosnik 2002-04-10 11:47 ` Paolo Carlini @ 2002-04-10 15:44 ` Paolo Carlini 2002-04-10 15:49 ` Phil Edwards 1 sibling, 1 reply; 101+ messages in thread From: Paolo Carlini @ 2002-04-10 15:44 UTC (permalink / raw) To: Benjamin Kosnik; +Cc: Mark Mitchell, Joe Buck, gcc, gdr Benjamin Kosnik wrote: >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? > Hi all, FWIW, barring a different solution suggested by Gaby, I have already tested with no regressions on i686-pc-linux-gnu the below. It fixes the following testcase, which however, I have'nt integrated yet in testsuite since I'm not sure where it properly belongs: #include <vector> #include <utility> using namespace std::rel_ops; int main() { std::vector<int> v; std::vector<int>::iterator vi; vi != v.begin(); vi > v.begin(); vi <= v.begin(); vi >= v.begin(); } Ciao, Paolo. ////////////////// libstdc++/3628 * include/bits/stl_iterator.h: Add template definitions to avoid the conflict with std::rel_ops !=, >, <=, >= operators. --- stl_iterator.h.~1.19.~ 2002-02-08 08:34:54.000000000 +0100 +++ stl_iterator.h 2002-04-10 21:02:20.000000000 +0200 @@ -645,6 +645,13 @@ 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 @@ -658,18 +665,39 @@ const __normal_iterator<_IteratorR, _Container>& __rhs) { return __rhs < __lhs; } + // 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 __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); } + // 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 !(__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); } + // 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); } + template<typename _Iterator, typename _Container> inline __normal_iterator<_Iterator, _Container> operator+(typename __normal_iterator<_Iterator, _Container>::difference_type __n, ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Fixing libstdc++/3628 (was: Re: GCC 3.1 Release) 2002-04-10 15:44 ` Fixing libstdc++/3628 (was: Re: GCC 3.1 Release) Paolo Carlini @ 2002-04-10 15:49 ` Phil Edwards 2002-04-10 17:29 ` Paolo Carlini 0 siblings, 1 reply; 101+ messages in thread From: Phil Edwards @ 2002-04-10 15:49 UTC (permalink / raw) To: Paolo Carlini; +Cc: Benjamin Kosnik, Mark Mitchell, Joe Buck, gcc, gdr On Thu, Apr 11, 2002 at 12:29:35AM +0200, Paolo Carlini wrote: > > It fixes the following testcase, which however, I have'nt integrated yet in > testsuite since I'm not sure where it properly belongs: How about 20_util/rel_ops.cc ? > libstdc++/3628 > * include/bits/stl_iterator.h: Add template definitions to avoid > the conflict with std::rel_ops !=, >, <=, >= operators. By the way, the changelog entry only gets sent to GNATS if the line reads PR libstdc++/3628 i.e., with the leading "PR " text. I just noticed that none of Benjamin's recent fixes have that text either. Oh well. :-) No easy way to make it work retroactively. 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] 101+ messages in thread
* Re: Fixing libstdc++/3628 (was: Re: GCC 3.1 Release) 2002-04-10 15:49 ` Phil Edwards @ 2002-04-10 17:29 ` Paolo Carlini 2002-04-12 16:10 ` Mark Mitchell 0 siblings, 1 reply; 101+ messages in thread From: Paolo Carlini @ 2002-04-10 17:29 UTC (permalink / raw) To: Phil Edwards; +Cc: Benjamin Kosnik, Mark Mitchell, Joe Buck, gcc, gdr Phil Edwards wrote: >How about 20_util/rel_ops.cc ? > [...] >By the way, the changelog entry only gets sent to GNATS if the line reads > > PR libstdc++/3628 > >i.e., with the leading "PR " text. I just noticed that none of Benjamin's >recent fixes have that text either. Oh well. :-) No easy way to make it >work retroactively. > Thanks for both Phil! I was completely unaware :-( of the required PR at the beginning... Ciao, Paolo. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Fixing libstdc++/3628 (was: Re: GCC 3.1 Release) 2002-04-10 17:29 ` Paolo Carlini @ 2002-04-12 16:10 ` Mark Mitchell 2002-04-12 18:20 ` Paolo Carlini 0 siblings, 1 reply; 101+ messages in thread From: Mark Mitchell @ 2002-04-12 16:10 UTC (permalink / raw) To: Paolo Carlini, Phil Edwards; +Cc: Benjamin Kosnik, Joe Buck, gcc, gdr --On Thursday, April 11, 2002 12:48:45 AM +0200 Paolo Carlini <pcarlini@unitus.it> wrote: > Phil Edwards wrote: > >> How about 20_util/rel_ops.cc ? >> > [...] > >> By the way, the changelog entry only gets sent to GNATS if the line reads >> >> PR libstdc++/3628 >> >> i.e., with the leading "PR " text. I just noticed that none of >> Benjamin's recent fixes have that text either. Oh well. :-) No easy >> way to make it work retroactively. Gaby, I understand your objection here, I think. You're saying that since we're creating these new operators in namespace std, saying: "using std::operator==" will pull in more things that it should. Can a conforming program detect that difference? I agree that putting __normal_iterator and friends into a separate namespace would be a cleaner solution. It sounds pretty invasive, though. Do you think it's practical to do that quickly? If not, I'd suggest we go with Joe/Paolo's patch, and then file a PR about the "using std::operator==" issue. I think that would probably be a step forward. Remember that sometimes we can't do everything we'd like to, but we still want to make progress... What are your thoughts on that? Thanks, -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: Fixing libstdc++/3628 (was: Re: GCC 3.1 Release) 2002-04-12 16:10 ` Mark Mitchell @ 2002-04-12 18:20 ` Paolo Carlini 0 siblings, 0 replies; 101+ messages in thread From: Paolo Carlini @ 2002-04-12 18:20 UTC (permalink / raw) To: Mark Mitchell; +Cc: Phil Edwards, Benjamin Kosnik, Joe Buck, gcc, gdr Hi all, for concreteness, the below (tested i686-pc-linux-gnu) is the complete non-invasive proposal. Ciao, Paolo. //////////// 2002-04-13 Joe Buck <joe.buck@synopsys.com> Paolo Carlini <pcarlini@unitus.it> PR libstdc++/3628 * include/bits/stl_iterator.h (class __normal_iterator): Add template definitions to avoid the conflict with std::rel_ops !=, >, <=, and >= operators. * testsuite/20_util/rel_ops.cc: New tests. diff -prN libstdc++-v3-orig/include/bits/stl_iterator.h libstdc++-v3/include/bits/stl_iterator.h *** libstdc++-v3-orig/include/bits/stl_iterator.h Fri Feb 8 08:34:54 2002 --- libstdc++-v3/include/bits/stl_iterator.h Sat Apr 13 00:53:54 2002 *************** namespace std *** 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 *************** namespace std *** 658,675 **** --- 665,703 ---- const __normal_iterator<_IteratorR, _Container>& __rhs) { return __rhs < __lhs; } + // 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 __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); } + // 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 !(__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); } + // 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); } + template<typename _Iterator, typename _Container> inline __normal_iterator<_Iterator, _Container> operator+(typename __normal_iterator<_Iterator, _Container>::difference_type __n, diff -prN libstdc++-v3-orig/testsuite/20_util/rel_ops.cc libstdc++-v3/testsuite/20_util/rel_ops.cc *** libstdc++-v3-orig/testsuite/20_util/rel_ops.cc Thu Jan 1 01:00:00 1970 --- libstdc++-v3/testsuite/20_util/rel_ops.cc Sat Apr 13 01:16:55 2002 *************** *** 0 **** --- 1,44 ---- + // 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] 101+ 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; 101+ 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] 101+ messages in thread
* Re: GCC 3.1 Release 2002-04-15 17:51 ` GCC 3.1 Release Gabriel Dos Reis @ 2002-04-15 19:36 ` Gabriel Dos Reis 2002-04-15 19:43 ` Mark Mitchell 1 sibling, 0 replies; 101+ 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] 101+ messages in thread
* Re: GCC 3.1 Release 2002-04-15 17:51 ` GCC 3.1 Release 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; 101+ 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] 101+ messages in thread
* Re: GCC 3.1 Release 2002-04-15 19:43 ` Mark Mitchell @ 2002-04-15 20:03 ` Gabriel Dos Reis 2002-04-16 9:49 ` rel_ops (was Re: GCC 3.1 Release) Joe Buck 0 siblings, 1 reply; 101+ 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] 101+ messages in thread
* rel_ops (was Re: GCC 3.1 Release) 2002-04-15 20:03 ` Gabriel Dos Reis @ 2002-04-16 9:49 ` Joe Buck 2002-04-16 10:04 ` Mark Mitchell 2002-04-16 10:49 ` Gabriel Dos Reis 0 siblings, 2 replies; 101+ messages in thread From: Joe Buck @ 2002-04-16 9:49 UTC (permalink / raw) To: Gabriel Dos Reis Cc: Mark Mitchell, Gabriel Dos Reis, Joe Buck, Phil Edwards, gcc, bkoz, libstdc++ Gaby: > | > I'll apply the same thing to mainline. Branch requires your approval > | > if I understand correctly. Mark: > | Do it. And thank you. And please close the high-priority PR. :-) Gaby: > Done. Thanks. I see that Gaby couldn't resist throwing in an editorial comment attacking std::rel_ops. After the attack, Gaby asks "Can someone remind me what generic programming is about?" I will remind him that the ability to define just operator== and operator< and automatically get correct definitions of the other four, every time, (at least for a large number of cases) is a powerful instance of of generic programming, and this is exactly what generic programming is about. I have a large C++ project that greatly benefits from that feature. Sometimes this is not what's desired (especially when operator== and operator< return some class rather than bool), but that is solved by creating the rel_ops namespace. Library implementers must pay a price for rel_ops, as the standard library has to work even if the user imports the rel_ops namespace, but it is not a large price. I'm not going to ask that the comment be stricken, but I'm not crazy about the idea of a lot of editorial commentary in the headers. The one-line comment I originally had would have been enough for maintainers (who need to be told why there is a seemingly redundant definition). ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: rel_ops (was Re: GCC 3.1 Release) 2002-04-16 9:49 ` rel_ops (was Re: GCC 3.1 Release) Joe Buck @ 2002-04-16 10:04 ` Mark Mitchell 2002-04-16 10:35 ` Joe Buck 2002-04-16 10:53 ` Gabriel Dos Reis 2002-04-16 10:49 ` Gabriel Dos Reis 1 sibling, 2 replies; 101+ messages in thread From: Mark Mitchell @ 2002-04-16 10:04 UTC (permalink / raw) To: Joe Buck, Gabriel Dos Reis; +Cc: Phil Edwards, gcc, bkoz, libstdc++ > I'm not going to ask that the comment be stricken, but I'm not crazy > about the idea of a lot of editorial commentary in the headers. I agree. We don't need editorial comments about languages, operating systems, or other similar things in comments. We really don't even need editorial comments about GCC itself in comments -- although saying "if we had this, then we could clean up that" is sometimes a useful reminder. But, C++ and its runtime library are what they are; it's up to us to implement them as well as we can without judging which features we like and which we don't. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: rel_ops (was Re: GCC 3.1 Release) 2002-04-16 10:04 ` Mark Mitchell @ 2002-04-16 10:35 ` Joe Buck 2002-04-16 10:53 ` Gabriel Dos Reis 1 sibling, 0 replies; 101+ messages in thread From: Joe Buck @ 2002-04-16 10:35 UTC (permalink / raw) To: Mark Mitchell Cc: Joe Buck, Gabriel Dos Reis, Phil Edwards, gcc, bkoz, libstdc++ I wrote: > > I'm not going to ask that the comment be stricken, but I'm not crazy > > about the idea of a lot of editorial commentary in the headers. Mark wrote: > I agree. We don't need editorial comments about languages, operating > systems, or other similar things in comments. Thanks, but I wouldn't want this little dispute take away from my gratitude to Paolo and Gaby for helping me to get this problem resolved. I realize (rather, it has been pointed out to me) that I hadn't said "thank you" yet. Thank you. Having the high-priority bug fixed is so much better than not having it fixed that a comment I don't care for in a header that few will read is a small price to pay. Gaby, sometimes we seem to get on one another's nerves. I'm sorry about that, but I am grateful for all your contributions to GCC. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: rel_ops (was Re: GCC 3.1 Release) 2002-04-16 10:04 ` Mark Mitchell 2002-04-16 10:35 ` Joe Buck @ 2002-04-16 10:53 ` Gabriel Dos Reis 2002-04-16 11:05 ` Mark Mitchell 1 sibling, 1 reply; 101+ messages in thread From: Gabriel Dos Reis @ 2002-04-16 10:53 UTC (permalink / raw) To: Mark Mitchell Cc: Joe Buck, Gabriel Dos Reis, Phil Edwards, gcc, bkoz, libstdc++ Mark Mitchell <mark@codesourcery.com> writes: | > I'm not going to ask that the comment be stricken, but I'm not crazy | > about the idea of a lot of editorial commentary in the headers. | | I agree. Mark, I don't think I were attacking anything in saying that std::rel_ops isn't friendly since it is a *fact* that they tend take over operators that would have been selected otherwise -- they are "isolated" but as soon as they're brought into scope, they tend to things. I'm disappointed that Joe is taking this issue personally. -- Gaby ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: rel_ops (was Re: GCC 3.1 Release) 2002-04-16 10:53 ` Gabriel Dos Reis @ 2002-04-16 11:05 ` Mark Mitchell 0 siblings, 0 replies; 101+ messages in thread From: Mark Mitchell @ 2002-04-16 11:05 UTC (permalink / raw) To: Gabriel Dos Reis; +Cc: Joe Buck, Phil Edwards, gcc, bkoz, libstdc++ --On Tuesday, April 16, 2002 07:49:23 PM +0200 Gabriel Dos Reis <gdr@codesourcery.com> wrote: > Mark Mitchell <mark@codesourcery.com> writes: > >| > I'm not going to ask that the comment be stricken, but I'm not crazy >| > about the idea of a lot of editorial commentary in the headers. >| >| I agree. > > Mark, > > I don't think I were attacking anything in saying that std::rel_ops > isn't friendly since it is a *fact* that they tend take over operators > that would have been selected otherwise -- they are "isolated" but as > soon as they're brought into scope, they tend to things. I should admit that I didn't read the comment. (I still haven't.) I should have before making any comment. Let's not take this any further; everyone's thrilled that the bug is fixed! I'm grateful to Joe for pointing out the problem and proposing a patch, Paolo for developing it further, and you for moving the stuff into namespaces and incorporating the whole bit. Me, I just sit in the middle and watch all you folks work. :-) -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: rel_ops (was Re: GCC 3.1 Release) 2002-04-16 9:49 ` rel_ops (was Re: GCC 3.1 Release) Joe Buck 2002-04-16 10:04 ` Mark Mitchell @ 2002-04-16 10:49 ` Gabriel Dos Reis 2002-04-17 11:56 ` Richard B. Kreckel 1 sibling, 1 reply; 101+ messages in thread From: Gabriel Dos Reis @ 2002-04-16 10:49 UTC (permalink / raw) To: Joe Buck Cc: Gabriel Dos Reis, Mark Mitchell, Phil Edwards, gcc, bkoz, libstdc++ Joe Buck <Joe.Buck@synopsys.com> writes: | Gaby: | > | > I'll apply the same thing to mainline. Branch requires your approval | > | > if I understand correctly. | | Mark: | > | Do it. And thank you. And please close the high-priority PR. :-) | | Gaby: | > Done. Thanks. | | I see that Gaby couldn't resist throwing in an editorial comment attacking | std::rel_ops. Joe, I didn't "attack" std::rel_ops. I simply stated a *fact*: the operators in std::rel_ops are greedy and tend to take precedence over operators that would have been selected, were stg::rel_ops absent. | After the attack, Gaby asks "Can someone remind me what | generic programming is about?" | | I will remind him that the ability to define just operator== and operator< | and automatically get correct definitions of the other four, every time, | (at least for a large number of cases) is a powerful instance of of | generic programming, and this is exactly what generic programming is | about. I appreciate your answer, but it doesn't answer my concern and as such doesn't enlighten the point std::rel_ops is serving generic programming here: It causes more trouble than it solves. [...] | I'm not going to ask that the comment be stricken, but I'm not crazy | about the idea of a lot of editorial commentary in the headers. I think you're taking this issue more personally than it should. Qualifying my comments as being attacking std::rel_ops is far too extreme. Am I mistaken to think that the std::rel_ops issue is more about Joe/Gaby than about anything else? -- Gaby ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: rel_ops (was Re: GCC 3.1 Release) 2002-04-16 10:49 ` Gabriel Dos Reis @ 2002-04-17 11:56 ` Richard B. Kreckel 2002-04-17 12:15 ` Joe Buck ` (2 more replies) 0 siblings, 3 replies; 101+ messages in thread From: Richard B. Kreckel @ 2002-04-17 11:56 UTC (permalink / raw) To: Gabriel Dos Reis Cc: Joe Buck, Mark Mitchell, Phil Edwards, gcc, bkoz, libstdc++, Christian Bauer Hi, On 16 Apr 2002, Gabriel Dos Reis wrote: > Joe Buck <Joe.Buck@synopsys.com> writes: > | Gaby: > | > | > I'll apply the same thing to mainline. Branch requires your approval > | > | > if I understand correctly. > | > | Mark: > | > | Do it. And thank you. And please close the high-priority PR. :-) > | > | Gaby: > | > Done. Thanks. > | > | I see that Gaby couldn't resist throwing in an editorial comment attacking > | std::rel_ops. > > Joe, I didn't "attack" std::rel_ops. I simply stated a *fact*: the > operators in std::rel_ops are greedy and tend to take precedence over > operators that would have been selected, were stg::rel_ops absent. Sorry, that beats me. When you overload or specialize any operator> then a templated operator> that would match the same signature should not take precedence, be it in some namespace or not. And it doesn't seem to happen in GCC as far as I can see and it would be a freaking bug if it happened as far as I can tell. Gaby, I have repeatedly asked you to explain the problems you keep mentioning but you never answered. Could someone please enlighten me and provide a scenario where the operators in std::rel_ops take precendence over operators that would have been selected otherwise. Maybe just blind -richy. -- Richard B. Kreckel <Richard.Kreckel@Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/> ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: rel_ops (was Re: GCC 3.1 Release) 2002-04-17 11:56 ` Richard B. Kreckel @ 2002-04-17 12:15 ` Joe Buck 2002-04-19 12:54 ` Gabriel Dos Reis 2002-04-17 12:16 ` Phil Edwards 2002-04-19 12:47 ` Gabriel Dos Reis 2 siblings, 1 reply; 101+ messages in thread From: Joe Buck @ 2002-04-17 12:15 UTC (permalink / raw) To: Richard.Kreckel Cc: Gabriel Dos Reis, Joe Buck, Mark Mitchell, Phil Edwards, gcc, bkoz, libstdc++, Christian Bauer Richard Kreckel writes: > Sorry, that beats me. When you overload or specialize any operator> then > a templated operator> that would match the same signature should not take > precedence, be it in some namespace or not. And it doesn't seem to happen > in GCC as far as I can see and it would be a freaking bug if it happened > as far as I can tell. Gaby, I have repeatedly asked you to explain the > problems you keep mentioning but you never answered. Could someone please > enlighten me and provide a scenario where the operators in std::rel_ops > take precendence over operators that would have been selected otherwise. Before the bug was fixed, the problem was not that std::rel_ops::operator!= took precedence over the != for __normal_iterator, it was that neither one took precedence (there was an ambiguity). This meant that some valid programs failed to compile. The bug is now fixed for 3.1, so let's not fight about it any more. Users of 3.0.4 might have some difficulties if they have programs that say using std::rel_ops; and then use vector iterators. A workaround is to change code that uses != on iterators from something like iter != vec.end() to !(iter == vec.end()) for 3.0.x if you see a compilation failure. This will not be needed for 3.1. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: rel_ops (was Re: GCC 3.1 Release) 2002-04-17 12:15 ` Joe Buck @ 2002-04-19 12:54 ` Gabriel Dos Reis 0 siblings, 0 replies; 101+ messages in thread From: Gabriel Dos Reis @ 2002-04-19 12:54 UTC (permalink / raw) To: Joe Buck Cc: Richard.Kreckel, Gabriel Dos Reis, Mark Mitchell, Phil Edwards, gcc, bkoz, libstdc++, Christian Bauer Joe Buck <Joe.Buck@synopsys.com> writes: | Richard Kreckel writes: | > Sorry, that beats me. When you overload or specialize any operator> then | > a templated operator> that would match the same signature should not take | > precedence, be it in some namespace or not. And it doesn't seem to happen | > in GCC as far as I can see and it would be a freaking bug if it happened | > as far as I can tell. Gaby, I have repeatedly asked you to explain the | > problems you keep mentioning but you never answered. Could someone please | > enlighten me and provide a scenario where the operators in std::rel_ops | > take precendence over operators that would have been selected otherwise. | | Before the bug was fixed, the problem was not that std::rel_ops::operator!= | took precedence over the != for __normal_iterator, it was that neither one | took precedence (there was an ambiguity). std::rel_ops::operator!= can take precedence in specific cases (not for __normal_iterator). See the example I just posted. -- Gaby ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: rel_ops (was Re: GCC 3.1 Release) 2002-04-17 11:56 ` Richard B. Kreckel 2002-04-17 12:15 ` Joe Buck @ 2002-04-17 12:16 ` Phil Edwards 2002-04-17 16:54 ` Joe Buck 2002-04-19 12:59 ` Gabriel Dos Reis 2002-04-19 12:47 ` Gabriel Dos Reis 2 siblings, 2 replies; 101+ messages in thread From: Phil Edwards @ 2002-04-17 12:16 UTC (permalink / raw) To: Richard.Kreckel Cc: Gabriel Dos Reis, Joe Buck, Mark Mitchell, gcc, bkoz, libstdc++, Christian Bauer On Wed, Apr 17, 2002 at 08:52:50PM +0200, Richard B. Kreckel wrote: > Could someone please > enlighten me and provide a scenario where the operators in std::rel_ops > take precendence over operators that would have been selected otherwise. The problem is not that they take precendence /over/ other operators, it's that they don't allow other operators to take precedence over themselves. They become equal candidates. Then the compiler pukes out due to the ambiguity. (To see this, use the rel_ops operators with vector or string iterators, /without/ the recently applied patch.) At least, that seems to be the problem. Gaby? In a perfect world (or at least in mine *grin*), we could tell the compiler that, in the case of ambiguous matches, check to see if one of the functions is in the std::rel_ops namespace, and if so, temporarily discard that one, and see if the ambiguity remains. (Blue-sky idea, probably flaky.) 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] 101+ messages in thread
* Re: rel_ops (was Re: GCC 3.1 Release) 2002-04-17 12:16 ` Phil Edwards @ 2002-04-17 16:54 ` Joe Buck 2002-04-19 13:19 ` Gabriel Dos Reis 2002-04-19 12:59 ` Gabriel Dos Reis 1 sibling, 1 reply; 101+ messages in thread From: Joe Buck @ 2002-04-17 16:54 UTC (permalink / raw) To: Phil Edwards Cc: Richard.Kreckel, Gabriel Dos Reis, Joe Buck, Mark Mitchell, gcc, bkoz, libstdc++, Christian Bauer Phil writes: > In a perfect world (or at least in mine *grin*), we could tell the compiler > that, in the case of ambiguous matches, check to see if one of the functions > is in the std::rel_ops namespace, and if so, temporarily discard that one, > and see if the ambiguity remains. (Blue-sky idea, probably flaky.) Such a trick, I believe, would conflict with the ISO standard, though I suppose it could be considered an extension. But no matter, it isn't needed. I don't believe that it is difficult to avoid conflicts with std::rel_ops. To review this once more: std::rel_ops defines things like template <class _Tp> inline bool operator!=(const _Tp& __x, const _Tp& __y) { return !(__x == __y); } The things to note about this definition are: 1) it is completely general (seen by many as a bad thing, and in fact it would be a bad thing if it weren't confined to its own namespace; the user should choose to use it or not) 2) the types of both arguments are constrained to be the same. Point #2 and the rules of C++ guarantee that any more-specific operator!= definition will always be preferred to this one guarantee that there will never be an ambiguity between this definition and any user definition of operator!= that uses the same type for both arguments. Conflicts will only occur if the user definition (or more specific definition in the system library) permits the arguments to be of different types but allows them to be of the same type. If this happens, then it is possible that, for a call to operator!= with two arguments that are of exactly the same type, the two definitions of operator!= will be seen as equal cost, and neither will be seen as a specialization of the other, so the compiler will report an ambiguity. The way to solve it is to add a third definition that will be seen by the compiler as more specific than either of the alternatives. Generally speaking, this will be a symmetric form of the user definition. In the particular case that we just fixed, the problem was with the following definition: 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(); } Ambiguities will arise where we generate a match that uses the same value for _IteratorL and _IteratorR. For this case, both templates generate exact matches, and neither covers a strict subset of the other's range of applicability. The trick of adding a third tie-breaker, in this case 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(); } applies in all such cases. The above template always wins when both it and the rel_ops template are exact matches. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: rel_ops (was Re: GCC 3.1 Release) 2002-04-17 16:54 ` Joe Buck @ 2002-04-19 13:19 ` Gabriel Dos Reis 2002-04-19 15:05 ` Joe Buck 0 siblings, 1 reply; 101+ messages in thread From: Gabriel Dos Reis @ 2002-04-19 13:19 UTC (permalink / raw) To: Joe Buck Cc: Phil Edwards, Richard.Kreckel, Gabriel Dos Reis, Mark Mitchell, gcc, bkoz, libstdc++, Christian Bauer Joe Buck <Joe.Buck@synopsys.com> writes: [...] | 2) the types of both arguments are constrained to be the same. | | Point #2 and the rules of C++ guarantee that any more-specific operator!= | definition will always be preferred to this one guarantee that there will | never be an ambiguity between this definition and any user definition of | operator!= that uses the same type for both arguments. With an appropriate definition of "more-specific", the code I just sent is a counterexample to the above statement :-) | Conflicts will only occur if the user definition (or more specific | definition in the system library) permits the arguments to be of different | types but allows them to be of the same type. If this happens, then it is | possible that, for a call to operator!= with two arguments that are of | exactly the same type, the two definitions of operator!= will be seen as | equal cost, and neither will be seen as a specialization of the other, | so the compiler will report an ambiguity. Not always. Sometimes, it will take the std::rel_ops version because it provides a "best match" (according to the standard). | The way to solve it is to add a third definition that will be seen by | the compiler as more specific than either of the alternatives. Actually, this might not be always practical. -- Gaby ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: rel_ops (was Re: GCC 3.1 Release) 2002-04-19 13:19 ` Gabriel Dos Reis @ 2002-04-19 15:05 ` Joe Buck 0 siblings, 0 replies; 101+ messages in thread From: Joe Buck @ 2002-04-19 15:05 UTC (permalink / raw) To: Gabriel Dos Reis Cc: Joe Buck, Phil Edwards, Richard.Kreckel, Gabriel Dos Reis, Mark Mitchell, gcc, bkoz, libstdc++, Christian Bauer > | Conflicts will only occur if the user definition (or more specific > | definition in the system library) permits the arguments to be of different > | types but allows them to be of the same type. If this happens, then it is > | possible that, for a call to operator!= with two arguments that are of > | exactly the same type, the two definitions of operator!= will be seen as > | equal cost, and neither will be seen as a specialization of the other, > | so the compiler will report an ambiguity. > > Not always. Sometimes, it will take the std::rel_ops version because > it provides a "best match" (according to the standard). Right. For example, if I define bool operator!=(const foo&, const foo&); and then I have a class bar that derives from foo, the std::rel_ops version will be a better match for bar b1, b2; ... b1 != b2; because the exact template match is better than the standard conversion to the base class. However, anyone who does a using directive to bring in rel_ops is saying that it is OK to define != in terms of ==, so this doesn't matter. The only cases that are problems are those in which neither is preferred. > | The way to solve it is to add a third definition that will be seen by > | the compiler as more specific than either of the alternatives. > > Actually, this might not be always practical. If so, the alternative is to be sure not to use rel_ops. :-) However, since the standard library has to support rel_ops to be correct, at least the standard library implementers need to use such techniques. ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: rel_ops (was Re: GCC 3.1 Release) 2002-04-17 12:16 ` Phil Edwards 2002-04-17 16:54 ` Joe Buck @ 2002-04-19 12:59 ` Gabriel Dos Reis 2002-04-19 14:34 ` Phil Edwards 1 sibling, 1 reply; 101+ messages in thread From: Gabriel Dos Reis @ 2002-04-19 12:59 UTC (permalink / raw) To: Phil Edwards Cc: Richard.Kreckel, Gabriel Dos Reis, Joe Buck, Mark Mitchell, gcc, bkoz, libstdc++, Christian Bauer Phil Edwards <phil@jaj.com> writes: | On Wed, Apr 17, 2002 at 08:52:50PM +0200, Richard B. Kreckel wrote: | > Could someone please | > enlighten me and provide a scenario where the operators in std::rel_ops | > take precendence over operators that would have been selected otherwise. | | The problem is not that they take precendence /over/ other operators, it's | that they don't allow other operators to take precedence over themselves. :-) You're right. But it is also true that in some cases, they do take precedence over some operators. The crux being that sometimes, the standard conversion derived -> base is attempted only when there is no match that would could solve the overload; and it such cases, things break. See the example I just posted. | They become equal candidates. Then the compiler pukes out due to the | ambiguity. (To see this, use the rel_ops operators with vector or string | iterators, /without/ the recently applied patch.) | | At least, that seems to be the problem. Gaby? Yes, in the specific case of __normal_iterator, that is what happens. | In a perfect world (or at least in mine *grin*), we could tell the compiler | that, in the case of ambiguous matches, check to see if one of the functions | is in the std::rel_ops namespace, and if so, temporarily discard that one, | and see if the ambiguity remains. (Blue-sky idea, probably flaky.) That isn't conforming and I'm not sure I would like to implement that feature, I might be definitely labelled "anti-rel-ops" ;-) [ Phil, I'm getting mailer-daemon notices telling me that your address isn't valid. What is up? ] -- Gaby ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: rel_ops (was Re: GCC 3.1 Release) 2002-04-19 12:59 ` Gabriel Dos Reis @ 2002-04-19 14:34 ` Phil Edwards 0 siblings, 0 replies; 101+ messages in thread From: Phil Edwards @ 2002-04-19 14:34 UTC (permalink / raw) To: Gabriel Dos Reis Cc: Richard.Kreckel, Joe Buck, Mark Mitchell, gcc, bkoz, libstdc++, Christian Bauer On Fri, Apr 19, 2002 at 09:54:02PM +0200, Gabriel Dos Reis wrote: > Phil Edwards <phil@jaj.com> writes: > > | In a perfect world (or at least in mine *grin*), we could tell the compiler > | that, in the case of ambiguous matches, check to see if one of the functions > | is in the std::rel_ops namespace, and if so, temporarily discard that one, > | and see if the ambiguity remains. (Blue-sky idea, probably flaky.) > > That isn't conforming and I'm not sure I would like to implement that > feature, I might be definitely labelled "anti-rel-ops" ;-) Oh, it's definitely nonconforming, but most of my ideas for extensions are nonconforming. :-) > [ Phil, I'm getting mailer-daemon notices telling me that your address > isn't valid. What is up? ] There was some network flakiness earlier today. Things should be normal again. (Note that it's no longer pedwards@, but phil@.) 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] 101+ messages in thread
* Re: rel_ops (was Re: GCC 3.1 Release) 2002-04-17 11:56 ` Richard B. Kreckel 2002-04-17 12:15 ` Joe Buck 2002-04-17 12:16 ` Phil Edwards @ 2002-04-19 12:47 ` Gabriel Dos Reis 2 siblings, 0 replies; 101+ messages in thread From: Gabriel Dos Reis @ 2002-04-19 12:47 UTC (permalink / raw) To: Richard.Kreckel Cc: Gabriel Dos Reis, Joe Buck, Mark Mitchell, Phil Edwards, gcc, bkoz, libstdc++, Christian Bauer "Richard B. Kreckel" <kreckel@ginac.de> writes: | Hi, | | On 16 Apr 2002, Gabriel Dos Reis wrote: | > Joe Buck <Joe.Buck@synopsys.com> writes: | > | Gaby: | > | > | > I'll apply the same thing to mainline. Branch requires your approval | > | > | > if I understand correctly. | > | | > | Mark: | > | > | Do it. And thank you. And please close the high-priority PR. :-) | > | | > | Gaby: | > | > Done. Thanks. | > | | > | I see that Gaby couldn't resist throwing in an editorial comment attacking | > | std::rel_ops. | > | > Joe, I didn't "attack" std::rel_ops. I simply stated a *fact*: the | > operators in std::rel_ops are greedy and tend to take precedence over ^^^^ | > operators that would have been selected, were stg::rel_ops absent. | | Sorry, that beats me. When you overload or specialize any operator> then | a templated operator> that would match the same signature should not take | precedence, be it in some namespace or not. And it doesn't seem to happen | in GCC as far as I can see and it would be a freaking bug if it happened | as far as I can tell. Gaby, I have repeatedly asked you to explain the | problems you keep mentioning but you never answered. The keyword here is *tend*. Now, you asked for a testcase, and it is easy to produce one, so here we are (and I to think I provided one in the past). Consider the following struct X { // some stuff }; bool operator!=(const X&, const X&); struct X : Y { // add some customization, but essential the same as X. }; // no operator== for 'Y's, as they're essentially the same. In absence of std::rel_ops::operator!=, the the above operator will be preferred. But as soon as, std::rel_ops_operator!= is in scope, things break. Just compile the following and see what happens. #include <utility> #include <iostream> struct X { }; struct Y : X { }; bool operator!=(const X&, const X&) { std::cout << "::operator!=(const X&, const X&)\n"; return false; } void f() { X() != X(); } void g() { using namespace std::rel_ops; Y() != Y(); } int main() { f(); g(); } In Joe's example, both operators were considered equal. In the above example std::rel_ops::operator!= takes precedence. Hence my word "tend". | Could someone please | enlighten me and provide a scenario where the operators in std::rel_ops | take precendence over operators that would have been selected otherwise. See above. -- Gaby ^ permalink raw reply [flat|nested] 101+ messages in thread
* Re: GCC 3.1 Release 2002-04-02 14:38 GCC 3.1 Release 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; 101+ 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] 101+ messages in thread
* Re: GCC 3.1 Release 2002-04-02 14:38 GCC 3.1 Release Mark Mitchell ` (2 preceding siblings ...) 2002-04-06 7:47 ` GCC 3.1 Release 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; 101+ 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] 101+ 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; 101+ 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] 101+ 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; 101+ 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] 101+ 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; 101+ 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] 101+ 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; 101+ 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] 101+ messages in thread
* Re: GCC 3.1 Release
@ 2002-04-03 23:20 John David Anglin
0 siblings, 0 replies; 101+ 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] 101+ 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; 101+ 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] 101+ 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; 101+ 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] 101+ 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; 101+ 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] 101+ 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; 101+ 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] 101+ 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; 101+ 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] 101+ 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; 101+ 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] 101+ 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; 101+ 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] 101+ 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; 101+ 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] 101+ 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; 101+ 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] 101+ 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; 101+ 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] 101+ 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; 101+ 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] 101+ 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; 101+ 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] 101+ 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; 101+ 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] 101+ 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; 101+ 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] 101+ 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; 101+ 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] 101+ 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; 101+ 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] 101+ 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; 101+ 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] 101+ 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; 101+ 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] 101+ 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; 101+ 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] 101+ 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; 101+ 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] 101+ 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; 101+ 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] 101+ 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; 101+ 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] 101+ 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; 101+ 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] 101+ 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; 101+ 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] 101+ 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; 101+ 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] 101+ 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; 101+ 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] 101+ 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; 101+ 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] 101+ 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; 101+ 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] 101+ 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; 101+ 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] 101+ 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; 101+ 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] 101+ 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; 101+ 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] 101+ 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; 101+ 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] 101+ 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; 101+ 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] 101+ 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; 101+ 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] 101+ 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; 101+ 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] 101+ 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; 101+ 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] 101+ 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; 101+ 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] 101+ 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; 101+ 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] 101+ 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; 101+ 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] 101+ messages in thread
* Re: GCC 3.1 Release
@ 2002-04-13 13:51 Robert Dewar
0 siblings, 0 replies; 101+ 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] 101+ messages in thread
* Re: GCC 3.1 Release @ 2002-04-14 10:34 Robert Dewar 0 siblings, 0 replies; 101+ 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] 101+ messages in thread
* Re: GCC 3.1 Release @ 2002-04-15 15:06 Richard Kenner 0 siblings, 0 replies; 101+ 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] 101+ 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; 101+ 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] 101+ 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; 101+ 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] 101+ 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; 101+ 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] 101+ 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; 101+ 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] 101+ 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; 101+ 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] 101+ 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; 101+ 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] 101+ 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; 101+ 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] 101+ messages in thread
end of thread, other threads:[~2002-05-17 23:38 UTC | newest] Thread overview: 101+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-04-02 14:38 GCC 3.1 Release 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-10 15:44 ` Fixing libstdc++/3628 (was: Re: GCC 3.1 Release) Paolo Carlini 2002-04-10 15:49 ` Phil Edwards 2002-04-10 17:29 ` Paolo Carlini 2002-04-12 16:10 ` Mark Mitchell 2002-04-12 18:20 ` Paolo Carlini 2002-04-15 17:51 ` GCC 3.1 Release 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-16 9:49 ` rel_ops (was Re: GCC 3.1 Release) Joe Buck 2002-04-16 10:04 ` Mark Mitchell 2002-04-16 10:35 ` Joe Buck 2002-04-16 10:53 ` Gabriel Dos Reis 2002-04-16 11:05 ` Mark Mitchell 2002-04-16 10:49 ` Gabriel Dos Reis 2002-04-17 11:56 ` Richard B. Kreckel 2002-04-17 12:15 ` Joe Buck 2002-04-19 12:54 ` Gabriel Dos Reis 2002-04-17 12:16 ` Phil Edwards 2002-04-17 16:54 ` Joe Buck 2002-04-19 13:19 ` Gabriel Dos Reis 2002-04-19 15:05 ` Joe Buck 2002-04-19 12:59 ` Gabriel Dos Reis 2002-04-19 14:34 ` Phil Edwards 2002-04-19 12:47 ` Gabriel Dos Reis 2002-04-06 7:47 ` GCC 3.1 Release Jason Merrill 2002-04-10 10:17 ` Janis Johnson 2002-04-10 10:24 ` Mark Mitchell 2002-04-10 10:35 ` Christian Jönsson 2002-04-03 2:38 Reichelt 2002-04-03 13:21 ` Mark Mitchell 2002-04-03 23:20 John David Anglin 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-13 13:51 Robert Dewar 2002-04-14 10:34 Robert Dewar 2002-04-15 15:06 Richard Kenner 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
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).