This is the mail archive of the
mailing list for the GDB project.
Re: C++ FAIL counts and the effect of demangler fix
- To: Andrew Cagney <ac131313 at cygnus dot com>
- Subject: Re: C++ FAIL counts and the effect of demangler fix
- From: Daniel Berlin <dberlin at redhat dot com>
- Date: 14 Feb 2001 11:27:43 -0500
- Cc: Michael Elizabeth Chastain <chastain at cygnus dot com>, gdb at sources dot redhat dot com
- References: <200102140806.AAA28150@bosch.cygnus.com><3A8AA3D2.22B3CF9B@cygnus.com>
Andrew Cagney <firstname.lastname@example.org> writes:
> 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
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
> > 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.
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
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.