From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa1-f45.google.com (mail-oa1-f45.google.com [209.85.160.45]) by sourceware.org (Postfix) with ESMTPS id 444B13858422 for ; Thu, 18 Aug 2022 14:49:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 444B13858422 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-f45.google.com with SMTP id 586e51a60fabf-10cf9f5b500so2045047fac.2 for ; Thu, 18 Aug 2022 07:49:28 -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=Vfz8pAYccR63PD+y8wtn63uORQtTw7QJjDG/7HH4PgA=; b=Z38Ythg5pHevA3c/WVNffQ0//xB1eg3xlaRKhqLqwfbYt+jKw6fNbeL0Px5InFua+D Yk8f+oZrbjIV/DZ2juYafB2L0WJgn2Z6GOlEctar3qZZ4GG69B/Xt8eeQF3Uh+vQz6rw Y7KHdu0/4WeuNBBcy06iFPEw4lOYNbRr588sVHzz5hGLKIOJhKcs93sQckgnsUnVKOYH ZghVt28eDN1Meb8kAhkqnylpw58kZoQcp0ZyLSBE7Seqq6gEsXXQ83DatssfrMvrRSfk uXNqExj6M1FZ5tSv799DssZmnkjDa6INNb+HHk0gvc3MeUX4tiT1ENEHW7LUinfcavUk HDoA== X-Gm-Message-State: ACgBeo3fBUvE3qZ6yWFdNlU22hDYnHA8x30H3018fKbvtSbGtk66iUwg hn32xmZ1XYdajq+8MYTjdNjb6uUUHIs= X-Google-Smtp-Source: AA6agR6fCbijpBn4Ge/sO6Q/YBGQpFLa/qELujvYSEJAj+cUcqKM6rd43pwaI/F0qf3ePWWpqjfNMw== X-Received: by 2002:a05:6871:810:b0:10e:ecbb:a077 with SMTP id q16-20020a056871081000b0010eecbba077mr1647457oap.22.1660834166762; Thu, 18 Aug 2022 07:49:26 -0700 (PDT) Received: from mail-ot1-f43.google.com (mail-ot1-f43.google.com. [209.85.210.43]) by smtp.gmail.com with ESMTPSA id z26-20020a9d7a5a000000b00638ab4c953asm438481otm.74.2022.08.18.07.49.26 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 18 Aug 2022 07:49:26 -0700 (PDT) Received: by mail-ot1-f43.google.com with SMTP id h20-20020a056830165400b00638ac7ddba5so1244494otr.4 for ; Thu, 18 Aug 2022 07:49:26 -0700 (PDT) X-Received: by 2002:a05:6830:2787:b0:60c:33b4:f374 with SMTP id x7-20020a056830278700b0060c33b4f374mr1202050otu.295.1660834165946; Thu, 18 Aug 2022 07:49:25 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Reply-To: joel@rtems.org From: Joel Sherrill Date: Thu, 18 Aug 2022 09:49:15 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Revisiting More Complete long double Support To: Newlib Content-Type: multipart/mixed; boundary="0000000000007e37d305e6851639" X-Spam-Status: No, score=-3031.8 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 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 14:49:31 -0000 --0000000000007e37d305e6851639 Content-Type: text/plain; charset="UTF-8" On Thu, Aug 18, 2022 at 2:57 AM Corinna Vinschen wrote: > On Aug 17 17:06, Joel Sherrill wrote: > > Hi > > > > I'm looking at newlib long double support again when sizeof(long double) > != > > sizeof(double). > > > > (1) Merged FreeBSD C code for long double math > > > > FreeBSD has C code for long double math routines as default > implementation: > > > > https://github.com/freebsd/freebsd-src/tree/main/lib/msun/src > > > > I **THINK** those will work if LDBL != DBL so that code might need the > > ifdef for LDBL_EQ_DBL to pick the current newlib common implementation of > > the method which just calls the normal version of the method. I code > even > > add the files as XXX_freebsd.c and only add > > > > 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. What about two directories of long double implementations. One is for _LDBL_EQ_DBL and the other is the FreeBSD code. I think libm/Makefile.inc already has an example of picking one of two directories based on an automake flag. Adding one for to reflect _LDBL_EQ_DBL and picking either one of the two long double math implementation directories should work. Names are always an issue. I have no ideas for good names for the directories. Something somewhat horrible like common/ldbl_eq_double and common/ldbl are the best I have. > If we just merge the long double code from FreeBSD's lib/msun/src > into our libm/common dir... > Maybe a subdirectory or parallel directory so we can keep the _LDBL_EQ_DBL where it is needed. > > > (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? --joel > > > Corinna > > --0000000000007e37d305e6851639 Content-Type: application/octet-stream; name="has_long_double.tar.xz" Content-Disposition: attachment; filename="has_long_double.tar.xz" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_l6z5e27c0 /Td6WFoAAATm1rRGAgAhARYAAAB0L+Wj4E//BcldADQYSsxyB3RJoBKR+1k2F+z4xTA5ivt43c9E JT98NSOHfVHRhmN/yoCAR/NnnkVewKDeChCNJvG+hJXwyrTFSPGJy2FH0DNypOKLQsXO0awdJGnV G4ty9xSZHdAb/ULONUb1CM+xgkg+dZklAGl9snCCogjpfmuiqiJsa4Lq6UFrUlW88QzNah68GWY0 o4XrOD75hndKiI6QBPQEVEiiGdfimWA5Ntb5cNV6UQLhAHCkZUjynN5UvLq4z0+FGhX302NnLwYL GHUPbJ4iHs3D4D1l1DvzXviklH15a/1i8G91jPZYlmwSdASRya8ccXwVCXqOKa/++3M6XYi7GqZR DQckVUCXg+niCneQ42RRSY4+FmEv14qYXxwtrmFJ6S3O22Ho2PQwmXrWpYfLWtNQN5KWTJlYO9rK dc2A00wpODrbfW2kl0x4zSE7nst224Z98/jY/JP4nmou1c4l78Ndlg6ogJXUH5v6OUE/bQB+tyPv BbGEaKpm2h9Sl3Meu0nT0Qgg+3acwtDUGSojHRcfFv/FhQRsZxiXieT8xP/tjRPsM7b0A6O2Sbj0 /fr5x7XUzq+azoWbGuRxlXlX1fB4X3FVh/rrRZ1X/F8KseQzJtGxNfS6Xp/W7pnFG3J8VMG9F6vg 0jKSQEeUMNWZ8ptF84zdTYvG7hOySJStH33reO+FBjSL6zbHf9sMuAUBV0cRlouOkjcL9nuz7VmX DFnDWBBsupnxYN/mgOxCuIbIkKAnRuqavSVwRZ5VD2++eFC2ngfVi50KXFuF3czEooRQQKZxtpdZ mncJl0movExyMagE21Kmk/UB7dH6RHJ2/hTVW8deUG/BZXMu5F6SlBY0bPeLO/rxEtUR62+opOU3 VBfrQCwoRml6JI8Ok5ueyKMDaAqM5bM7KhgZffi2jYzjHeVlk0ydm6jg1GNh9kaXxuDlM8bxgCbD KtGFGa8MnT7ApcQAwjMO/GusFyZ3VUvS193KudsXBU9fDR72opoXWc+HD3sDuVgTP7ijGRWuV70r rDX6+21OGxnqpZkUv4+828cjLXhHHl5FW3se9bluwWmjdqMtcyQa/c8eL4pvqDIwQ2fJEqblYRkS 6+NTORgqnvmHc07qDaybCOHJxr6iuWdN9haRj1uT2SW8VmE+GozA7er1V90kqi3tSsZSUWRT7YFX C6IllrVR3D/L6mCPY1x5Y+6R08YAvDE+h2aN5byZssHNNaVSHkTOx1CV5GRoaPj5P3w28r6Yhur2 VaHoTIXXOZRUqXzAu6/vppsJJPgL3Nzq+zgvhEdQdMwSxS8B9Py1nhAmHgqx847Kr36MUwsuJTFO +1yzDxQH+8EPjfiPqevjBXAZlVDn35kq5enVjTJl3EXyWpFQcPu0aGYXHYfNELUmneAwYKx8Zhrk 0XeBZp3xSGgs8G8GXmT6Y3gfSdVKWSaBsPJJVL/XpcF+eR/cWMGYqQHdqWjnSe/TRBzf9lbRu/3X nnTmopIrskcAEQKdcz8CclbxAnduN+TruaIlbK2KFYu1DQZ8CFLuZmz1vNIDKx4XpQs36Ywm8e17 4m6VQLlLU8n5IQHc4tlDs4FYBIN+Z3NK0XT5TMIS9ugZFIiuJ4F22JLZKZsmOnMsnIEMOP9y7UE3 1d4+FTdmEE7Lz9VbTCaSbNSy5eLXGnOA3VEJ0eTdmZpLE2R+t6JQX9RgAdaAnwueXAcTbYh6nJUp 4clzcHPEtaz+D2XZxKlesQ1Kb0a1gwWM3XpR7gnKQj+jDxtpSz/0kkWmR7TyqggQeMOZae8RmNk8 reL0BwmEEnV4qD10vepsC53eXzIJIc3KNGwBjh7zORqsGpzr3qcGJLWXV7zBdtLy21NoU+YohEud cP91yV57QA2JeHCEG83KICEOJYm1dTXFfwzhjgMeGPjsaaVm60jPCI16UnYEo+/Cc69DRTsNbnAy 3EaRsLYVp3218DoBYnzOn8Da9tbjUq5tLYfFaU4IAAAAAAHa4BkAH/4SAAHlC4CgAQDntTbfscRn +wIAAAAABFla --0000000000007e37d305e6851639--