From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 75510 invoked by alias); 29 Jun 2017 16:31:23 -0000 Mailing-List: contact newlib-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: newlib-owner@sourceware.org Received: (qmail 75407 invoked by uid 89); 29 Jun 2017 16:31:22 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=H*r:ip*192.168.2.2, H*r:0500 X-HELO: OARmail.OARCORP.com Received: from oarmail.oarcorp.com (HELO OARmail.OARCORP.com) (67.63.146.244) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 29 Jun 2017 16:31:20 +0000 Received: from [192.168.1.168] (192.168.1.168) by OARmail.OARCORP.com (192.168.2.2) with Microsoft SMTP Server (TLS) id 8.3.389.2; Thu, 29 Jun 2017 11:31:19 -0500 Subject: Re: Long double complex methods To: Joseph Myers CC: Dionna Amalie Glaze , Aditya Upadhyay , "newlib@sourceware.org" References: From: Joel Sherrill Message-ID: <3016e298-4acf-9edc-1f8e-31f2ef040bd7@oarcorp.com> Date: Thu, 29 Jun 2017 16:31:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2017/txt/msg00527.txt.bz2 On 6/29/2017 11:18 AM, Joseph Myers wrote: > On Wed, 28 Jun 2017, Joel Sherrill wrote: > >> Also, although I don't know how to run them, doesn't someone >> run glibc tests on newlib? They likely have tests for this for >> newlib's purposes. > > It would be interesting to see results of glibc libm tests (current git > please, there have been major changes since the last release) for a range > of libm implementations and operating systems, but also probably a lot of > work to get them building with other C libraries; they make plenty of use > of glibc features, include some internal glibc headers for configuration > of some details of the architecture, and hardcode glibc choices of goals > for errno, exceptions and accuracy that other libm implementations may > differ on. An implementation/architecture-specific libm-test-ulps file > also needs to be generated before you can expect clean results even for an > implementation following glibc's goals. > That would be interesting. In theory, we should be able to mimic the internal glibc .h files. The devil is in the detail. My first order problem is that I have never seen the procedure for running glibc tests against a newlib based toolset for any newlib target -- embedded, Cygwin, or Linux. Heck.. as I posted earlier, I don't even know what to do to run the tests inside the newlib tree. :( -joel