GCC 3.1 Release

GCC 3.1 Release

[Mark Mitchell]

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

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

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

Thanks,

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

Re: GCC 3.1 Release

[Tom Tromey]

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

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

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

Tom

Re: GCC 3.1 Release

[Phil Edwards]

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

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


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

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

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

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


Phil

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

Re: GCC 3.1 Release

[Joe Buck]

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

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

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

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

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

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

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

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

Re: GCC 3.1 Release

[Phil Edwards]

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

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


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

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

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


Phil

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

Re: GCC 3.1 Release

[Mark Mitchell]

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

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

Agreed, I've downgraded it.

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

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

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

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

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

Thanks,

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

Re: GCC 3.1 Release

[Jason Merrill]

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

Jason

Re: GCC 3.1 Release

[Joe Buck]

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

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

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

Re: GCC 3.1 Release

[Benjamin Kosnik]

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

Enough talk. Let's see the patch.

:)

-benjamin

Re: GCC 3.1 Release

[Gabriel Dos Reis]

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

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

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

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

Huh?!?

-- Gaby

Re: GCC 3.1 Release

[Mark Mitchell]

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

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

Thanks,

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

Re: GCC 3.1 Release

[Joe Buck]

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

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

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

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

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

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

Re: GCC 3.1 Release

[Gabriel Dos Reis]

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

[...]

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

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

-- Gaby

Re: GCC 3.1 Release

[Joe Buck]

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

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

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

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

Re: GCC 3.1 Release

[Mark Mitchell]

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

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

OK, I understand your situtation.

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

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

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

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

Re: GCC 3.1 Release

[Janis Johnson]

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

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

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

Janis

Re: GCC 3.1 Release

[Mark Mitchell]

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

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

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

OK, I've updated the bug list.

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

Re: GCC 3.1 Release

[Christian Jönsson]

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

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

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

Cheers,

/ChJ

Re: GCC 3.1 Release

[Benjamin Kosnik]

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

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

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

-benjamin

Re: GCC 3.1 Release

[Paolo Carlini]

Benjamin Kosnik wrote:

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

Ciao, Paolo.

Re: GCC 3.1 Release

[Gabriel Dos Reis]

Paolo Carlini <pcarlini@unitus.it> writes:

[...]

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

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

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

-- Gaby

Fixing libstdc++/3628 (was: Re: GCC 3.1 Release)

[Paolo Carlini]

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,

Re: Fixing libstdc++/3628 (was: Re: GCC 3.1 Release)

[Phil Edwards]

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

Re: Fixing libstdc++/3628 (was: Re: GCC 3.1 Release)

[Paolo Carlini]

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.

Re: GCC 3.1 Release

[Joe Buck]

Gaby writes:

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

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

Re: GCC 3.1 Release

[Gabriel Dos Reis]

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

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

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

-- Gaby

Re: GCC 3.1 Release

[Paolo Carlini]

Gabriel Dos Reis wrote:

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

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

Ciao, Paolo.

Re: Fixing libstdc++/3628 (was: Re: GCC 3.1 Release)

[Mark Mitchell]

--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

Re: Fixing libstdc++/3628 (was: Re: GCC 3.1 Release)

[Paolo Carlini]

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;
+ }

Re: GCC 3.1 Release

[Gabriel Dos Reis]

Mark Mitchell <mark@codesourcery.com> writes:

[...]

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


Mark,

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

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

-- Gaby

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

Re: GCC 3.1 Release

[Gabriel Dos Reis]

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

[...]

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

Done.

-- Gaby

Re: GCC 3.1 Release

[Mark Mitchell]

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

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

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

Re: GCC 3.1 Release

[Gabriel Dos Reis]

Mark Mitchell <mark@codesourcery.com> writes:

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

Done.  Thanks.

-- Gaby

rel_ops (was Re: GCC 3.1 Release)

[Joe Buck]

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).

Re: rel_ops (was Re: GCC 3.1 Release)

[Mark Mitchell]

> 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

Re: rel_ops (was Re: GCC 3.1 Release)

[Joe Buck]

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.

Re: rel_ops (was Re: GCC 3.1 Release)

[Gabriel Dos Reis]

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

Re: rel_ops (was Re: GCC 3.1 Release)

[Gabriel Dos Reis]

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

Re: rel_ops (was Re: GCC 3.1 Release)

[Mark Mitchell]

--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

Re: rel_ops (was Re: GCC 3.1 Release)

[Richard B. Kreckel]

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/>

Re: rel_ops (was Re: GCC 3.1 Release)

[Joe Buck]

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.

Re: rel_ops (was Re: GCC 3.1 Release)

[Phil Edwards]

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

Re: rel_ops (was Re: GCC 3.1 Release)

[Joe Buck]

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.

Re: rel_ops (was Re: GCC 3.1 Release)

[Gabriel Dos Reis]

"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

Re: rel_ops (was Re: GCC 3.1 Release)

[Gabriel Dos Reis]

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

Re: rel_ops (was Re: GCC 3.1 Release)

[Gabriel Dos Reis]

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

Re: rel_ops (was Re: GCC 3.1 Release)

[Gabriel Dos Reis]

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

Re: rel_ops (was Re: GCC 3.1 Release)

[Phil Edwards]

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

Re: rel_ops (was Re: GCC 3.1 Release)

[Joe Buck]

> | 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.

Re: GCC 3.1 Release

[Marc Espie]

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

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

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

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

Re: GCC 3.1 Release

[David O'Brien]

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

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

Re: GCC 3.1 Release

[Loren James Rittle]

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

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

> Does look like a bad idea...

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

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

Regards,
Loren

Re: GCC 3.1 Release

[Marc Espie]

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

Does look like a bad idea...

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

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

Totally unacceptable on slow machines.

Re: GCC 3.1 Release

[Andreas Schwab]

Mark Mitchell <mark@codesourcery.com> writes:

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

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

Andreas.

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

Re: GCC 3.1 Release

[Mark Mitchell]

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

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

That patch is OK.

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

Re: GCC 3.1 Release

[Andreas Schwab]

Mark Mitchell <mark@codesourcery.com> writes:

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

For the line-too-long problem:

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

Andreas.

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

Re: GCC 3.1 Release

[Mark Mitchell]

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

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

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

Thanks,

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

Re: GCC 3.1 Release

[Andreas Schwab]

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

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

They _are_ regressions, because they cause bootstrap failures.

Andreas.

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

Re: GCC 3.1 Release

[Florian Weimer]

Mark Mitchell <mark@codesourcery.com> writes:

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

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

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

b) Include the patch at:

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

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

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

GCC 3.1 Release

[Mark Mitchell]

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

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

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

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

Thanks,

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

Re: GCC 3.1 Release

[Bryce McKinlay]

David O'Brien wrote:

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

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

regards

Bryce.

Re: GCC 3.1 Release

[David O'Brien]

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

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

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

Re: GCC 3.1 Release

[Kaveh R. Ghazi]

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

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

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

Re: GCC 3.1 Release

[Bryce McKinlay]

David O'Brien wrote:

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

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

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

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

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

regards

Bryce.

Re: GCC 3.1 Release

[David O'Brien]

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

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


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

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


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

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

Re: GCC 3.1 Release

[Andreas Schwab]

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

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

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

Andreas.

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

Re: GCC 3.1 Release

[Gerald Pfeifer]

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

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

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

Re: GCC 3.1 Release

[Marc Espie]

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

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

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

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

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

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

Re: GCC 3.1 Release

[Marc Espie]

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

>> Mark Mitchell wrote:-

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

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

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

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

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

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

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

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

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

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

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

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

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

Re: GCC 3.1 Release

[H . J . Lu]

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

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



H.J.

Re: GCC 3.1 Release

[mark]

Hi,

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

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

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

Cheers,

Mark

Re: GCC 3.1 Release

[David Edelsohn]

>>>>> David O'Brien writes:

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

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

David

Re: GCC 3.1 Release

[David O'Brien]

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

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

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

Re: GCC 3.1 Release

[Richard Kenner]

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

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

Re: GCC 3.1 Release

[Mark Mitchell]

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

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

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

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

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

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

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

40%.

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

Small, less than 10%.

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

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

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

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

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

Thanks,

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

Re: GCC 3.1 Release

[Geoff Keating]

Mark Mitchell <mark@codesourcery.com> writes:

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

Hi Mark,

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

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

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

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

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

Re: GCC 3.1 Release

[Geoff Keating]

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

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

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

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

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

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

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

Re: GCC 3.1 Release

[Mark Mitchell]

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

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

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

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

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

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

Re: GCC 3.1 Release

[Michael Matz]

Hi,

On Mon, 15 Apr 2002, Mark Mitchell wrote:

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

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


Ciao,
Michael.

Re: GCC 3.1 Release

[Mark Mitchell]

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

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

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

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

Re: GCC 3.1 Release

[Andreas Jaeger]

Mark Mitchell <mark@codesourcery.com> writes:

[...]

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

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

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

Re: GCC 3.1 Release

[Joe Buck]

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

Andreas writes:

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

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

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

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

Re: GCC 3.1 Release

[Andreas Jaeger]

Geoff Keating <geoffk@geoffk.org> writes:

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

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

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

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

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

Re: GCC 3.1 Release

[H . J . Lu]

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

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

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

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



H.J.

Re: GCC 3.1 Release

[Geoff Keating]

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

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

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

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

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

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

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

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

Re: GCC 3.1 Release

[David Edelsohn]

>>>>> Bryce McKinlay writes:

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

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

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

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

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

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

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

Thanks, David

Re: GCC 3.1 Release

[Robert Dewar]

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

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

Re: GCC 3.1 Release

[Jason Merrill]

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

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

> What do you mean with slave tester?

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

Jason

Re: GCC 3.1 Release

[Andreas Jaeger]

Jason Merrill <jason@redhat.com> writes:

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

What do you mean with slave tester?

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

Re: GCC 3.1 Release

[Jason Merrill]

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

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

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

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

Jason

Re: GCC 3.1 Release

[H . J . Lu]

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

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


H.J.

Re: GCC 3.1 Release

[Bryce McKinlay]

Toon Moene wrote:

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

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

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

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

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

regards

Bryce.

Re: GCC 3.1 Release

[Robert Dewar]

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

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

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

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

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

Re: GCC 3.1 Release

[Tom Tromey]

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

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

Me too.

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

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

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

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

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

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

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

Tom

Re: GCC 3.1 Release

[Tim Prince]

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

-- 
Tim Prince

Re: GCC 3.1 Release

[Toon Moene]

Neil Booth wrote:

> Mark Mitchell wrote:-

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

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

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

I do not have a good solution to that problem.

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

Re: GCC 3.1 Release

[Neil Booth]

Mark Mitchell wrote:-

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

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

Neil.

GCC 3.1 Release

[Mark Mitchell]

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

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

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

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

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

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

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

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

Re: GCC 3.1 Release

[John David Anglin]

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

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

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

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

Re: GCC 3.1 Release

[Mark Mitchell]

> A slightly updated list for your convenience:

Thanks.  I'll process those shortly.

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

Re: GCC 3.1 Release

[Reichelt]

Hello,

Mark Mitchell wrote:

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

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

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

A slightly updated list for your convenience:

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

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


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

Greetings,
Volker Reichelt