From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-f169.google.com (mail-qt1-f169.google.com [209.85.160.169]) by sourceware.org (Postfix) with ESMTPS id 9186038A908A for ; Tue, 15 Nov 2022 18:17:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9186038A908A 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-qt1-f169.google.com with SMTP id jr19so9237111qtb.7 for ; Tue, 15 Nov 2022 10:17:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=n8aLYXuKG3XM7DiR3cBmA3uqx0Ha69E66KGH/dU8Abc=; b=t3KlOn6zUsuPM3rfEnrKUdMjUzrpipyg5QNxqD6WYY1+fAEN2ubGED2iDtZSnB7oG7 GKdMsanD9TsQaCVWqdWNVJmtVi+uCmmEjae79Xpkuv0CV0e1KbkT3LJjdVyfuTD9WvvL kWQnbreR8YLiPVL6kR+pnXsFWouW5X6giqB/Q6zhaxTifnK1pqHVSg5Kk+lhB6LFYbkD JQGjlioDH8jrjz4vg6DHI5j5b7H+iuJQ291a6dcDc5WGcmqGibvSu+P7ERL74hDSaTLl YTzTDpAxPG5oTVdjMmWIBAxnRFTAVvj9jAhzN2q0ARiwyZgxjCYbLjyNqxGk+lXvqWBS eCVA== X-Gm-Message-State: ANoB5plH6+mSuI/auknAQNLYxqXb5zziURzDA2QngzxvyBy2eU1Ol0+v gpCXqOxfjKxrRfFPZ2AtUoxn3zJsB/g= X-Google-Smtp-Source: AA0mqf7BU2MAme8DEjm7mt1lkjy/0S9hxiq7HscxWdm0Nme8XJTFEFaU8aCObfQvFe1ZBDzVdnbRNw== X-Received: by 2002:a05:622a:1f09:b0:3a5:410c:bb77 with SMTP id ca9-20020a05622a1f0900b003a5410cbb77mr17620885qtb.266.1668536234499; Tue, 15 Nov 2022 10:17:14 -0800 (PST) Received: from mail-yb1-f177.google.com (mail-yb1-f177.google.com. [209.85.219.177]) by smtp.gmail.com with ESMTPSA id bl12-20020a05620a1a8c00b006fae7e6204bsm8497241qkb.108.2022.11.15.10.17.12 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 15 Nov 2022 10:17:14 -0800 (PST) Received: by mail-yb1-f177.google.com with SMTP id k84so13936922ybk.3 for ; Tue, 15 Nov 2022 10:17:12 -0800 (PST) X-Received: by 2002:a25:cc51:0:b0:6cf:c231:1ab6 with SMTP id l78-20020a25cc51000000b006cfc2311ab6mr19001813ybf.137.1668536232734; Tue, 15 Nov 2022 10:17:12 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: Reply-To: joel@rtems.org From: Joel Sherrill Date: Tue, 15 Nov 2022 12:17:00 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: round() on arm vs aarch64 To: Stephanos Ioannidis Cc: "Richard.Earnshaw@foss.arm.com" , "newlib@sourceware.org" Content-Type: multipart/alternative; boundary="00000000000072757105ed865dc9" X-Spam-Status: No, score=-3031.3 required=5.0 tests=BAYES_00,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,KAM_DMARC_STATUS,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,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: --00000000000072757105ed865dc9 Content-Type: text/plain; charset="UTF-8" On Tue, Nov 15, 2022 at 9:58 AM Stephanos Ioannidis wrote: > On Tue, 2022-11-15 at 09:38 -0600, Joel Sherrill wrote: > > Digging a bit, I noticed a huge block of is ifdef'ed out for > > aarch64. > > I found the file c++config.h which is different between the two. > > > > Based on the diff of the arm and aarch64 versions, arm has > > _GLIBCXX_USE_C99_MATH_TR1 defined but aarch64 does not. > > > > I have no idea where the settings in this file come from but this > > appears to be the key difference. > > > > More insight appreciated. > > Funny how I came across a similar issue today. The following link might > be of help in understanding what is going on: > > > https://github.com/zephyrproject-rtos/sdk-ng/issues/566#issuecomment-1315165640 Thanks for the quick reply. It is a shame that the lack of long double methods prevents the entire TR1 from being there. Wouldn't it be ok to just have the prototypes and let the user get a link error? Anyway, I have been very very slowly picking at newlib long double support but haven't gotten a complete patch set that is acceptable. See https://sourceware.org/newlib/ for the discussion. I am happy to share my work in process. As I recall, one of the sticking points is that the FreeBSD code has long double support for architectures which have true long double but nothing as far as I can tell for architectures where double == long double. I was proposing a configure time selection of the current code for when long double == double and use the imported FreeBSD code when there is true long double support. Making libstdc++'s configure probe more forgiving would be a nice step but long term having complete long double support would be better. How to progress? --joel > > Regards, > > Stephanos > --00000000000072757105ed865dc9--