From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.12]) by sourceware.org (Postfix) with ESMTPS id 000583A1AC44 for ; Sat, 6 Feb 2021 00:40:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 000583A1AC44 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=SystematicSw.ab.ca Authentication-Results: sourceware.org; spf=none smtp.mailfrom=brian.inglis@systematicsw.ab.ca Received: from [192.168.1.104] ([24.64.172.44]) by shaw.ca with ESMTP id 8BeIlQNh0eHr98BeKlmQkr; Fri, 05 Feb 2021 17:40:32 -0700 X-Authority-Analysis: v=2.4 cv=Yq/K+6UX c=1 sm=1 tr=0 ts=601de580 a=kiZT5GMN3KAWqtYcXc+/4Q==:117 a=kiZT5GMN3KAWqtYcXc+/4Q==:17 a=IkcTkHD0fZMA:10 a=axDLF4JMAAAA:8 a=8pif782wAAAA:8 a=wU2JPNmvdgT24ZyQSXsA:9 a=QEXdDO2ut3YA:10 a=PAvEFfIi8YbDbmX8zHlT:22 Reply-To: newlib@sourceware.org To: newlib@sourceware.org References: From: Brian Inglis Organization: Systematic Software Subject: Re: accuracy of mathematical functions Message-ID: <674c2347-c833-150d-3e4a-8e3867ada8a4@SystematicSw.ab.ca> Date: Fri, 5 Feb 2021 17:40:30 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-CA Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4xfOqYvqn7I4e91BE5wD/DB0a0Bp59niu5hZYWThEJKdT1R8J/k6nyGX5USUAs2/oRcJt2yfWP879kncQfpHxJbSxXuo3YUFL5KrWPErBFVSwgIksRckVt mSzquj+TkFnPSn7iW6mkZ2QGxErwWT2hQnj5GhnXKCyCSnGgxPHumrMS1C+5eLVBd5uEms8c1Ml0ZMNH7Mnt1uKR/sxQdmMsbNM= X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: newlib@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Newlib mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Feb 2021 00:40:35 -0000 On 2021-02-05 16:46, Joel Sherrill wrote: > On Fri, Feb 5, 2021 at 5:01 PM Brian Inglis wrote: >> On 2021-02-05 03:43, Paul Zimmermann wrote: >>> I have updated my comparison with the newly released 2.33 version. >>> No big difference with the previous version, except that I included >>> the "long double" format (aka ldbl-96), which is not supported by Newlib. >>> >>> https://members.loria.fr/PZimmermann/papers/#accuracy >> >> Thanks for doing this work and making it available is greatly appreciated. >> >> While newlib is mainly targeted to smaller platforms, the Cygwin port math >> library supports gcc __FLT64X_...__/__FLT128_...__ under >> .../newlib-cygwin/winsup/cygwin/math/ and related includes. > Any thoughts on what's required to have long double support on the targets > where long double != double? Someone was recently cleaning up the warnings > from the RTEMS tests which check that the headers match POSIX's man page and > I generated this list of architectures from the RTEMS tools and which have > long double support in libm.a > > no aarch64-rtems6 > yes arm-rtems6 > yes bfin-rtems6 > no i386-rtems6 > yes lm32-rtems6 > no m68k-rtems6 > yes microblaze-rtems6 > yes mips-rtems6 > yes moxie-rtems6 > yes nios2-rtems6 > yes or1k-rtems6 > yes powerpc-rtems6 > no riscv-rtems6 > yes sh-rtems6 > no sparc64-rtems6 > yes sparc-rtems6 > yes v850-rtems6 > no x86_64-rtems6 > > It probably is a decent GSoC project if upstream sources for long double on > some of those architectures can be identified for potential incorporation. ARM aarch64 probably have c and S sources available, maybe recent PowerPC. Cygwin sources appear to be from mingw-w64 and are PD, ZPL, or unspecified: $cd ~/src/newlib-cygwin/winsup/cygwin/math/ $ egrep -c 'Zope|PD' *l.* | pr -4th "" acoshl.c:1 complex_internal. floorl.S:1 nearbyintl.S:1 acosl.c:1 conjl.c:1 fmal.c:1 nextafterl.c:1 asinhl.c:1 copysignl.S:1 fmaxl.c:1 pow10l.c:0 asinl.c:1 coshl.c:1 fminl.c:1 powil.c:1 atan2l.c:1 cosl.c:1 fmodl.c:1 powl.c:1 atanhl.c:1 cosl_internal.S:1 frexpl.S:1 remainderl.S:1 atanl.c:1 cpowl.c:1 ilogbl.S:1 remquol.S:1 cabsl.c:1 cprojl.c:1 internal_logl.S:1 rintl.c:1 cacosl.c:1 creal.def.h:1 ldexpl.c:1 roundl.c:1 cargl.c:1 creall.c:1 lgammal.c:1 scalbl.S:1 casinl.c:1 csinl.c:1 llrintl.c:1 scalbnl.S:1 catanl.c:1 csqrtl.c:1 llroundl.c:1 sinhl.c:1 cbrtl.c:1 ctanl.c:1 log10l.S:1 sinl.c:1 ccosl.c:1 erfl.c:1 log1pl.S:1 sinl_internal.S:1 ceil.S:1 exp10l.c:0 log2l.S:1 sqrtl.c:1 ceill.S:1 exp2l.S:1 logbl.c:1 tanhl.c:1 cexpl.c:1 expl.c:1 logl.c:1 tanl.S:1 cimagl.c:1 expm1l.c:1 lrintl.c:1 tgammal.c:1 clog10l.c:1 fabsl.c:1 lroundl.c:1 truncl.c:1 clogl.c:1 fdiml.c:1 modfl.c:1 $ head ???10l.c ==> exp10l.c <== #undef exp10l #include long double exp10l (long double x) { return powl (10.0L, x); } ==> pow10l.c <== #undef pow10l #include long double pow10l (long double x) { return powl (10.0L, x); } >> As you may already be aware, clang and gcc have added support for ARM >> __FLT16/__fp16, AMD and Intel have added it to x86/amd64 as CVT16/FP16C >> https://en.wikipedia.org/wiki/F16C, and more compiler and library support >> are likely to follow, as they are already used in graphics and GPGPU >> areas. > > What would this require from newlib, if anything? He asks ignorantly. :) More of a comment to the OP for future exhaustive testing. Indication of demand or need; arch and compiler support; adopt/adapt software library? -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.]