From nobody Mon Nov 01 00:47:49 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 2FD1A182BE4C for ; Mon, 1 Nov 2021 00:47:54 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HjDsN1f51z4gJX for ; Mon, 1 Nov 2021 00:47:51 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 1A10lntC084157 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Sun, 31 Oct 2021 17:47:49 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 1A10lnFe084156 for freebsd-current@freebsd.org; Sun, 31 Oct 2021 17:47:49 -0700 (PDT) (envelope-from sgk) Date: Sun, 31 Oct 2021 17:47:49 -0700 From: Steve Kargl To: freebsd-current@freebsd.org Subject: Re: access to ld128 system Message-ID: <20211101004749.GA84142@troutmask.apl.washington.edu> References: <20211028222851.GA24101@troutmask.apl.washington.edu> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211028222851.GA24101@troutmask.apl.washington.edu> X-Rspamd-Queue-Id: 4HjDsN1f51z4gJX X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=washington.edu (policy=none); spf=none (mx1.freebsd.org: domain of sgk@troutmask.apl.washington.edu has no SPF policy when checking 128.95.76.21) smtp.mailfrom=sgk@troutmask.apl.washington.edu X-Spamd-Result: default: False [-0.98 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.96)[-0.957]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.99)[-0.992]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_SHORT(0.97)[0.973]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[washington.edu : No valid SPF, No valid DKIM,none] X-ThisMailContainsUnwantedMimeParts: N On Thu, Oct 28, 2021 at 03:28:51PM -0700, Steve Kargl wrote: > kib@ recently committed my implementations of cospi[fl], > sinpi[fl], and tanpi[fl]. These functions have been > extensively tested for float, double, and long double > where long double is the Intel 80-bit long double (e.g., > msun/ld80/s_sinpil.c). The 128-bit versions of these > routines have not been tested (e.g., msun/ld128/s_sinpil.c) > > kib pointed me to a system in the FreeBSD, which I have > access to. Unfortunately, that system has double == > long double, and can only test the support for the > weak references. > > Is there a system with 128-bit long double that I can > have access for some testing? > FYI. An individual has provided access to an aarch64 system. A patch has been submitted to fix the ld128 sinpi, cospi, and tanpi. For the record, I did limited testing to not overwhelm the system. The observed max ULP for sinpi and cospi were less than 1.1 ULP, which is slight worse that the desired less than 1 ULP target. This has been traced to the kernel for computing cosl() in the interval [0,pi/4]. I suspect the minmax polynomial coefficients need refinement. -- Steve