Re: C++ FAIL counts and the effect of demangler fix

Re: C++ FAIL counts and the effect of demangler fix

[Michael Elizabeth Chastain]

Hi Andrew,

I was so tired last night that all I could post was the raw numbers.

> BTW, we don't have to get back to anything.  As far as I know, the
> failures are being caused by an unlreased version of GCC that has
> changed its mangler ABI in some incompatible way.

Column #2 is gcc CVS version plus a gdb that *includes* Daniel Berlin's
patch to fix demangler compatibility.  This shows that gdb has other
v3 abi problems besides the changes induced by the demangler.

I don't know what those problems are.  It requires someone to roll
up their sleeves and analyze gdb.log files.  I have time to do one
of these per week.  I'm working in order of "most FAILs first" and
I'm on cplusfuncs.exp.

> It would be nice if the problems were resolved, however, they are _NOT_
> a 5.1 release criteria so not especially high on my radar.  5.1 needs
> to work with real compilers installed on real machines.

I respectfully disagree.  I think gdb 5.1 needs to be ready for gcc 3.0.

Michael Elizabeth Chastain
<chastain@redhat.com>
"love without fear"

Re: C++ FAIL counts and the effect of demangler fix

[Andrew Cagney]

Michael Elizabeth Chastain wrote:

> > It would be nice if the problems were resolved, however, they are _NOT_
> > a 5.1 release criteria so not especially high on my radar.  5.1 needs
> > to work with real compilers installed on real machines.
> 
> I respectfully disagree.  I think gdb 5.1 needs to be ready for gcc 3.0.

I can see why both of you might disagree, however my position stands.
Remember:

	o	I'm not stopping you trying to fix
		all the bugs.  I'm just stopping you
		making that last critical bug/feature
		(minus the next one) the reason to delay
		the release of GDB 5.1.

	o	we're trying to move to a situtation where
		there are more frequent releases of GDB
		(and I'm failing dismally).  Right now
		5.1 is effectivly stuck because it
		needs SPARC/Linux fixed.

	o	I don't want GDB's release schedule in
		someway directly tided to GCC's release
		schedule.

I also posted this decision to the discussion list and at the time I had
ZERO responses.

	Andrew

Re: C++ FAIL counts and the effect of demangler fix

[Per Bothner]

Andrew Cagney <ac131313@cygnus.com> writes:

> 	o	I don't want GDB's release schedule in
> 		someway directly tided to GCC's release
> 		schedule.

I think that is unavoidable, given that Gcc 3 has a new and
incompatible C++ ABI.  It is Bad if the current release of Gdb cannot
debug code produced from the current release of Gcc.  Therefore, Gdb
5.1 should be released before or at the same time as Gcc 3.0 is
released, and it needs to have at least tolerable support for the new
C++ ABI.

Otherwise, we may have to live with the situation (and I don't
actually know what the situation is), but make no mistake: This is
a critical issue for many people, Red Hat included.  (OS distributors
may have a hard time switching to Gcc 3.0 if there are critical Gdb
regressions.)
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

Re: C++ FAIL counts and the effect of demangler fix

[Andrew Cagney]

Per Bothner wrote:
> 
> Andrew Cagney <ac131313@cygnus.com> writes:
> 
> >       o       I don't want GDB's release schedule in
> >               someway directly tided to GCC's release
> >               schedule.
> 
> I think that is unavoidable, given that Gcc 3 has a new and
> incompatible C++ ABI.  It is Bad if the current release of Gdb cannot
> debug code produced from the current release of Gcc.  Therefore, Gdb
> 5.1 should be released before or at the same time as Gcc 3.0 is
> released, and it needs to have at least tolerable support for the new
> C++ ABI.

As far as I know, GDB works tolerably well now for 3.0 - it doesn't dump
core for instance :-).  I'm just geting in and being clear to people
that think 3.0 C++ support perfect needs to be perfect for 5.1 :-)

One likely reality is that: GDB 5.1 will come out, GCC 3.0 will come out
and then a GDB 5.2 will appear.

enjoy,
	Andrew

Re: C++ FAIL counts and the effect of demangler fix

[Per Bothner]

Andrew Cagney <ac131313@cygnus.com> writes:

> As far as I know, GDB works tolerably well now for 3.0 - it doesn't dump
> core for instance :-).  I'm just geting in and being clear to people
> that think 3.0 C++ support perfect needs to be perfect for 5.1 :-)
> 
> One likely reality is that: GDB 5.1 will come out, GCC 3.0 will come out
> and then a GDB 5.2 will appear.

That seems ok.  I don't think we should hold up 5.1 for "perfect"
3.0 C++ support - in fact it is better, I think, for 5.1 to come
out before Gcc 3.0, as long as it has at least tolerable 3.0 C++
support.

I could list my version of a priority list of C++ features, but
since I'm unlikely to do anything about it, there;s not point.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

Re: C++ FAIL counts and the effect of demangler fix

[Eli Zaretskii]

> From: Per Bothner <per@bothner.com>
> Date: 15 Feb 2001 13:54:02 -0800
> 
> Andrew Cagney <ac131313@cygnus.com> writes:
> 
> >	o	I don't want GDB's release schedule in
> >		someway directly tided to GCC's release
> >		schedule.
> 
> I think that is unavoidable, given that Gcc 3 has a new and
> incompatible C++ ABI.  It is Bad if the current release of Gdb cannot
> debug code produced from the current release of Gcc.  Therefore, Gdb
> 5.1 should be released before or at the same time as Gcc 3.0 is
> released, and it needs to have at least tolerable support for the new
> C++ ABI.
> 
> Otherwise, we may have to live with the situation (and I don't
> actually know what the situation is), but make no mistake: This is
> a critical issue for many people, Red Hat included.  (OS distributors
> may have a hard time switching to Gcc 3.0 if there are critical Gdb
> regressions.)

If there are important reasons why the next release of GDB should
support the new C++ ABI, then perhaps the GCC team should help Daniel
and others work on the GDB side of this support.  Or maybe you should
consider delaying the release of GCC 3.0 in the same manner as you are
suggesting that GDB will delay its release.

This is not an issue with GDB alone.  The change of the ABI was in
GCC, so I think the GCC team should share the responsibility for
making GDB support it.

Re: C++ FAIL counts and the effect of demangler fix

[Daniel Berlin]

Eli Zaretskii <eliz@delorie.com> writes:

> > From: Per Bothner <per@bothner.com>
> > Date: 15 Feb 2001 13:54:02 -0800
> > 
> > Andrew Cagney <ac131313@cygnus.com> writes:
> > 
> > >	o	I don't want GDB's release schedule in
> > >		someway directly tided to GCC's release
> > >		schedule.
> > 
> > I think that is unavoidable, given that Gcc 3 has a new and
> > incompatible C++ ABI.  It is Bad if the current release of Gdb cannot
> > debug code produced from the current release of Gcc.  Therefore, Gdb
> > 5.1 should be released before or at the same time as Gcc 3.0 is
> > released, and it needs to have at least tolerable support for the new
> > C++ ABI.
> > 
> > Otherwise, we may have to live with the situation (and I don't
> > actually know what the situation is), but make no mistake: This is
> > a critical issue for many people, Red Hat included.  (OS distributors
> > may have a hard time switching to Gcc 3.0 if there are critical Gdb
> > regressions.)
> 
> If there are important reasons why the next release of GDB should
> support the new C++ ABI, then perhaps the GCC team should help Daniel
> and others work on the GDB side of this support. 

While i'd be happy for the support, ....
>  Or maybe you should
> consider delaying the release of GCC 3.0 in the same manner as you are
> suggesting that GDB will delay its release.
> 
> This is not an issue with GDB alone.  The change of the ABI was in
> GCC, so I think the GCC team should share the responsibility for
> making GDB support it.

I don't agree with this.
The GCC team is responsible for GCC, not GDB.
Why should they have to be coding support for things in GDB?

Sure, we should be connected, and informed of what the GCC team is
doing, and they, informed of what we are doing, in timely fashion such
that we can make the two work well together, but saying they have a
responsibility to actually implement gdb functionality is, IMHO, going
to far.

Fer instance, if they change GCC to emit dwarf2 location expressions
in something they plan to release in ~8 months (estimated of course, but
guaranteed to not be *shorter* than 8 months), and tell us, why the
heck should they have to implement dwarf2 location expression support
in GDB?  That's a big job, and not easy for someone not familiar with
th dwarf2 *reader*, or the symbol table structures, etc, by a long
shot. It would be *better* done by someone on the gdb team.

Saying they have share any kind of responsibility for us supporting it
just feels wrong to me. I'm okay with saying they have a
responsibility to make sure we know about the stuff, but not that they
have any responsibility to actually implement it.

Regardless, besides virtual functions, i've got the rest abstracted so
that it works for both ABI's, and will be submitting it soon. And
virtual functions don't work because i'm having 
trouble following all the cases in the abi, and generating the code
necessary to perform the same lookups. The rest of the issues are
mainly cosmetic, and don't take more than a day or two to fix (IMHO).

I also haven't readded HP's C++ ABI stuff, since it was *so*
improperly inlined, pieces need to rewritten (I've verified that they
*can* be implemented in terms of the new C++ abi abstraction stuff, i
just have no way of doing so and testing the result. Though I will
attempt it if requested).

The only real need for any delay will depend on how long it takes to
get the patches to be reviewed. They aren't particularly large, but
touch a whole bunch of code to get rid of stuff, like macros that were too
specific to one abi that each abi had (named different things of
course), and were replaced with a canonical function that all the
abi's implement instead. 
--Dan

Re: C++ FAIL counts and the effect of demangler fix

[Eli Zaretskii]

> From: Daniel Berlin <dberlin@redhat.com>
> Date: 16 Feb 2001 03:57:11 -0500
> 
> Eli Zaretskii <eliz@delorie.com> writes:
> 
> > > From: Per Bothner <per@bothner.com>
> > > Date: 15 Feb 2001 13:54:02 -0800
> > > 
> > > Andrew Cagney <ac131313@cygnus.com> writes:
> > > 
> > > >	o	I don't want GDB's release schedule in
> > > >		someway directly tided to GCC's release
> > > >		schedule.
> > > 
> > > I think that is unavoidable, given that Gcc 3 has a new and
> > > incompatible C++ ABI.  It is Bad if the current release of Gdb cannot
> > > debug code produced from the current release of Gcc.  Therefore, Gdb
> > > 5.1 should be released before or at the same time as Gcc 3.0 is
> > > released, and it needs to have at least tolerable support for the new
> > > C++ ABI.
[snip]
> > 
> > If there are important reasons why the next release of GDB should
> > support the new C++ ABI, then perhaps the GCC team should help Daniel
> > and others work on the GDB side of this support. 
[snip]
> I don't agree with this.
> The GCC team is responsible for GCC, not GDB.

[Sorry for the long quotations, they are necessary in this case.]

Let me back up for a moment.  See the quotations above; it goes like
this:

   - Andrew says he doesn't want GDB's release schedule to be directly
     tied to GCC's releases (FWIW, I'm with Andrew on this one);

   - Per replies that it is very important that GDB _does_ release its
     new version with the new C++ ABI support together with GCC 3.0;

   - To this I say that if the GCC teams wants it so badly, they
     should come on board and help.

In other words, I also don't think that the GCC team should be
developing GDB.  What I am saying is that if they think our decisions
are not good enough for them, they have the opportuninty to make a
difference by contributing the code.

Re: C++ FAIL counts and the effect of demangler fix

[Michael Elizabeth Chastain]

> I'll do it, send me the log.

Argh, I already did something else in that tree.  I was testing an
unrelated patch and I did "make check RUNTESTFLAGS=callfwmall.exp".

I'll regenerate the log and send it to you privately.  Can you handle a
two megabyte e-mail message?

Michael

Re: C++ FAIL counts and the effect of demangler fix

[Michael Elizabeth Chastain]

Good morning Daniel,

> Well, okay, there are a few real bugs in there, that i'm working on,
> but the *majority* of the fails are caused by the testsuite being
> wrong.

My intution says this is probably true but I'm shaken up by the actual
data.  Someone's going to have to analyze the test suite, FAIL by FAIL.
"Someone" probably will be "me".

Michael

Re: C++ FAIL counts and the effect of demangler fix

[Daniel Berlin]

Michael Elizabeth Chastain <chastain@cygnus.com> writes:

> Good morning Daniel,
> 
> > Well, okay, there are a few real bugs in there, that i'm working on,
> > but the *majority* of the fails are caused by the testsuite being
> > wrong.
> 
> My intution says this is probably true but I'm shaken up by the actual
> data.  Someone's going to have to analyze the test suite, FAIL by FAIL.
> "Someone" probably will be "me".

I'll do it, send me the log.

I know what parts of the code actually correlate with which C++ tests,
so it would take me significantly less time. At least, I would imagine
it would.
--Dan

C++ FAIL counts and the effect of demangler fix

[Michael Elizabeth Chastain]

FAIL counts for gdb.c++/*.exp

			 plain compat  diff       v2

  gdb.c++/*.exp            306   163    143       18
  -------------            ---   ---    ---       --
  gdb.c++/cplusfuncs.exp    83     0    -83
  gdb.c++/inherit.exp       62     6    -56
  gdb.c++/ref-types.exp     60    60      0
  gdb.c++/virtfunc.exp      32    31     -1
  gdb.c++/derivation.exp    20    20      0
  gdb.c++/classes.exp       19    18     -1        5
  gdb.c++/templates.exp      7     7      0        2
  gdb.c++/overload.exp       6     5     -1
  gdb.c++/namespace.exp      5     4     -1        1
  gdb.c++/method.exp         4     4      0
  gdb.c++/local.exp          3     3      0
  gdb.c++/annota2.exp        3     3      0        3
  gdb.c++/userdef.exp        1     1      0
  gdb.c++/demangle.exp       1     1      0        1
  gdb.c++/ovldbreak.exp      0     0      0        6

Column #1 is FSF CVS gcc (2001-02-12) + FSF CVS gdb (2001-02-12).
Test results are combined from three platforms: Red Hat Linux 7 native,
Red Hat Linux 6.2 native, and Solaris 2.6 native.  There is no
significant platform dependence.

Column #2 is software from #1 plus Daniel Berlin's patch to the demangler
to format names the same as the v2 abi.  Test results are from Red Hat Linux
7 only.

Column #3 is the difference between #1 and #2.

Column #4 is /usr/bin/gcc (gcc 2.96), which uses v2 abi, + FSF CVS gdb
(2001-02-12).  This is the baseline that we have to get back to.  [Hmmm,
ovldbreak.exp was working with v2 abi compilers on 2001-01-28 when I
checked it in.  I have to look into that].

Michael Elizabeth Chastain
<chastain@redhat.com>
"love without fear"

Re: C++ FAIL counts and the effect of demangler fix

[Andrew Cagney]

Michael,

Can you elaborate?  The numbers look really intersting however, to me
(someone that has avoided C++ since cfront 1.2) they are meaningless. 
Why is there the divergence, for instance - where is it comming from.

> Column #4 is /usr/bin/gcc (gcc 2.96), which uses v2 abi, + FSF CVS gdb
> (2001-02-12).  This is the baseline that we have to get back to.  [Hmmm,
> ovldbreak.exp was working with v2 abi compilers on 2001-01-28 when I
> checked it in.  I have to look into that].

BTW, we don't have to get back to anything.  As far as I know, the
failures are being caused by an unlreased version of GCC that has
changed its mangler ABI in some incompatible way.  It would be nice if
the problems were resolved, however, they are _NOT_ a 5.1 release
criteria so not especially high on my radar.  5.1 needs to work with
real compilers installed on real machines.

	enjoy,
		Andrew

Re: C++ FAIL counts and the effect of demangler fix

[Daniel Berlin]

Andrew Cagney <ac131313@cygnus.com> writes:

> Michael,
> 
> Can you elaborate?  The numbers look really intersting however, to me
> (someone that has avoided C++ since cfront 1.2) they are meaningless. 
> Why is there the divergence, for instance - where is it comming
> from.

Simple.
regex's don't match anymore.

My demangler changes make the whitespace/type names/etc look the same
as the old demangler.

The rest of the fails are caused by the fact that we now have two
constructors, rather than one, so those regex's don't match now.

Well, okay, there are a few real bugs in there, that i'm working on,
but the *majority* of the fails are caused by the testsuite being
wrong.

> 
> > Column #4 is /usr/bin/gcc (gcc 2.96), which uses v2 abi, + FSF CVS gdb
> > (2001-02-12).  This is the baseline that we have to get back to.  [Hmmm,
> > ovldbreak.exp was working with v2 abi compilers on 2001-01-28 when I
> > checked it in.  I have to look into that].
> 
> BTW, we don't have to get back to anything.  As far as I know, the
> failures are being caused by an unlreased version of GCC that has
> changed its mangler ABI in some incompatible way.

Whoa there.

3.0 will be released soon. it's already been branched. We will get a
lot of flack if we don't support it.

Especially if we release 5.1 after they release 3.0.

If 5.1 goes out first, it should be a 5.2 release criteria, and maybe
the only release criteria (since it will be critical for C++ support),
if nothing else major pops up (IE some platform stops working or something).

>   It would be nice if
> the problems were resolved, however, they are _NOT_ a 5.1 release
> criteria so not especially high on my radar.  5.1 needs to work with
> real compilers installed on real machines.

Be careful of this. In my experience, C++ people are more concerned,
usually, with working compilers, then using stable versions.
Probably because they are still used to having to deal with ICE's on complex
C++ code.

Not that people are using the 3.0 branch to make production builds, but they
might be waiting for 3.0 to release products, rather than try to code
workarounds. Assuming they can, of course.

--Dan