From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 8AB4738582B0 for ; Fri, 30 Sep 2022 19:27:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8AB4738582B0 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1664566036; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=MtFRMcav05nT9Mz546DDaZ6Wyzsc7I2hP64c5oD3Xks=; b=LbC7MRVioW4LFoAo+M5juMZNuuUnEGW31oEQNPLZBZEYKBl3h3cKRgUKESH8syE2VPSktL HKHNRtSL1T8VTYkUOglaNPalDOb03DdcqQ+94S3QwTSTj+gEvchy61BNHMvUO4Y2+c9/D9 g7iV4NYEdncMaksekgI4ZwuzXp5QRIA= Received: from mail-qk1-f197.google.com (mail-qk1-f197.google.com [209.85.222.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-640-OE6scujiPmu-1jfAuJ-O7Q-1; Fri, 30 Sep 2022 15:27:15 -0400 X-MC-Unique: OE6scujiPmu-1jfAuJ-O7Q-1 Received: by mail-qk1-f197.google.com with SMTP id j13-20020a05620a288d00b006be7b2a758fso4419045qkp.1 for ; Fri, 30 Sep 2022 12:27:14 -0700 (PDT) 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; bh=MtFRMcav05nT9Mz546DDaZ6Wyzsc7I2hP64c5oD3Xks=; b=bsIcupMyWln/xc2CKfOoLIuLcTRdc8wI1VmVxEEHFIbbawvTt58p8cShVNvgd0BU4S 8nCsFcjqjY7YFq6cxZcEUnm5e+4K3xYaaMemeOZNifSveRwztbbdpsm0BnPjCSFbAymD gAiLzIwp7dldhBDUp/akjzxDHAZQep9CJfTSs1rkhMcSD5wcywsZDfs20TQ0Vg4vVEmv zLCPCz6+1psh0pHLUYYLxw86qGJkW0BmNYshZ1ANrgGq62tLNz3sy8Mu/xzN4zWU7a+2 e1fO8recRid/q3Z2eSTlXQgjl+pwVpF07H/w0JiypXR2NQvxzGme2Cu+aFulqSf4w2Hb INXg== X-Gm-Message-State: ACrzQf0rVsNBQXfKL7qZRUAdOFr90j8TW/QND+7ToqiWo48j3rNCm+ob N7FXaGDyJyGMoeI2eduW+lokYC9xij8t9p68zd6r1dprEH5h7CiZSt3aQiO7WBhri1H/2ESIwjM ZKKW7Zed+bXowGMq9fXS/Qk4K+bzTbI/5hg== X-Received: by 2002:a05:622a:3cd:b0:35d:5a31:add3 with SMTP id k13-20020a05622a03cd00b0035d5a31add3mr8277058qtx.301.1664566034360; Fri, 30 Sep 2022 12:27:14 -0700 (PDT) X-Google-Smtp-Source: AMsMyM6X58vxzAVnIFEbYVQSbZ4Cp5lTIkuF9d1fxpn9RHMd0Qvt233BZ+r7vYrhdRQ/2Eov8H5cgML+WYOgMPwCrF8= X-Received: by 2002:a05:622a:3cd:b0:35d:5a31:add3 with SMTP id k13-20020a05622a03cd00b0035d5a31add3mr8277044qtx.301.1664566034159; Fri, 30 Sep 2022 12:27:14 -0700 (PDT) MIME-Version: 1.0 References: <37522634-319a-b471-aa35-87e711b0479e@redhat.com> In-Reply-To: From: Jonathan Wakely Date: Fri, 30 Sep 2022 20:27:03 +0100 Message-ID: Subject: Re: [RFC PATCH] c++, i386, arm, aarch64, libgcc: std::bfloat16_t and __bf16 arithmetic support To: Jakub Jelinek Cc: Joseph Myers , Jason Merrill , Richard Earnshaw , richard.sandiford@arm.com, gcc-patches@gcc.gnu.org X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-6.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE,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 Fri, 30 Sept 2022 at 19:38, Jakub Jelinek wrote: > > On Fri, Sep 30, 2022 at 06:21:04PM +0000, Joseph Myers wrote: > > On Fri, 30 Sep 2022, Jakub Jelinek via Gcc-patches wrote: > > > > > What isn't in the patch but I think we'll need to also change are some > > > minimal set of __builtin_*bf16 builtins. Seems for _Float16, GCC provides > > > all the __builtin_*f16 (and for C/ObjC even with *f16 names), but there is > > > no glibc support for any of that, so builtins that are expanded by the > > > compiler are fine, but what should be fall back to libm won't work. > > > Maybe at least for now it is acceptable to implement most and > > > std::float16_t and std::bfloat16_t overloads with using > > > __builtin_*f and explicitly narrow down, but I think at least nextafter > > > (and apparently nexttoward as an alias for it for extended floating > > > point types) needs to be specific for the particular floating point format. > > > > C doesn't have nexttoward (the function whose second argument is always > > long double, independent of the type of the first argument) for any of the > > _FloatN or _FloatNx types; why does C++ have in (but with second argument > > the same type as the first?) for those types? > > No idea. > https://eel.is/c++draft/cmath.syn > has (since that std::float*_t/std::bfloat16_t paper) > constexpr floating-point-type nextafter(floating-point-type x, floating-point-type y); > constexpr float nextafterf(float x, float y); > constexpr long double nextafterl(long double x, long double y); > > constexpr floating-point-type nexttoward(floating-point-type x, floating-point-type y); > constexpr float nexttowardf(float x, long double y); > constexpr long double nexttowardl(long double x, long double y); > > That is certainly wrong for double, because it is a backwards incompatible > change, where > constexpr double nexttoward(double x, long double y); > is gone and > constexpr double nexttoward(double x, double y); > is added. > IMHO the nexttoward case just shouldn't be changed, so it should remain: > constexpr float nexttoward(float x, long double y); > constexpr double nexttoward(double x, long double y); > constexpr long double nexttoward(long double x, long double y); > constexpr float nexttowardf(float x, long double y); > constexpr long double nexttowardl(long double x, long double y); Right, this is a defect. The author of P1467 reported that as an accidental change (which we all missed). It should be in the LWG issues list by Monday, and (I hope) will be voted Tentatively Ready immediately. > Having > constexpr floating-point-type nexttoward(floating-point-type x, long double y); > would be problematic, because long double might have unordered floating > point rank to floating-point-type (say powerpc IBM extended long double > vs. std::float128_t), or could have smaller floating point rank (say if > it is IEEE double). > But like nexttowardl or nexttoward(long double, long double) aren't very > useful because they are the same thing as nextafterl or > nextafter(long double, long double), introducing other nexttoward overloads > doesn't seem useful. > > Jakub >