From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) by sourceware.org (Postfix) with ESMTPS id 397123858D32; Mon, 17 Oct 2022 21:45:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 397123858D32 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-ej1-x630.google.com with SMTP id y14so27935918ejd.9; Mon, 17 Oct 2022 14:45:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=rFb+h63TkhnVM1RDNV28CngsVRZOjaK6xQVCdnfjhDk=; b=HAKYA8TmhSyhqsnNE/0y3RX8ueagjIqfhkkkVBKUfmvSi/TBUD1tLiCHQmrFUVBBFn oAtLbx3mnAObdsCqUz8eHvdYThs+n2FrNgbYYXnmB1nr8uYeCGP5zsWwYFpaLfN5mDro qv2GZdRLUOElVnj35fi32IQkQjuxH/DmFcXyOnWhZZ7FGk/j/nQMDhEpDTS/DxJ8/w8G hrSPPbS9gGR9+pXuifsF5yZsIhdEx3TXOvklP3fhGxtSQz7nCvhvQSeZSCW+MCpG6wbp tJ9fSNKlRFXJVeNlXiESOK2vOeIC0klbh1VMTx7cTEcF834P11EkhGh44JvnQSOzGriE Pq/g== 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:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=rFb+h63TkhnVM1RDNV28CngsVRZOjaK6xQVCdnfjhDk=; b=1Q7BcWk2G8dmE62gPxlqF5xvl4FUa9St02FCXoaHaOKsYYTloCtmWoTMiUTD6o2HWE b5ufvmnSFRzXK2aifiWsY2s9uAotIjoPFukhRFoz0kZPCCiEmXUssB24bwbnG3mGH/LC c0Wpq0qlP1Pgo3c858AfV1XR27SAi4r3g4B19O0dT/EaAqYVVWFySJ3BNa3sW9EUpozw 0BDjHXKnzNo5RRzo9bNZZsulBhWtb4VYEemJ7RkbQlQu8NAt5nrbQRu20ob+hkMw17yw bbaGZjmpuSOx80hulAPB4VjKBc05CfScQRZFmTQitZ444uTgZSmtMtMx1NYrbzTHueau cxVg== X-Gm-Message-State: ACrzQf271SkqXw2rr9K5ZxH2LONe/6iWOgsCKGIhMc4yl2TDHk5mtosA Ns8TQ6j6RNz1JqrHzCsHRBJ/fXIfo4X/05fyvBQ= X-Google-Smtp-Source: AMsMyM5pvGlA0QGlhYNi23fHTb3q/kPoMWZdzMPFt/7pQZW8JpLGApa88IyaHKrb9pDURZoWLIILdNDRvRMYBZOfB6s= X-Received: by 2002:a17:907:7626:b0:78d:e65b:e5ac with SMTP id jy6-20020a170907762600b0078de65be5acmr9920432ejc.416.1666043124822; Mon, 17 Oct 2022 14:45:24 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jonathan Wakely Date: Mon, 17 Oct 2022 22:45:13 +0100 Message-ID: Subject: Re: [RFC PATCH] libstdc++, v2: Partial library support for std::float{16, 32, 64, 128}_t To: Joseph Myers Cc: Jonathan Wakely , Jakub Jelinek , libstdc++@gcc.gnu.org, gcc-patches@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-0.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Mon, 17 Oct 2022 at 22:33, Joseph Myers wrote: > > On Mon, 17 Oct 2022, Jonathan Wakely via Gcc-patches wrote: > > > > And I/O etc. support is missing, not sure I'm able to handle that and if it > > > is e.g. possible to keep that support out of libstdc++.so.6, because what > > > extended floating point types one has on a particular arch could change over > > > time (I mean e.g. bfloat16_t support or float16_t support can be added > > > etc.). > > > > Yes, I think we can add the I/O functions as always_inline because all > > they're going to do is convert the argument to float, double, or long > > double and then call the existing overloads. There will be no new > > virtual functions. > > As with fma, note that doing conversions from strings to floating-point is > a case where doing the operation on float and then narrowing is > technically incorrect because double rounding can occur (the rounded float > result can be half way between two values of the narrower type, without > that being the exact mathematical result) but the operation should be > correctly rounding. It's fine to use float or double operations in the > other direction (floating-point to strings), of course. Yes, this is called out in the C++23 draft: [ Note: When the extended floating-point type has a floating-point conversion rank that is not equal to the rank of any standard floating-point type, then double rounding during the conversion can result in inaccurate results. from_chars can be used in situations where maximum accuracy is important. - end note ] The alternative is an ABI break, which we didn't want to force on implementors. For libstdc++ we're not going to break the ABI, so we're going to live with the double rounding.