From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-f182.google.com (mail-oi1-f182.google.com [209.85.167.182]) by sourceware.org (Postfix) with ESMTPS id 042F4385C335 for ; Wed, 24 Aug 2022 13:40:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 042F4385C335 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-oi1-f182.google.com with SMTP id v125so19655738oie.0 for ; Wed, 24 Aug 2022 06:40: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=Y5J7UO2j3Pv3+gGhEAZz8/LCDBkbj5OYeXYOerhaVU8=; b=jrXKBMN6nFAw5RB+ffXKnpbDPkZ/VFv3YnTKoJjnarkDnZnt1Wf8SkPZmrd+3Kfbgz aHD1zzk0BDlDe/6L2hbLpnRj/ReluSAd+2AUq9vxd3Q26+E2deibhAIgBbLadEAFlkte k74r2VT701tOs97tu4QTbZ2MxtSmhqlEHGkc0iS1tVJ2hkBeTWxIilXwYycHJa1DEPDC fbHU8pWDr2HHpi/Xjjw3YW+FG1iHXB5/qaV8/ddtaBrWzOMA/W5sKcj98tFBASFx2gSB Peusk1PaiSnOQvycSFv3Z8xldUG/0Ky23CwmwCXyOgZbgoQ0sNwzGrjikSKl2d7A9byf XxhA== X-Gm-Message-State: ACgBeo0xbEZaE3opkkjNZQmWyvVn9IeU2cBG/PD1ICVO9Y60ghIG9TPJ GYsIb3Yo9HQ5QW6M0nKWJE1s3AKp/O8= X-Google-Smtp-Source: AA6agR5LKcvOtVKH7Ul+bRMcQxVBrSvh3T/ghuNjNxPIJmUwLlZ275ZPqUfRF/ma4y5MlcCFN8DQvA== X-Received: by 2002:a05:6808:1392:b0:344:878c:cb7d with SMTP id c18-20020a056808139200b00344878ccb7dmr3357696oiw.94.1661348456921; Wed, 24 Aug 2022 06:40:56 -0700 (PDT) Received: from mail-oo1-f47.google.com (mail-oo1-f47.google.com. [209.85.161.47]) by smtp.gmail.com with ESMTPSA id n16-20020a0568301e9000b0061c71777dcfsm4410033otr.75.2022.08.24.06.40.56 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 24 Aug 2022 06:40:56 -0700 (PDT) Received: by mail-oo1-f47.google.com with SMTP id u5-20020a4a5705000000b0044b34c2c89cso886877ooa.9 for ; Wed, 24 Aug 2022 06:40:56 -0700 (PDT) X-Received: by 2002:a4a:d085:0:b0:448:93e6:bb67 with SMTP id i5-20020a4ad085000000b0044893e6bb67mr9500227oor.55.1661348456329; Wed, 24 Aug 2022 06:40:56 -0700 (PDT) MIME-Version: 1.0 References: <20220822225022.32209-1-joel@rtems.org> In-Reply-To: Reply-To: joel@rtems.org From: Joel Sherrill Date: Wed, 24 Aug 2022 08:40:45 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH newlib v1 0/4] Add FreeBSD long double functions To: Newlib Content-Type: multipart/alternative; boundary="0000000000009679aa05e6fcd47d" 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_H2,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 List-Id: Message-ID: <20220824134045.dW7oO88p4n-1yQqigYj0SZod9Jmi0JlCYQBC0kv11to@z> --0000000000009679aa05e6fcd47d Content-Type: text/plain; charset="UTF-8" On Wed, Aug 24, 2022 at 4:26 AM Corinna Vinschen wrote: > On Aug 22 17:50, Joel Sherrill wrote: > > Hi > > > > To be clear, this is a V1 for review. It actually does **NOT** > > add every long double math method from FreeBSD. That would add > > unnecessary bulk to this patch set at this point. > > > > The FreeBSD long double code requires there to be an architecture > > specific _fpmath.h file. This is only available for a handful of > > architestures. Further, LDBL does EQ DBL on many architectures. > > The FreeBSD long double code will **NOT** compile if there isn't > > an _fpmath.h file. Thus, the overall approach is: > > > > if architecture has _fpmath.h > > use FreeBSD long double code in libm/common/ldbl > > else > > use existing long double code > > Erm... Did you actually read my last reply? Yes. If we do that, we end up with long double support on 8 architectures and lose it immediately on all others. On the 18 RTEMS target architectures, + Current: long double support on 12 + Proposed: long double support on all + Delete ldbl=dbl implementation: 8 would have long double We should really not add YA > code path. Merging the FreeBSD long double functions should work for > basically all supported arches. We only have to create our own > _fpmath.h supporting all arches based on LDBL_MANT_DIG, isn't it? > It should if someone creates all the _fpmath.h headers. There are 61 directories under libc/machine. That leaves 53 _fpmath.h headers to complete and most are likely ldbl==dbl. That is up to 53 target architectures which would lose the long double math APIs in libm.a. Honestly, I don't mind long term planning to delete them but I was thinking this approach improves the current situation a lot since it will support the targets which really have long double support. It leaves in place support for where ldbl==dbl with no change in available APIs. It is a net win for users. If there is a target with long double which doesn't have a FreeBSD _fpmath.h file, then there is value in creating it. Honestly, unless someone can script writing the missing 50+ _fpmath.h files, I am not comfortable or eager to dive in. Ignoring the lack of time to so. This approach works and doesn't abandon the targets which the ldbl==dbl method works for. --joel > > > Corinna > > --0000000000009679aa05e6fcd47d--