From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa1-f49.google.com (mail-oa1-f49.google.com [209.85.160.49]) by sourceware.org (Postfix) with ESMTPS id BE1C63858D28 for ; Thu, 18 Aug 2022 22:16:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BE1C63858D28 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=rtems.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-oa1-f49.google.com with SMTP id 586e51a60fabf-11cb3c811d9so1678528fac.1 for ; Thu, 18 Aug 2022 15:16:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:reply-to:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=TLuRIGA/b/OJxP/hr32QoFx8l2fHcKNm5rGRJZAA9ug=; b=rrQHBAHPhU0WK46wuD6Bm1igftRnPVriqhaopC7FR+f7XFWgRqzWpY6mI0LJTVtVb4 kVMs+LakI9DLG5sOP8FhAapGr6G7dypNrMEfIT6uQmwG3wxL3MzVIDecrc7o0iuxFXeH a3iQ92xQ8w7z8E1CkE/FEJJZ0zmxkxHnRpEPvH0TY7pTkyx7WyttmWOf5s3oMgLVrCSy unU/KUHuMP+fwF7km7uCjIHufNirRVJMQDCP7rYuDBKA4I8tRm54XdkTMbJMxWR29EGS zslS2Froclr34OO2xbBtQwz5m24NhnU3+B+UyNM0AengogQ9PfKxyvVZaVJ4XZR3NaM2 Lz9g== X-Gm-Message-State: ACgBeo38Sq4FTEYL7+97wGuJpT+vAQJ7Rk4ceRBodaOwjKAJKXsSlPMk I8wDszfOwxf2Rius39M8JFNJmXcJPIk= X-Google-Smtp-Source: AA6agR6WvQbwHVMEqWKPAmYH+W2fkHamTBEC6B/y79rUxrNK0TJc2MRCLnrP3SnarjPjoG6HyXroPw== X-Received: by 2002:a05:6870:ea01:b0:116:861f:6e55 with SMTP id g1-20020a056870ea0100b00116861f6e55mr5022441oap.285.1660860993751; Thu, 18 Aug 2022 15:16:33 -0700 (PDT) Received: from mail-oi1-f169.google.com (mail-oi1-f169.google.com. [209.85.167.169]) by smtp.gmail.com with ESMTPSA id cp19-20020a056830661300b0061cd208fadesm691088otb.71.2022.08.18.15.16.33 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 18 Aug 2022 15:16:33 -0700 (PDT) Received: by mail-oi1-f169.google.com with SMTP id u9so2978509oiv.12 for ; Thu, 18 Aug 2022 15:16:33 -0700 (PDT) X-Received: by 2002:a05:6808:144b:b0:343:8421:c737 with SMTP id x11-20020a056808144b00b003438421c737mr2163572oiv.15.1660860993034; Thu, 18 Aug 2022 15:16:33 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Reply-To: joel@rtems.org From: Joel Sherrill Date: Thu, 18 Aug 2022 17:16:22 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Revisiting More Complete long double Support To: Newlib , Joel Sherrill X-Spam-Status: No, score=-3031.6 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, HTML_MESSAGE, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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: Thu, 18 Aug 2022 22:16:37 -0000 I've dug in a bit and tried to bring in one function. Found a few things that are going to shape the solution: (1) Newlib and FreeBSD do not agree on filenames. truncl.c gets replaced by s_truncl.c (a) Great work on the new build system. :) (2) FreeBSD long double methods rely on _fpmath.h to define the long double format. It doesn't have to be 128 bits for the code to work. But only a handful of architectures have this file: aarch64 amd64 arm i386 mips powerpc powerpc64 riscv sparc64 This file would go in libc/machine/... I think based on the FreeBSD source layout. (3) I think my suggestion to have the default implementation and then this implementation in parallel and then select the appropriate one at configure time. For the architectures with _fpmath.h, the new FreeBSD implementation can be used. For others, architectures the old implementation could be used. Unfortunately, I started working with sparc which does not have an _fpmath.h. I will try one of the architectures with _fpmath.h tomorrow. But it looks like a wholesale update isn't going to work out. I want to get one long double method building for an architecture with and one without _fpmath.h with whatever structure we decide on before I start repeating that. Thoughts? --joel --joel On Thu, Aug 18, 2022 at 2:31 PM Joel Sherrill wrote: > > > On Thu, Aug 18, 2022 at 2:16 PM Corinna Vinschen > wrote: > >> On Aug 18 09:49, Joel Sherrill wrote: >> > On Thu, Aug 18, 2022 at 2:57 AM Corinna Vinschen wrote: >> > > On Aug 17 17:06, Joel Sherrill wrote: >> > > > [...] >> > > > ifdef _LDBL_EQ_DBL >> > > > long double >> > > > acosl (long double x) >> > > > { >> > > > return acos(x); >> > > > } >> > > > #else >> > > > #include "acosl_freebsd.c" >> > > > #endif >> > > > >> > > > which would definitely avoid edits to the FreeBSD source. >> > > >> > > Question is, do we really still need this? >> > > >> > > These #ifdef have been added just as a cheap workaround for small >> > > targets, because nobody provided the actual long double >> implementations, >> > > yet. If we merge the actual long double implementations from FreeBSD, >> > > there's no need for this anymore and we can probably drop the >> > > _LDBL_EQ_DBL flag entirely. >> > >> > I think that's hopeful thinking although I like the idea of importing >> the >> > FreeBSD code. I have attached a slightly updated version of the script >> > I used to probe which targets were _LDBL_EQ_DBL. Two yes'es means >> > that _LDBL_EQ_DBL implementation is used. Two no's means that >> > it needs a real long double implementation -- if my script and probe >> program >> > are correct. >> > >> > has_long_double]$ sh j >> > TARGET in lib ldbl=dbl >> > ================= ====== ======== >> > aarch64-rtems6 no no >> > arm-rtems6 yes yes >> > bfin-rtems6 yes yes >> > i386-rtems6 no no >> > lm32-rtems6 yes yes >> > m68k-rtems6 no no >> > microblaze-rtems6 yes yes >> > mips-rtems6 yes yes >> > moxie-rtems6 yes yes >> > nios2-rtems6 yes yes >> > or1k-rtems6 yes yes >> > powerpc-rtems6 yes yes >> > riscv-rtems6 no no >> > sh-rtems6 yes yes >> > sparc64-rtems6 no no >> > sparc-rtems6 yes yes >> > v850-rtems6 yes yes >> > x86_64-rtems6 no no >> > >> > Hopefully that aligns ok on your side. Most of the targets seem to be >> able >> > to legitimately use the current _LDBL_EQ_DBL implementations. >> >> They might be able to use it, but if so, they are only able to do so >> since 2009. It was really just a cheap trick to allow calling long >> double functions on targets which don't require a real long double lib. >> As you may remember, it's not the first time we talk about long double >> functions... >> > > Yeah. I have been tracking newlib/RTEMS against various FACE > Technical Standard POSIX profiles. fenv was also part of the missing > functionality. The long double math is the bulk of what's left to address. > >> >> However, if we have a *real*, generic implementation of all long double >> functions, there's just no need to keep up with the _LDBL_EQ_DBL hackery. >> > > Agreed. If the FreeBSD code works when _LDBL_EQ_DBL and when it isn't. > I honestly can't tell by looking at the FreeBSD e_acosl.c, > > I'll put it in my todo list to experiment to see what happens just > replacing it. > > If someone sees an obvious problem, please speak up. > > If it doesn't work, then falling back to the current implementations may > be > needed. But we can try to avoid it. > >> >> > > > (2) More i386 assembly versions >> > > > >> > > > Then there appears to be some long double methods for the i386/87 >> here >> > > > which newlib doesn't currently have: >> > > > >> > > > https://github.com/freebsd/freebsd-src/tree/main/lib/msun/i387 >> > > > >> > > > Thoughts on adding this long double code from FreeBSD? >> > > >> > > ...and merge the occasional CPU-specific assembler code from >> > > FreeBSD's lib/msun/ into our libm/machine/ dir, that >> > > should work nicely. >> > > >> > >> > :) >> > >> > I think you've said in the past that Cygwin has these but the >> > calling conventions are different. Is that something that has to >> > be taken into account in newlib? >> >> No worries. It wouldn't matter for i386, but we dropped 32 bit support >> in master anyway. For x86_64, Cygwin uses the Windows AMD64 calling >> convention, so we can't use the assembler functions using the standard >> calling convention there. >> >> As a side note, I added x86_64 assembler memcpy/memset functions from >> FreeBSD to Cygwin at one point. The code is untouched, I just added >> wrapper code which reshuffles the arg registers according to the >> different calling conventions. >> >> That could help using the FreeBSD x86_64 long double functions for >> Cygwin, too, using wrapper macros or something like that. However, the >> Mingw64 long double functions work nicely for a couple of years, so >> there's no reason to force this. We're sticking to the Mingw64 >> functions in Cygwin for the time being. >> >> >> Corinna >> >>