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 BC88F38582AF for ; Tue, 18 Oct 2022 09:18:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BC88F38582AF 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=1666084705; 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=hXr/oq3hlPeoB7nKVOiplkRk6CH94+Ax0a4OD53kMkU=; b=AvWIB0YV+OkLHIZADh/vP4mE2MGo4ML6obmSbTCTfdwFU32AzBA2HR+PiJVr7CzQboyJs+ QiOy1CYo2c47ql7DJ6eqybGfxkBBxogPm4XI6x3i3S8PaqeXykHuKxAM6Cf1KRp7iRRNeg Y/U6/tOqQsG2yGdqSxVfo4GuosCEAEM= Received: from mail-qk1-f200.google.com (mail-qk1-f200.google.com [209.85.222.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-319-jCDvAehzMxiPRcbN2kNzTA-1; Tue, 18 Oct 2022 05:18:22 -0400 X-MC-Unique: jCDvAehzMxiPRcbN2kNzTA-1 Received: by mail-qk1-f200.google.com with SMTP id u9-20020a05620a454900b006eeafac8ea4so11846551qkp.19 for ; Tue, 18 Oct 2022 02:18:22 -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:message-id :reply-to; bh=hXr/oq3hlPeoB7nKVOiplkRk6CH94+Ax0a4OD53kMkU=; b=KLey8YXfskV3MYVicc9kR3/7IrcVLQTaZiaMHDNk0gkPbWqrRjlFJBoPkllJBZY77Z kdUX2Qa4R46GBhwpFIoQ91f2uQTemyKreLIt3o3uV5y48erfT43mE4HsUegDTWl4NoN/ Xutl3S7UuNuDirKbmNfiWH5+2RD9spFGmHrYVQalTvlZH1rZIK84g85JkAUouKX+2lBq D+DSzzXfZITw6n6mdkWbVnPfsDyUOnFRiM+esSGtLuItuxae62M0ggzNHrVUE7rNBK8A HuEQnXV97zqBO4Z2yAKrW7pE79n9NYqtVBJN5wb+kn0/09+jNNvHamH+eu5i894TVNq0 Oe/Q== X-Gm-Message-State: ACrzQf02V2L+pB9mz8zfVq5DN4E/LZJkQ3IExrhtjGg9fo83mH3yMzDU dyN8VA7NzG/xcbaKeZIx7i3/6gtyYB2JjY0pXVcdpmDFcmAqEj2OVsADD74NPiwYUh4o9aF4vVT gYJ1N2qpditS3Fzyh0Trg7bD8DZO60GuKxg== X-Received: by 2002:a05:620a:13f2:b0:6ec:597f:eda6 with SMTP id h18-20020a05620a13f200b006ec597feda6mr1100030qkl.287.1666084701921; Tue, 18 Oct 2022 02:18:21 -0700 (PDT) X-Google-Smtp-Source: AMsMyM6oph8F8bsQ3eQtFZRcVW6uRqD/COIOk0o/XgE9MJYmPLTxYC8Se7FKcnt4n5gome1Sv08OHPLJGjVyGtbLBn4= X-Received: by 2002:a05:620a:13f2:b0:6ec:597f:eda6 with SMTP id h18-20020a05620a13f200b006ec597feda6mr1100021qkl.287.1666084701657; Tue, 18 Oct 2022 02:18:21 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jonathan Wakely Date: Tue, 18 Oct 2022 10:18:10 +0100 Message-ID: Subject: Re: [PATCH] libstdc++, v3: Partial library support for std::float{16,32,64,128}_t and std::bfloat16_t To: Jakub Jelinek Cc: libstdc++@gcc.gnu.org, 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.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=unavailable 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 17:26, Jakub Jelinek wrote: > > Hi! > > On Mon, Oct 17, 2022 at 02:07:00PM +0100, Jonathan Wakely wrote: > > Yes, that's now https://cplusplus.github.io/LWG/issue3790 > > The current proposed resolution is to just restore the C++20 functions > > and not provide anything for the new types. > > Ok. > > > > If you want to have done in a different way, e.g. the patch > > > groups a lot of different function overloads by the floating point type, > > > is that ok or do you want to have them one function at a time for all types, > > > then next? > > > > No, I think this way makes more sense. Otherwise the line count in the > > file will baloon with all the repeated #if #endif directives. > > Ok, changed. > I've also changed this in limits and std_abs.h (ditto for > _GLIBCXX_USE_CONSTEXPR, _GLIBCXX_USE_NOEXCEPT). > > There is one thing I'm not sure about but can be handled incrementally. > What exactly is is_iec559 supposed to be? Nobody really knows. numeric_limits is not well specified. > Currently for float/double/long double/__float128 it seems to be defined > to true if the type has Inf, qNaN and denormals. > For std::float{16,32,64,128}_t even a note in the spec says they are > true. > Shall it be true only if the type is actually a IEEE754 type > (binary16/32/64/128) and false otherwise, or that + the x86 extended type? I think it makes sense to include _Float64x there too. > Or if it is IEEE754-like and shall it be true also for > std::bfloat16_t? It does have NaNs and Infs, so I suppose if double double sets it to true, then bfloat16_t could as well. I'm unsure what the right choice is here though. > Yet another case is the IBM double double, which has infinities, NaNs > and denormals, but for that one it is hard to claim it is even IEEE754-like > (variable precision). Yeah, I think that has is_iec559 == true which is odd. > > > > I could try to handle too, but am kind of lost there. > > > The paper dropped the explicit std::complex specializations, can they stay > > > around as is and should new overloads be added for the > > > _Float*/__gnu_cxx::__bfloat16_t types? > > > > The explicit specializations can stay, they do no harm. > > Ok. Shall those specialization also get the P1467 changes for the ctors? > Shall we also have specializations for the extended floating point types, > or only conditionally (say when float is binary have _Complex _Float32 > so that we get better code)? Oh I forgot the primary template doesn't use __complex__ for its data members. Maybe we want to leave the primary template alone (even though it's kinda useless for non-FP types) and add a new partial specialization using concepts to constrain it for FP types: template requires floating_point<_Tp> class complex; That would be used for all the new FP types, and we can use __complex__ in there. The existing explicit specializations for float/double/longdouble would be preferred to this new partial specialization. We could disable them for C++23, or leave them. We can decide that later anyway. > > > I can take care of the changes. > > Ok. > > > > 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. > > > > I can take care of that too. > > Thanks. > > Here is an updated patch that I'll test overnight (but can't commit > until the builtins patch is reviewed as it depends on that; > well, I could comment out the std::float128_t cmath support if > long double is not IEEE quad and commit that only once the builtins > patch is in). Yes, please comment out the define in os_defines.h for now and push - thanks!