From: Joseph Myers <joseph@codesourcery.com>
To: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Cc: Arnd Bergmann <arnd@arndb.de>, Helmut Grohne <helmut@subdivi.de>,
GNU C Library <libc-alpha@sourceware.org>,
linux-arch <linux-arch@vger.kernel.org>,
metcalf@alum.mit.edu, Henrik Grindal Bakken <hgb@ifi.uio.no>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: RFC: remove the "tile" architecture from glibc
Date: Fri, 9 Mar 2018 16:53:02 +0000 [thread overview]
Message-ID: <alpine.DEB.2.20.1803091645580.8457@digraph.polyomino.org.uk> (raw)
In-Reply-To: <224c8996-bda1-5e75-bff3-9ed8abc4de87@physik.fu-berlin.de>
On Fri, 9 Mar 2018, John Paul Adrian Glaubitz wrote:
> On 03/09/2018 05:31 PM, Joseph Myers wrote:
> > Note that SH glibc test results need some work - there are a large number
> > of failures listed at <https://sourceware.org/glibc/wiki/Release/2.27#SH>.
> > Probably most could be addressed with the NaN fixes I outlined at
> > <https://sourceware.org/ml/libc-alpha/2018-02/msg00440.html> - but that
> > does of course need someone to do the work to implement that in GCC and
> > glibc. (The stdlib/tst-tininess failure is stranger; SH manuals don't
> > seem very specific on this, but the existing setting was definitely
> > determined by testing on hardware. SH experts with access to a range of
> > different hardware may be needed to advise on what different hardware does
> > or is supposed to do in this regard.)
>
> Ok, thanks for the explanation.
>
> On a sidenote: Is there documentation somewhere which explains how to properly
> run the glibc testsuite? I would then go ahead and run it on my Amiga 4000
> for m68k.
"make check", or "make -k check" if you're concerned about some tests
failing to build (e.g. the compiler running out of memory on a few large
tests) - the testsuite should continue after execution failures, but not
after compilation failures. (Having previously configured with
--prefix=/usr for the build. And if the compiler used doesn't have
libgcc_s and libstdc++ shared libraries in directories ld.so searches by
default, you should copy those libraries into the glibc build directory
before running tests.) On a system that can handle it you'd use an
appropriate -jN option for parallelism, but probably not on m68k.
For cross testing over SSH (when glibc is running on a system that is very
slow running the compiler or has too little memory to do so) you need a
shared filesystem at the same path on both the system where glibc is built
and the system where tests will execute (probably NFS-exported from the
build system, and it may be necessary to mount it on the test system with
acdirmax=0,acdirmin=0 to limit any caching). Then you can pass
test-wrapper="/path/to/glibc/scripts/cross-test-ssh.sh <host>" to make
check.
In both cases, for very slow test systems you may wish to export
TIMEOUTFACTOR (an integer by which all test timeouts are multiplied).
--
Joseph S. Myers
joseph@codesourcery.com
next prev parent reply other threads:[~2018-03-09 16:53 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1a57be83-3349-5450-ee4f-d2a33569a728@mellanox.com>
[not found] ` <d6c8e425-a6b6-6594-05e3-965536f06da3@physik.fu-berlin.de>
[not found] ` <abce89d0-6798-069a-1a54-06e664665b78@mellanox.com>
[not found] ` <dc3c52ce-f082-0da0-7828-0d4e6751e2a5@physik.fu-berlin.de>
2018-03-07 15:39 ` RFC: remove the "tile" architecture from glibc Arnd Bergmann
2018-03-07 15:39 ` Arnd Bergmann
2018-03-07 16:00 ` Joseph Myers
2018-03-07 16:00 ` Joseph Myers
2018-03-07 16:08 ` John Paul Adrian Glaubitz
2018-03-07 16:08 ` John Paul Adrian Glaubitz
2018-03-07 18:14 ` Helmut Grohne
2018-03-07 18:14 ` Helmut Grohne
2018-03-08 15:55 ` Arnd Bergmann
2018-03-08 15:55 ` Arnd Bergmann
2018-03-08 16:06 ` John Paul Adrian Glaubitz
2018-03-08 16:06 ` John Paul Adrian Glaubitz
2018-03-08 16:23 ` Arnd Bergmann
2018-03-08 16:23 ` Arnd Bergmann
2018-03-09 16:31 ` Joseph Myers
2018-03-09 16:31 ` Joseph Myers
2018-03-09 16:37 ` John Paul Adrian Glaubitz
2018-03-09 16:37 ` John Paul Adrian Glaubitz
2018-03-09 16:53 ` Joseph Myers [this message]
2018-03-09 16:53 ` Joseph Myers
2018-03-08 17:14 ` Palmer Dabbelt
2018-03-08 17:14 ` Palmer Dabbelt
2018-03-08 23:36 ` Arnd Bergmann
2018-03-08 23:36 ` Arnd Bergmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.20.1803091645580.8457@digraph.polyomino.org.uk \
--to=joseph@codesourcery.com \
--cc=arnd@arndb.de \
--cc=glaubitz@physik.fu-berlin.de \
--cc=helmut@subdivi.de \
--cc=hgb@ifi.uio.no \
--cc=libc-alpha@sourceware.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=metcalf@alum.mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox