On Tue, Sep 10, 2013 at 3:17 AM, Jakub Jelinek <ja...@redhat.com> wrote:
> On Mon, Sep 09, 2013 at 01:56:29PM -0700, Caroline Tice wrote:
>> The patch looks good to me, but somebody else needs to approve it.
>
> Why? You are listed as libvtv maintainer, the patch is fully contained in
> libvtv, thus you can review it and approve.
>
There was a bit of communication confusion and I originally
misunderstood things. I thought I was the libvtv maintainer, but so
far i have only been proposed (am being proposed?) to the steering
committee to be the libvtv maintainer. Until the steering committee
officially approves that, I am not actually the maintainer, and I do
not have the authority to approve patches.
> On an unrelated note, what kind of testing was performed on libvtv
> testsuite?
> I'm seeing very bad results on both x86_64-linux and i686-linux, like
> === libvtv Summary ===
>
> # of expected passes 92
> # of unexpected failures 44
> # of unresolved testcases 40
>
> Many of the errors seem to be related to missing vtv_start_preinit.o
> not being found (why do those actually live in libgcc rather than libvtv?),
> libvtv/Makefile.am has only rules for vtv_start.c etc., but not
> vtv_start_preinit.c.
>
Actually I performed a lot of testing of this testsuite, but it was
all on my linux x86_64 system. I consistently get it passing all
the tests:
=== libvtv tests ===
Schedule of variations:
unix
Running target unix
Using /usr/local/share/dejagnu/baseboards/unix.exp as board
description file for target.
Using /usr/local/share/dejagnu/config/unix.exp as generic interface
file for target.
Using /usr/local/google2/cmtice/gcc-fsf/libvtv/testsuite/config/default.exp
as tool-and-target-specific interface file.
Running /usr/local/google2/cmtice/gcc-fsf/libvtv/testsuite/libvtv.cc/vtv.exp ...
Running
/usr/local/google2/cmtice/gcc-fsf/libvtv/testsuite/libvtv.mempool.cc/mempool.exp
...
Running /usr/local/google2/cmtice/gcc-fsf/libvtv/testsuite/libvtv.mt.cc/mt.exp
...
=== libvtv Summary ===
# of expected passes 176
make[1]: Leaving directory
`/usr/local/google2/cmtice/gcc-fsf.obj/x86_64-unknown-linux-gnu/libvtv/testsuite'
Based on the errors you are reporting, my guess is that you did not
configure with --enable-vtable-verifiy. The testsuite in libvtv will
not pass without vtable verification enabled. If you DID configure
with --enable-vtable-verify, then please send me the rest of your
configure command so that I can try to reproduce your failures.
> But I also see complains from glibc about corrupted malloc state in some
> tests, tests with such undefined behavior IMHO don't belong into the
> testsuite, unless you can prevent the corruption before it happens.
>
I have never seen that; if you could forward the complaints/errors to
me I would appreciate it.
-- Caroline Tice
cmt...@google.com
> Jakub
