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

Daniel Berlin
2001-02-14T08:28:00Z

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