From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-f51.google.com (mail-ot1-f51.google.com [209.85.210.51]) by sourceware.org (Postfix) with ESMTPS id AEFE63858D28 for ; Thu, 18 Aug 2022 19:31:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org AEFE63858D28 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-ot1-f51.google.com with SMTP id t11-20020a05683014cb00b0063734a2a786so1722563otq.11 for ; Thu, 18 Aug 2022 12:31:57 -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=iV03K4RS48MtbfBCcTgN6pqUJCGb/O+X5QE09iHVo9g=; b=QujVyehgHMkMC/YqqLZ5p6J30LomPFCVQ2giNsTatsIetPOIr3ZXbgSKAklvuegeRc oVqR+5FD2C4Mv8uGs+zQ9KuYhc2k+EjLMgUdAX+ZhPQEjdL4+tIahyvCsIBBxjYNJwbv 7SuPE3c4zCyZEhE/bJevHcOCqd8AjT9B3SOpaf8jO5lJ1iGl4vEmGRZs+RbnFi2U6Boy Yo6iR6gquh5NRz49uATihnObZ4DEu5ce67wqJrMlEeb1qCgIxcPNE6a1I+aRi8jdYmtl 2nRajXdLdU7o5TgzgbNj1925i0grOEYD6vQf9qQNmL6HaiRTINAG4MOmiS+lCpNsovZM Qz0Q== X-Gm-Message-State: ACgBeo00o0mSNa0mx69K4KGNtEg9CYyB3zrPsff7WpKzAra+qr1atvdY +msbU4cVPwsvSRVY4lrJASqpLeOK4b0= X-Google-Smtp-Source: AA6agR4pDpXW/GEruKHJyIeb/Ck5H/6vF3Da6abJzUXLUdGyW10O7exziX774IPd8JDjBaplzTsXCA== X-Received: by 2002:a05:6830:3142:b0:638:d079:74fd with SMTP id c2-20020a056830314200b00638d07974fdmr1703683ots.129.1660851116778; Thu, 18 Aug 2022 12:31:56 -0700 (PDT) Received: from mail-ot1-f41.google.com (mail-ot1-f41.google.com. [209.85.210.41]) by smtp.gmail.com with ESMTPSA id n25-20020a05680803b900b00342e14a96d5sm548744oie.25.2022.08.18.12.31.56 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 18 Aug 2022 12:31:56 -0700 (PDT) Received: by mail-ot1-f41.google.com with SMTP id h20-20020a056830165400b00638ac7ddba5so1745335otr.4 for ; Thu, 18 Aug 2022 12:31:56 -0700 (PDT) X-Received: by 2002:a9d:6a4d:0:b0:638:9c7b:40fe with SMTP id h13-20020a9d6a4d000000b006389c7b40femr1674849otn.37.1660851116006; Thu, 18 Aug 2022 12:31:56 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Reply-To: joel@rtems.org From: Joel Sherrill Date: Thu, 18 Aug 2022 14:31:45 -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.7 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 19:32:00 -0000 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 > >