From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 102417 invoked by alias); 9 Mar 2018 16:53:10 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 102403 invoked by uid 89); 9 Mar 2018 16:53:09 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS,URIBL_RED autolearn=ham version=3.3.2 spammy= X-HELO: relay1.mentorg.com Date: Fri, 09 Mar 2018 16:53:00 -0000 From: Joseph Myers To: John Paul Adrian Glaubitz CC: Arnd Bergmann , Helmut Grohne , GNU C Library , linux-arch , , Henrik Grindal Bakken , Linux Kernel Mailing List Subject: Re: RFC: remove the "tile" architecture from glibc In-Reply-To: <224c8996-bda1-5e75-bff3-9ed8abc4de87@physik.fu-berlin.de> Message-ID: References: <1a57be83-3349-5450-ee4f-d2a33569a728@mellanox.com> <20180307181407.GA24350@alf.mars> <9a60ac70-21e4-3f48-5cd7-ffd3aabc5c21@physik.fu-berlin.de> <224c8996-bda1-5e75-bff3-9ed8abc4de87@physik.fu-berlin.de> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-ClientProxiedBy: svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-SW-Source: 2018-03/txt/msg00243.txt.bz2 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 . > > Probably most could be addressed with the NaN fixes I outlined at > > - 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 " 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