Does anyone check libstdc++-v3 failures in gcc 3.0?

[Phil Edwards]

On Sun, Apr 15, 2001 at 08:49:49PM -0700, H . J . Lu wrote:
> Does anyone check those libstdc++v3 failures in gcc 3.0?

Every day.


> -b      -b      23_containers/map_operators.cc
> -b      -b      23_containers/set_operators.cc

XFAILs.  The mkcheck script doesn't know about XFAIL yet.

> -b      -b      26_numerics/c99_macros.cc

glibc defines certain things as macros which C++ requires to be functions.
I don't recall whether this is supposed to be XFAIL or not (I think it
should pass).

> -b      -b      27_io/filebuf.cc

Undefined references at link time.  Looks like 'short' is being used as
the instantiating character type (where did wchar_t go).  I haven't looked
into this one.  It's working on the trunk.

> -b      -b      27_io/istream_seeks.cc

The compiler spits out a bunch of "by the way, I'm choosing this conversion
over that conversion because it's a better match" messages, and then
simply /stops/.  Apparently those messages are supposed to be errors.
(This was discussed once before when it was fixed on the trunk; I'm sorry
but I still don't understand why these errors sound more like "informational"
or "debug" messsages.)  Fixed on the trunk.

> diff: ./istream_unformatted-2.txt: No such file or directory
> +       diff: ./istream_unformatted-2.txt: No such file or directory

Missing empty file on the branch.  Fixed on the trunk.


> I hope gcc 3.0 will ship a working libstdc++ which at least passes its
> own testsuite. That is what gcc had been doing before gcc 3.0.

The trunk shows fewer failures.


-- 
pedwards at disaster dot jaj dot com  |  pme at sources dot redhat dot com
devphil at several other less interesting addresses in various dot domains
The gods do not protect fools.  Fools are protected by more capable fools.