From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw1-f171.google.com (mail-yw1-f171.google.com [209.85.128.171]) by sourceware.org (Postfix) with ESMTPS id 9FE6C3858D20 for ; Wed, 5 Apr 2023 21:35:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9FE6C3858D20 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-yw1-f171.google.com with SMTP id 00721157ae682-545e907790fso587239907b3.3 for ; Wed, 05 Apr 2023 14:35:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680730509; x=1683322509; h=cc:to:subject:message-id:date:from:reply-to:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=BJB6CtRgnvL2CZHEjldeOCLAW7el/nMiWqMpTssrbXs=; b=xgBZ+yKfa0Hu0PZQf52uSld6/uUUs/jFinpc7/lx6REfKtvCHCyIOCX9MFA8tCyTjK 9lcs82STj4juHcmiaVII2Z5BUWjugi+aWXPVGbGizJ4eEmW3FYIY7Prs/pn6ukXhsT87 R+Uug/iVCG3Allcv217hGyLNVVVDBb+S280EXmTYvQQi32HXiVsHUqb2mswtxnUuqwE7 nqlJeXmr8HjdkXLt9yBneLVPkDOnknefx9RD1W0hxF32ve6M7bOV2IhzDnJR7KK4LzaP 9Eqrsct1qtY6Q6808Bs9o78ZCVZwAAp+Kpe/dV/jr7BWu65INwrARoskmidhLvmFB3RI SRXg== X-Gm-Message-State: AAQBX9eTUoRtOQ+MU5Xb1AwXti0d2+Sug3O+CZXX5SHNyDxq6sRFVtP0 fMW5loYbiMtvdS+S8pSznwHG3TDev0c= X-Google-Smtp-Source: AKy350Zif/3nva63rPaollng0CggVas02G40uoFd4702Cr9vviTg2Z5cNpM03wW6vUt7KwXo60TQcw== X-Received: by 2002:a0d:fc06:0:b0:549:27a8:90b with SMTP id m6-20020a0dfc06000000b0054927a8090bmr6552427ywf.40.1680730508739; Wed, 05 Apr 2023 14:35:08 -0700 (PDT) Received: from mail-yb1-f172.google.com (mail-yb1-f172.google.com. [209.85.219.172]) by smtp.gmail.com with ESMTPSA id 81-20020a810a54000000b00545a7720441sm4179867ywk.45.2023.04.05.14.35.08 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 05 Apr 2023 14:35:08 -0700 (PDT) Received: by mail-yb1-f172.google.com with SMTP id cf7so44261783ybb.5 for ; Wed, 05 Apr 2023 14:35:08 -0700 (PDT) X-Received: by 2002:a25:320d:0:b0:b45:e545:7c50 with SMTP id y13-20020a25320d000000b00b45e5457c50mr622753yby.0.1680730507864; Wed, 05 Apr 2023 14:35:07 -0700 (PDT) MIME-Version: 1.0 References: <20230403205837.1595602-1-jennifer.averett@oarcorp.com> In-Reply-To: Reply-To: joel@rtems.org From: Joel Sherrill Date: Wed, 5 Apr 2023 16:34:56 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 0/3]: Add math support for non LDBL_EQ_DBL architecture To: Jeff Johnston Cc: newlib@sourceware.org, Jennifer Averett Content-Type: multipart/alternative; boundary="000000000000e272a605f89d9075" X-Spam-Status: No, score=-3031.5 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_H2,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --000000000000e272a605f89d9075 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Apr 5, 2023 at 3:12=E2=80=AFPM Jeff Johnston = wrote: > See below. > > On Wed, Apr 5, 2023 at 5:24=E2=80=AFAM Corinna Vinschen > wrote: > > > Hi Jennifer, > > > > On Apr 3 15:58, Jennifer Averett wrote: > > > The attached set of patches add long double support for i386, aarch64 > > and > > > x86_64. The riscv and powerpc are supported by FreeBSD but will need > > more > > > work to be supported by newlib. FreeBSD has separate 64 and 32 bit > > powerpc > > > support which would have to be integrated for newlib. FreeBSD riscv > > support > > > is 64 and there are issues with fenv.h that would have to be addresse= d. > > > > Thanks for your patchset, it looks pretty well to me, though I like > > to have input on this from my co-maintainer Jeff, too. > > > > Looks good. I do have a comment about how the flag checks should not be > removed in math.h. The _REENT_ONLY checking should still be honored as > well as > the m68k flag: __math_68881. OK. Jennifer can revert that part of the patch. > There could be platforms where long double is > supported (possibly doubles are 32 bits and long double is 64 bits), but > there are only the 3 platforms that have the machine support headers at > present. As well, from ieeefp.h there are other > LDBL_MANT_DIG possibilities mentioned (e.g. 53, 65, 112) which the new co= de > cannot handle. > Agreed. We did not go on a quest to support everything at first. It may be possible to provide a generic _fpmath.h which wraps ieeefp.h which could enable a few more architectures. And there is nothing stopping someone from adding more ldNN directories. I think the riscv and ppc should be possible to add from the FreeBSD code but it will take more architecture specific tinkering than we were willing to do in this initial patch. I'm not disagreeing with you at all. Just saying we took a first step and did all the architectures which were straightforward. Plenty of opportunity for follow up. > > > I noticed that you exclude Cygwin from the new code, which makes sense > > as long as we provide our own long double math taken from Mingw-w64. > > > > However, there's something not quite right. When trying to build I get > > symbol conflicts for the fdim{f,l} and scalbln{f,l} symbols in the link > > stage (paths shortend for readability): > > > > ld: libm.a(libm_a-s_fdim.o): in function `fdimf': > > newlib/libm/ld/s_fdim.c:47: multiple definition of `fdimf'; > > libm.a(libm_a-sf_fdim.o):newlib/libm/common/sf_fdim.c:16: first defined > here > > > > ld: libm.a(libm_a-s_fdim.o): in function `fdiml': > > newlib/libm/ld/s_fdim.c:48: multiple definition of `fdiml'; > > libdll.a(fdiml.o):winsup/cygwin/math/fdiml.c:11: first defined here > > > > ld: libm.a(libm_a-s_scalbln.o): in function `scalblnf': > > newlib/libm/ld/s_scalbln.c:46: multiple definition of `scalblnf'; > > libm.a(libm_a-sf_scalbln.o):newlib/libm/common/sf_scalbln.c:34: first > > defined here > > > > ld: libm.a(libm_a-s_scalbln.o): in function `scalblnl': > > newlib/libm/ld/s_scalbln.c:53: multiple definition of `scalblnl'; > > libdll.a(scalbnl.o):winsup/cygwin/scalbnl.S:19: first defined here > > > > The conflicts really ony occur for these four functions. Any chance > > to fix these? > > > > > > Thanks, > > Corinna > > > > > --000000000000e272a605f89d9075--