* RISC-V test results
@ 2019-07-31 23:01 Maciej W. Rozycki
2019-07-31 23:06 ` Joseph Myers
2019-07-31 23:31 ` DJ Delorie
0 siblings, 2 replies; 10+ messages in thread
From: Maciej W. Rozycki @ 2019-07-31 23:01 UTC (permalink / raw)
To: libc-alpha; +Cc: Alistair Francis
Hi,
I saw no RISC-V test results published for glibc 2.30, so I have spent
some time to see how we perform. These were obtained for lp64 and lp64d
multilibs with a cross-compilation environment using GCC version 10.0.0
20190618, GNU Binutils version 2.32.51.20190618, Linux version
5.2.0-rc1unleashed-00006-g5bc63aefde9a and a HiFive Unleashed board
(rv64imafdc CPU) accessing the glibc source and build tree from the build
system over NFS.
I had to bump up the timeout factor to avoid excessive timeouts and
experimented with that. Consequently the lp64 and lp64d multilib tests
were run with the factor of 10 and 20 respectively. Still a couple of
tests timed out:
FAIL: nptl/tst-stack4
FAIL: resolv/tst-resolv-res_ninit
(nptl/tst-stack4 crashed instead for lp64). When run standalone these
tests eventually succeed, requiring short of 8 hours and 25 minutes each,
which I believe is due to synchronous NFS inefficiency, and which implies
a timeout factor of at least ~300 to guarantee completion (timeout is 100
for nptl/tst-stack4). I will use that next time; these testsuite runs
took over 9 hours to complete each anyway, so doubling the time should not
be a big deal.
For some reason I haven't established yet lp64 results are significantly
worse than lp64d ones, which in turn are similar to these previously
obtained for 2.29. I have noticed that out of 140 lp64 FAILs 90 are due
to SIGABRT having been raised, including said nptl/tst-stack4. I'm still
investigating the cause, which is likely outside glibc as I can see there
have been results posted now and they are fine for lp64.
Also these aborts caused the nptl/tst-cancel7 and nptl/tst-cancelx7 test
cases to hang, requiring a manual intervention for testing to proceed, as
one of the child threads remained behind as the parent thread aborted and
prevented the remotely started command from completing. I think this has
to be addressed somehow and it prevents testing from running unattended.
Maybe another timeout has to be defined and enforced for the build system
in `cross-test-ssh.sh'.
For the record my actual results are as follows:
rv64imafdc/lp64:
UNSUPPORTED: assert/tst-assert-c++
UNSUPPORTED: assert/tst-assert-g++
FAIL: debug/tst-backtrace2
FAIL: debug/tst-backtrace3
FAIL: debug/tst-backtrace4
FAIL: debug/tst-backtrace5
FAIL: debug/tst-backtrace6
UNSUPPORTED: debug/tst-chk4
UNSUPPORTED: debug/tst-chk5
UNSUPPORTED: debug/tst-chk6
UNSUPPORTED: debug/tst-lfschk4
UNSUPPORTED: debug/tst-lfschk5
UNSUPPORTED: debug/tst-lfschk6
UNSUPPORTED: dlfcn/bug-atexit3
FAIL: elf/tst-rtld-preload
FAIL: elf/tst-tls12
FAIL: elf/tst-unwind-main
FAIL: iconv/tst-iconv-mt
FAIL: inet/tst-idna_name_classify
FAIL: io/ftwtest
FAIL: libio/tst-wfile-sync
FAIL: locale/tst-locale-locpath
FAIL: localedata/tst-langinfo-newlocale
FAIL: malloc/tst-malloc-stats-cancellation
FAIL: malloc/tst-malloc-usable-tunables
UNSUPPORTED: malloc/tst-mallocstate
UNSUPPORTED: math/test-fesetexcept-traps
UNSUPPORTED: math/test-fexcept-traps
UNSUPPORTED: math/test-matherr
UNSUPPORTED: math/test-matherr-2
UNSUPPORTED: math/test-nearbyint-except
UNSUPPORTED: math/test-nearbyint-except-2
FAIL: misc/tst-gettid-kill
UNSUPPORTED: misc/tst-pkey
UNSUPPORTED: nptl/test-cond-printers
UNSUPPORTED: nptl/test-condattr-printers
UNSUPPORTED: nptl/test-mutex-printers
UNSUPPORTED: nptl/test-mutexattr-printers
UNSUPPORTED: nptl/test-rwlock-printers
UNSUPPORTED: nptl/test-rwlockattr-printers
FAIL: nptl/tst-basic3
FAIL: nptl/tst-basic4
FAIL: nptl/tst-call-once
FAIL: nptl/tst-cancel-self
FAIL: nptl/tst-cancel-self-cancelstate
FAIL: nptl/tst-cancel-self-canceltype
FAIL: nptl/tst-cancel-self-testcancel
FAIL: nptl/tst-cancel1
FAIL: nptl/tst-cancel10
FAIL: nptl/tst-cancel11
FAIL: nptl/tst-cancel12
FAIL: nptl/tst-cancel13
FAIL: nptl/tst-cancel14
FAIL: nptl/tst-cancel15
FAIL: nptl/tst-cancel16
FAIL: nptl/tst-cancel17
FAIL: nptl/tst-cancel18
FAIL: nptl/tst-cancel2
FAIL: nptl/tst-cancel20
FAIL: nptl/tst-cancel21
FAIL: nptl/tst-cancel22
FAIL: nptl/tst-cancel23
UNSUPPORTED: nptl/tst-cancel24
UNSUPPORTED: nptl/tst-cancel24-static
FAIL: nptl/tst-cancel25
FAIL: nptl/tst-cancel3
FAIL: nptl/tst-cancel4
FAIL: nptl/tst-cancel4_1
FAIL: nptl/tst-cancel4_2
FAIL: nptl/tst-cancel5
FAIL: nptl/tst-cancel6
FAIL: nptl/tst-cancel7
FAIL: nptl/tst-cancel8
FAIL: nptl/tst-cancel9
FAIL: nptl/tst-cancelx10
FAIL: nptl/tst-cancelx11
FAIL: nptl/tst-cancelx12
FAIL: nptl/tst-cancelx13
FAIL: nptl/tst-cancelx14
FAIL: nptl/tst-cancelx15
FAIL: nptl/tst-cancelx16
FAIL: nptl/tst-cancelx17
FAIL: nptl/tst-cancelx18
FAIL: nptl/tst-cancelx2
FAIL: nptl/tst-cancelx20
FAIL: nptl/tst-cancelx21
FAIL: nptl/tst-cancelx3
FAIL: nptl/tst-cancelx4
FAIL: nptl/tst-cancelx5
FAIL: nptl/tst-cancelx6
FAIL: nptl/tst-cancelx7
FAIL: nptl/tst-cancelx8
FAIL: nptl/tst-cancelx9
FAIL: nptl/tst-cleanup0
FAIL: nptl/tst-cleanup0-cmp
FAIL: nptl/tst-cleanup1
FAIL: nptl/tst-cleanup3
FAIL: nptl/tst-cleanup4
FAIL: nptl/tst-cleanupx0
FAIL: nptl/tst-cleanupx1
FAIL: nptl/tst-cleanupx3
FAIL: nptl/tst-cleanupx4
FAIL: nptl/tst-cnd-basic
FAIL: nptl/tst-cnd-broadcast
FAIL: nptl/tst-cnd-timedwait
FAIL: nptl/tst-cond-except
FAIL: nptl/tst-cond22
FAIL: nptl/tst-cond25
FAIL: nptl/tst-cond7
FAIL: nptl/tst-cond8
FAIL: nptl/tst-exec5
FAIL: nptl/tst-execstack
FAIL: nptl/tst-exit2
FAIL: nptl/tst-exit3
FAIL: nptl/tst-fini1
FAIL: nptl/tst-join1
FAIL: nptl/tst-join5
FAIL: nptl/tst-join6
FAIL: nptl/tst-join8
FAIL: nptl/tst-join9
FAIL: nptl/tst-key3
FAIL: nptl/tst-minstack-cancel
FAIL: nptl/tst-minstack-exit
UNSUPPORTED: nptl/tst-minstack-throw
FAIL: nptl/tst-mtx-basic
FAIL: nptl/tst-mtx-timedlock
FAIL: nptl/tst-mtx-trylock
FAIL: nptl/tst-mutex8
FAIL: nptl/tst-mutexpi8
FAIL: nptl/tst-once3
FAIL: nptl/tst-once4
UNSUPPORTED: nptl/tst-once5
FAIL: nptl/tst-oncex3
FAIL: nptl/tst-oncex4
FAIL: nptl/tst-robust1
FAIL: nptl/tst-robust2
FAIL: nptl/tst-robust3
FAIL: nptl/tst-robust4
FAIL: nptl/tst-robust5
FAIL: nptl/tst-robust6
FAIL: nptl/tst-robust7
FAIL: nptl/tst-robustpi1
FAIL: nptl/tst-robustpi2
FAIL: nptl/tst-robustpi3
FAIL: nptl/tst-robustpi4
FAIL: nptl/tst-robustpi5
FAIL: nptl/tst-robustpi6
FAIL: nptl/tst-robustpi7
FAIL: nptl/tst-sem11
FAIL: nptl/tst-sem12
FAIL: nptl/tst-sem16
FAIL: nptl/tst-stack4
FAIL: nptl/tst-thrd-detach
FAIL: nptl/tst-thrd-sleep
UNSUPPORTED: nptl/tst-thread-exit-clobber
UNSUPPORTED: nptl/tst-thread_local1
FAIL: nptl/tst-tsd5
FAIL: nptl/tst-tss-basic
FAIL: nptl/tst-unwind-thread
FAIL: nss/tst-cancel-getpwuid_r
FAIL: posix/tst-getopt-cancel
UNSUPPORTED: posix/tst-glob_lstat_compat
UNSUPPORTED: posix/tst-spawn4-compat
FAIL: resolv/mtrace-tst-resolv-res_ninit
UNSUPPORTED: resolv/tst-p_secstodate
UNSUPPORTED: resolv/tst-resolv-ai_idn
UNSUPPORTED: resolv/tst-resolv-ai_idn-latin1
FAIL: resolv/tst-resolv-res_init
FAIL: resolv/tst-resolv-res_init-thread
FAIL: resolv/tst-resolv-res_ninit
FAIL: rt/tst-cpuclock2
FAIL: rt/tst-mqueue8
FAIL: rt/tst-mqueue8x
FAIL: rt/tst-shm-cancel
UNSUPPORTED: stdlib/tst-quick_exit
UNSUPPORTED: stdlib/tst-thread-quick_exit
Summary of test results:
140 FAIL
5721 PASS
36 UNSUPPORTED
18 XFAIL
rv64imafdc/lp64d:
UNSUPPORTED: assert/tst-assert-c++
UNSUPPORTED: assert/tst-assert-g++
UNSUPPORTED: debug/tst-chk4
UNSUPPORTED: debug/tst-chk5
UNSUPPORTED: debug/tst-chk6
UNSUPPORTED: debug/tst-lfschk4
UNSUPPORTED: debug/tst-lfschk5
UNSUPPORTED: debug/tst-lfschk6
UNSUPPORTED: dlfcn/bug-atexit3
FAIL: elf/tst-rtld-preload
FAIL: elf/tst-tls12
FAIL: io/ftwtest
FAIL: libio/tst-wfile-sync
FAIL: locale/tst-locale-locpath
FAIL: malloc/tst-malloc-usable-tunables
UNSUPPORTED: malloc/tst-mallocstate
UNSUPPORTED: math/test-fesetexcept-traps
UNSUPPORTED: math/test-fexcept-traps
UNSUPPORTED: math/test-matherr
UNSUPPORTED: math/test-matherr-2
UNSUPPORTED: math/test-nearbyint-except-2
UNSUPPORTED: misc/tst-pkey
UNSUPPORTED: nptl/test-cond-printers
UNSUPPORTED: nptl/test-condattr-printers
UNSUPPORTED: nptl/test-mutex-printers
UNSUPPORTED: nptl/test-mutexattr-printers
UNSUPPORTED: nptl/test-rwlock-printers
UNSUPPORTED: nptl/test-rwlockattr-printers
UNSUPPORTED: nptl/tst-cancel24
UNSUPPORTED: nptl/tst-cancel24-static
FAIL: nptl/tst-cancel7
FAIL: nptl/tst-cancelx7
UNSUPPORTED: nptl/tst-minstack-throw
UNSUPPORTED: nptl/tst-once5
FAIL: nptl/tst-stack4
UNSUPPORTED: nptl/tst-thread-exit-clobber
UNSUPPORTED: nptl/tst-thread_local1
UNSUPPORTED: posix/tst-glob_lstat_compat
UNSUPPORTED: posix/tst-spawn4-compat
FAIL: resolv/mtrace-tst-resolv-res_ninit
UNSUPPORTED: resolv/tst-p_secstodate
FAIL: resolv/tst-resolv-res_init
FAIL: resolv/tst-resolv-res_init-thread
FAIL: resolv/tst-resolv-res_ninit
UNSUPPORTED: stdlib/tst-quick_exit
FAIL: stdlib/tst-strfrom
FAIL: stdlib/tst-strfrom-locale
UNSUPPORTED: stdlib/tst-thread-quick_exit
Summary of test results:
15 FAIL
5849 PASS
33 UNSUPPORTED
18 XFAIL
Maciej
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: RISC-V test results
2019-07-31 23:01 RISC-V test results Maciej W. Rozycki
@ 2019-07-31 23:06 ` Joseph Myers
2019-08-01 13:28 ` Maciej W. Rozycki
2019-07-31 23:31 ` DJ Delorie
1 sibling, 1 reply; 10+ messages in thread
From: Joseph Myers @ 2019-07-31 23:06 UTC (permalink / raw)
To: Maciej W. Rozycki; +Cc: libc-alpha, Alistair Francis
On Thu, 1 Aug 2019, Maciej W. Rozycki wrote:
> For some reason I haven't established yet lp64 results are significantly
> worse than lp64d ones, which in turn are similar to these previously
> obtained for 2.29. I have noticed that out of 140 lp64 FAILs 90 are due
> to SIGABRT having been raised, including said nptl/tst-stack4. I'm still
> investigating the cause, which is likely outside glibc as I can see there
> have been results posted now and they are fine for lp64.
To confirm: have you made sure that libgcc_s and libstdc++ shared
libraries for this ABI, from the compiler used for testing, are copied to
the glibc build directory (or present in the default dynamic linker search
path)? Missing libgcc_s causes both many NPTL tests to fail and some to
hang.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: RISC-V test results
2019-07-31 23:01 RISC-V test results Maciej W. Rozycki
2019-07-31 23:06 ` Joseph Myers
@ 2019-07-31 23:31 ` DJ Delorie
2019-08-01 13:45 ` Maciej W. Rozycki
1 sibling, 1 reply; 10+ messages in thread
From: DJ Delorie @ 2019-07-31 23:31 UTC (permalink / raw)
To: Maciej W. Rozycki; +Cc: libc-alpha, alistair.francis
"Maciej W. Rozycki" <macro@wdc.com> writes:
> I saw no RISC-V test results published for glibc 2.30,
I just posted mine to the wiki last night :-)
My environment is a HiFiveU board with a local SSD (no nfs involved),
running Fedora 28 but with some upgrades (versions noted in wiki). It's
one of the Fedora/RISC-V build machines so I have faith in it :-)
The build was a native build, no cross-anything.
> I had to bump up the timeout factor to avoid excessive timeouts and
I set TIMEOUTFACTOR to 20 for hifive builds, even with a local SSD.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: RISC-V test results
2019-07-31 23:06 ` Joseph Myers
@ 2019-08-01 13:28 ` Maciej W. Rozycki
2019-08-01 17:07 ` Joseph Myers
0 siblings, 1 reply; 10+ messages in thread
From: Maciej W. Rozycki @ 2019-08-01 13:28 UTC (permalink / raw)
To: Joseph Myers; +Cc: libc-alpha, Alistair Francis
On Wed, 31 Jul 2019, Joseph Myers wrote:
> > For some reason I haven't established yet lp64 results are significantly
> > worse than lp64d ones, which in turn are similar to these previously
> > obtained for 2.29. I have noticed that out of 140 lp64 FAILs 90 are due
> > to SIGABRT having been raised, including said nptl/tst-stack4. I'm still
> > investigating the cause, which is likely outside glibc as I can see there
> > have been results posted now and they are fine for lp64.
>
> To confirm: have you made sure that libgcc_s and libstdc++ shared
> libraries for this ABI, from the compiler used for testing, are copied to
> the glibc build directory (or present in the default dynamic linker search
> path)? Missing libgcc_s causes both many NPTL tests to fail and some to
> hang.
Good point! I wasn't aware of this dependency on these libraries, so I
have double-checked what was going on here.
So what I have found out is as follows. I actually have outstanding GCC
patches applied (pending FSF making up their minds about my WDC copyright
assignment) to get things automatically properly installed in the sysroot
if requested; I've had too many cases of using a stale version of such
libraries previously copied manually to be able to rely on such a
misarrangement:
$ find sysroot -name 'libgcc_s*.so*' -o -name 'libstdc++*.so*' | sort
sysroot/usr/lib64/lp64/libgcc_s.so
sysroot/usr/lib64/lp64/libgcc_s.so.1
sysroot/usr/lib64/lp64/libstdc++.so
sysroot/usr/lib64/lp64/libstdc++.so.6
sysroot/usr/lib64/lp64/libstdc++.so.6.0.26
sysroot/usr/lib64/lp64/libstdc++.so.6.0.26-gdb.py
sysroot/usr/lib64/lp64d/libgcc_s.so
sysroot/usr/lib64/lp64d/libgcc_s.so.1
sysroot/usr/lib64/lp64d/libstdc++.so
sysroot/usr/lib64/lp64d/libstdc++.so.6
sysroot/usr/lib64/lp64d/libstdc++.so.6.0.26
sysroot/usr/lib64/lp64d/libstdc++.so.6.0.26-gdb.py
$
That makes sure that these shared GCC libraries are available to the host
system along with any other shared libraries, however they are not
automatically picked up by the dynamic loader or explicitly requested by
the linker flags used by our test suite.
What I have come up with is I have added:
'sysdep-LDFLAGS=-Wl,-rpath,$(shell $(CC) -print-file-name=libgcc_s.so | xargs realpath | xargs dirname)'
to the `make check' invocation so that the correct location of the shared
`libgcc_s' library is automagically added according to the multilib used,
avoiding the risk of a human error. My choice of `sysdep-LDFLAGS' follows
my observation that this `make' variable is only appended to rather than
preassigned and it is included among the link flags used with test cases.
I'm sharing this in a hope it may help someone; we may want to define and
document a proper `make' variable to use instead for passing test flags
like this one.
I have run a subset of the lp64 tests of which some previously aborted
and they passed this time, so I have started full testing and will have
hopefully good results by tomorrow.
In the course of `Makefile' examination I have noticed that we have no
way to remove compiled tests only, that is `make tests-clean' only removes
test results and `make mostlyclean' does remove compiled tests, however it
also removes compiled library code.
Many of our test case names start with `tst-', however not all do and
therefore manual removal is problematic, so I think it would be good to
have an auxiliary clean target for compiled tests only in case they need
to be rebuild with a different set of flags. I'll have to wait until my
copyright assignment has been sorted before I can propose such an update
though.
Thanks for the hint!
Maciej
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: RISC-V test results
2019-07-31 23:31 ` DJ Delorie
@ 2019-08-01 13:45 ` Maciej W. Rozycki
0 siblings, 0 replies; 10+ messages in thread
From: Maciej W. Rozycki @ 2019-08-01 13:45 UTC (permalink / raw)
To: DJ Delorie; +Cc: libc-alpha, alistair.francis
On Wed, 31 Jul 2019, DJ Delorie wrote:
> My environment is a HiFiveU board with a local SSD (no nfs involved),
> running Fedora 28 but with some upgrades (versions noted in wiki). It's
> one of the Fedora/RISC-V build machines so I have faith in it :-)
>
> The build was a native build, no cross-anything.
For the record mine is Fedora 29, however in a cross-testing environment
it hardly matters as long as it doesn't crash. I think such a setup has
an advantage in that it relies less on native features, although on the
other hand native testing puts more stress on the system under test, and
in any case collecting results from different configurations provides
better coverage.
> > I had to bump up the timeout factor to avoid excessive timeouts and
>
> I set TIMEOUTFACTOR to 20 for hifive builds, even with a local SSD.
Sure, I think the vast majority of the test cases is not
filesystem-bound.
Maciej
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: RISC-V test results
2019-08-01 13:28 ` Maciej W. Rozycki
@ 2019-08-01 17:07 ` Joseph Myers
2019-08-05 14:24 ` Maciej W. Rozycki
0 siblings, 1 reply; 10+ messages in thread
From: Joseph Myers @ 2019-08-01 17:07 UTC (permalink / raw)
To: Maciej W. Rozycki; +Cc: libc-alpha, Alistair Francis
On Thu, 1 Aug 2019, Maciej W. Rozycki wrote:
> > To confirm: have you made sure that libgcc_s and libstdc++ shared
> > libraries for this ABI, from the compiler used for testing, are copied to
> > the glibc build directory (or present in the default dynamic linker search
> > path)? Missing libgcc_s causes both many NPTL tests to fail and some to
> > hang.
>
> Good point! I wasn't aware of this dependency on these libraries, so I
> have double-checked what was going on here.
This is a longstanding known issue - see
https://sourceware.org/glibc/wiki/Release/2.30#Architecture-independent -
but we should of course try to fix such issues (and architecture-specific
ones as well) to get closer to the baseline of "make check" just working
and producing clean results rather than needing to compare with a list of
known issues.
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: RISC-V test results
2019-08-01 17:07 ` Joseph Myers
@ 2019-08-05 14:24 ` Maciej W. Rozycki
2019-08-08 21:16 ` Carlos O'Donell
0 siblings, 1 reply; 10+ messages in thread
From: Maciej W. Rozycki @ 2019-08-05 14:24 UTC (permalink / raw)
To: Joseph Myers; +Cc: libc-alpha, Alistair Francis, DJ Delorie
On Thu, 1 Aug 2019, Joseph Myers wrote:
> > Good point! I wasn't aware of this dependency on these libraries, so I
> > have double-checked what was going on here.
>
> This is a longstanding known issue - see
> https://sourceware.org/glibc/wiki/Release/2.30#Architecture-independent -
> but we should of course try to fix such issues (and architecture-specific
> ones as well) to get closer to the baseline of "make check" just working
> and producing clean results rather than needing to compare with a list of
> known issues.
Noted.
For the record here are new rv64imafdc/lp64 results:
FAIL: elf/tst-rtld-preload
FAIL: elf/tst-tls12
FAIL: inet/tst-idna_name_classify
FAIL: io/ftwtest
FAIL: libio/tst-wfile-sync
FAIL: locale/tst-locale-locpath
FAIL: malloc/tst-malloc-usable-tunables
UNSUPPORTED: malloc/tst-mallocstate
UNSUPPORTED: math/test-fesetexcept-traps
UNSUPPORTED: math/test-fexcept-traps
UNSUPPORTED: math/test-matherr
UNSUPPORTED: math/test-matherr-2
UNSUPPORTED: math/test-nearbyint-except
UNSUPPORTED: math/test-nearbyint-except-2
UNSUPPORTED: misc/tst-pkey
UNSUPPORTED: nptl/test-cond-printers
UNSUPPORTED: nptl/test-condattr-printers
UNSUPPORTED: nptl/test-mutex-printers
UNSUPPORTED: nptl/test-mutexattr-printers
UNSUPPORTED: nptl/test-rwlock-printers
UNSUPPORTED: nptl/test-rwlockattr-printers
FAIL: nptl/tst-cancel7
FAIL: nptl/tst-cancelx7
UNSUPPORTED: posix/tst-glob_lstat_compat
UNSUPPORTED: posix/tst-spawn4-compat
UNSUPPORTED: resolv/tst-p_secstodate
UNSUPPORTED: resolv/tst-resolv-ai_idn
UNSUPPORTED: resolv/tst-resolv-ai_idn-latin1
FAIL: resolv/tst-resolv-res_init
FAIL: resolv/tst-resolv-res_init-thread
Summary of test results:
11 FAIL
5920 PASS
19 UNSUPPORTED
19 XFAIL
and for comparison also new rv64imafdc/lp64d results:
FAIL: elf/tst-rtld-preload
FAIL: elf/tst-tls12
FAIL: io/ftwtest
FAIL: libio/tst-wfile-sync
FAIL: locale/tst-locale-locpath
FAIL: malloc/tst-malloc-usable-tunables
UNSUPPORTED: malloc/tst-mallocstate
UNSUPPORTED: math/test-fesetexcept-traps
UNSUPPORTED: math/test-fexcept-traps
UNSUPPORTED: math/test-matherr
UNSUPPORTED: math/test-matherr-2
UNSUPPORTED: math/test-nearbyint-except-2
UNSUPPORTED: misc/tst-pkey
UNSUPPORTED: nptl/test-condattr-printers
UNSUPPORTED: nptl/test-mutexattr-printers
UNSUPPORTED: nptl/test-rwlockattr-printers
FAIL: nptl/tst-cancel7
FAIL: nptl/tst-cancelx7
UNSUPPORTED: posix/tst-glob_lstat_compat
UNSUPPORTED: posix/tst-spawn4-compat
UNSUPPORTED: resolv/tst-p_secstodate
FAIL: resolv/tst-resolv-res_init
FAIL: resolv/tst-resolv-res_init-thread
FAIL: stdlib/tst-strfrom
FAIL: stdlib/tst-strfrom-locale
Summary of test results:
12 FAIL
5925 PASS
13 UNSUPPORTED
19 XFAIL
Both completed with a timeout factor of 600 in ~18.5 and ~19 hours
respectively. I take it the reduction in the number of UNSUPPORTED test
cases comes from the installation of the `pexpect' package on the test
board, which I did having read your reference before the lp64d test run.
Maciej
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: RISC-V test results
2019-08-05 14:24 ` Maciej W. Rozycki
@ 2019-08-08 21:16 ` Carlos O'Donell
2019-08-13 22:46 ` Maciej W. Rozycki
0 siblings, 1 reply; 10+ messages in thread
From: Carlos O'Donell @ 2019-08-08 21:16 UTC (permalink / raw)
To: Maciej W. Rozycki, Joseph Myers; +Cc: libc-alpha, Alistair Francis, DJ Delorie
On 8/5/19 10:24 AM, Maciej W. Rozycki wrote:
> On Thu, 1 Aug 2019, Joseph Myers wrote:
>
>>> Good point! I wasn't aware of this dependency on these libraries, so I
>>> have double-checked what was going on here.
>>
>> This is a longstanding known issue - see
>> https://sourceware.org/glibc/wiki/Release/2.30#Architecture-independent -
>> but we should of course try to fix such issues (and architecture-specific
>> ones as well) to get closer to the baseline of "make check" just working
>> and producing clean results rather than needing to compare with a list of
>> known issues.
>
> Noted.
>
> For the record here are new rv64imafdc/lp64 results:
>
> FAIL: elf/tst-rtld-preload
> FAIL: elf/tst-tls12
> FAIL: inet/tst-idna_name_classify
> FAIL: io/ftwtest
> FAIL: libio/tst-wfile-sync
> FAIL: locale/tst-locale-locpath
> FAIL: malloc/tst-malloc-usable-tunables
> UNSUPPORTED: malloc/tst-mallocstate
> UNSUPPORTED: math/test-fesetexcept-traps
> UNSUPPORTED: math/test-fexcept-traps
> UNSUPPORTED: math/test-matherr
> UNSUPPORTED: math/test-matherr-2
> UNSUPPORTED: math/test-nearbyint-except
> UNSUPPORTED: math/test-nearbyint-except-2
> UNSUPPORTED: misc/tst-pkey
> UNSUPPORTED: nptl/test-cond-printers
> UNSUPPORTED: nptl/test-condattr-printers
> UNSUPPORTED: nptl/test-mutex-printers
> UNSUPPORTED: nptl/test-mutexattr-printers
> UNSUPPORTED: nptl/test-rwlock-printers
> UNSUPPORTED: nptl/test-rwlockattr-printers
> FAIL: nptl/tst-cancel7
> FAIL: nptl/tst-cancelx7
> UNSUPPORTED: posix/tst-glob_lstat_compat
> UNSUPPORTED: posix/tst-spawn4-compat
> UNSUPPORTED: resolv/tst-p_secstodate
> UNSUPPORTED: resolv/tst-resolv-ai_idn
> UNSUPPORTED: resolv/tst-resolv-ai_idn-latin1
> FAIL: resolv/tst-resolv-res_init
> FAIL: resolv/tst-resolv-res_init-thread
> Summary of test results:
> 11 FAIL
> 5920 PASS
> 19 UNSUPPORTED
> 19 XFAIL
>
> and for comparison also new rv64imafdc/lp64d results:
>
> FAIL: elf/tst-rtld-preload
> FAIL: elf/tst-tls12
> FAIL: io/ftwtest
> FAIL: libio/tst-wfile-sync
> FAIL: locale/tst-locale-locpath
> FAIL: malloc/tst-malloc-usable-tunables
> UNSUPPORTED: malloc/tst-mallocstate
> UNSUPPORTED: math/test-fesetexcept-traps
> UNSUPPORTED: math/test-fexcept-traps
> UNSUPPORTED: math/test-matherr
> UNSUPPORTED: math/test-matherr-2
> UNSUPPORTED: math/test-nearbyint-except-2
> UNSUPPORTED: misc/tst-pkey
> UNSUPPORTED: nptl/test-condattr-printers
> UNSUPPORTED: nptl/test-mutexattr-printers
> UNSUPPORTED: nptl/test-rwlockattr-printers
> FAIL: nptl/tst-cancel7
> FAIL: nptl/tst-cancelx7
> UNSUPPORTED: posix/tst-glob_lstat_compat
> UNSUPPORTED: posix/tst-spawn4-compat
> UNSUPPORTED: resolv/tst-p_secstodate
> FAIL: resolv/tst-resolv-res_init
> FAIL: resolv/tst-resolv-res_init-thread
> FAIL: stdlib/tst-strfrom
> FAIL: stdlib/tst-strfrom-locale
> Summary of test results:
> 12 FAIL
> 5925 PASS
> 13 UNSUPPORTED
> 19 XFAIL
>
> Both completed with a timeout factor of 600 in ~18.5 and ~19 hours
> respectively. I take it the reduction in the number of UNSUPPORTED test
> cases comes from the installation of the `pexpect' package on the test
> board, which I did having read your reference before the lp64d test run.
Please put these right into the wiki for the release:
https://sourceware.org/glibc/wiki/Release/2.30
It helps to have multiple references to know that people are testing
and posting results.
--
Cheers,
Carlos.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: RISC-V test results
2019-08-08 21:16 ` Carlos O'Donell
@ 2019-08-13 22:46 ` Maciej W. Rozycki
2019-08-14 20:19 ` Carlos O'Donell
0 siblings, 1 reply; 10+ messages in thread
From: Maciej W. Rozycki @ 2019-08-13 22:46 UTC (permalink / raw)
To: Carlos O'Donell
Cc: Joseph Myers, libc-alpha, Alistair Francis, DJ Delorie
On Thu, 8 Aug 2019, Carlos O'Donell wrote:
> Please put these right into the wiki for the release:
> https://sourceware.org/glibc/wiki/Release/2.30
>
> It helps to have multiple references to know that people are testing
> and posting results.
Done now then, good point! Thanks for the suggestion.
Maciej
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: RISC-V test results
2019-08-13 22:46 ` Maciej W. Rozycki
@ 2019-08-14 20:19 ` Carlos O'Donell
0 siblings, 0 replies; 10+ messages in thread
From: Carlos O'Donell @ 2019-08-14 20:19 UTC (permalink / raw)
To: Maciej W. Rozycki; +Cc: Joseph Myers, libc-alpha, Alistair Francis, DJ Delorie
On 8/13/19 6:45 PM, Maciej W. Rozycki wrote:
> On Thu, 8 Aug 2019, Carlos O'Donell wrote:
>
>> Please put these right into the wiki for the release:
>> https://sourceware.org/glibc/wiki/Release/2.30
>>
>> It helps to have multiple references to know that people are testing
>> and posting results.
>
> Done now then, good point! Thanks for the suggestion.
Much appreciated!
--
Cheers,
Carlos.
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2019-08-14 20:19 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-07-31 23:01 RISC-V test results Maciej W. Rozycki
2019-07-31 23:06 ` Joseph Myers
2019-08-01 13:28 ` Maciej W. Rozycki
2019-08-01 17:07 ` Joseph Myers
2019-08-05 14:24 ` Maciej W. Rozycki
2019-08-08 21:16 ` Carlos O'Donell
2019-08-13 22:46 ` Maciej W. Rozycki
2019-08-14 20:19 ` Carlos O'Donell
2019-07-31 23:31 ` DJ Delorie
2019-08-01 13:45 ` Maciej W. Rozycki
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).