RISC-V test results

RISC-V test results

[Maciej W. Rozycki]

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

Re: RISC-V test results

[Joseph Myers]

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

Re: RISC-V test results

[DJ Delorie]

"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.

Re: RISC-V test results

[Maciej W. Rozycki]

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

Re: RISC-V test results

[Maciej W. Rozycki]

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

Re: RISC-V test results

[Joseph Myers]

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

Re: RISC-V test results

[Maciej W. Rozycki]

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

Re: RISC-V test results

[Carlos O'Donell]

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.

Re: RISC-V test results

[Maciej W. Rozycki]

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

Re: RISC-V test results

[Carlos O'Donell]

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.