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.129.124]) by sourceware.org (Postfix) with ESMTPS id 8301C3858D1E for ; Fri, 30 Sep 2022 18:38:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8301C3858D1E 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=1664563134; h=from:from:reply-to: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=bPZ4HjSTEnu14iXe59NnntFWYzCZryuJpd0hnuNam+k=; b=UwZzSeY1NbDWYO3wvsPXJHk3BeiSwGKzX9ruM5NcqFu+lPXV4XEOOVWa3/9QeT6YqFIEYp fshQLVFM4ac1G8QMUImwWAqBnT+GOpIgZLmXazVn1m2AkZw4wUruS+WAMWgIDdz+gH3yVK o8gm+cRm8gIdNoibADGqaEkTUI6JkLk= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-257-Bo60WNdhNaypzIvprArxhA-1; Fri, 30 Sep 2022 14:38:52 -0400 X-MC-Unique: Bo60WNdhNaypzIvprArxhA-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 6D9422A5955A; Fri, 30 Sep 2022 18:38:52 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.194]) by smtp.corp.redhat.com (Postfix) with ESMTPS id ED13F2166B26; Fri, 30 Sep 2022 18:38:51 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 28UIclQJ091693 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 30 Sep 2022 20:38:47 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 28UIckjS091692; Fri, 30 Sep 2022 20:38:46 +0200 Date: Fri, 30 Sep 2022 20:38:45 +0200 From: Jakub Jelinek To: Jonathan Wakely , Joseph Myers Cc: Jason Merrill , Richard Earnshaw , richard.sandiford@arm.com, gcc-patches@gcc.gnu.org Subject: Re: [RFC PATCH] c++, i386, arm, aarch64, libgcc: std::bfloat16_t and __bf16 arithmetic support Message-ID: Reply-To: Jakub Jelinek References: <37522634-319a-b471-aa35-87e711b0479e@redhat.com> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.6 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-4.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_LOW,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, 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); 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