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 4B588385C32E for ; Mon, 31 Oct 2022 10:26:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4B588385C32E 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=1667211984; 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=emzangoKqwOevEOuNyYymcfP1EorQq3SB43Ua9kIUwc=; b=UVAN4E8VwHoI/9tCt2yqBslXaaBXbVDKjPT7wLpYPD6uxXgEwk5ZWb/hzVf3uWPtGl93zR OvaV04Kp7yQC33MWQhDTDkdOzY7+iWC2cKIOzP7Gdf7N6SSv+dtBWW+Mt1F7Z5V0wc7PLN +nSkIeyB1uTKnqKYoUjbdwUH/cv4ag8= Received: from mail-ed1-f70.google.com (mail-ed1-f70.google.com [209.85.208.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-446-7M_5AZEjO1avQbg03TKmzw-1; Mon, 31 Oct 2022 06:26:23 -0400 X-MC-Unique: 7M_5AZEjO1avQbg03TKmzw-1 Received: by mail-ed1-f70.google.com with SMTP id b14-20020a056402278e00b004621a2642d7so7457952ede.1 for ; Mon, 31 Oct 2022 03:26:23 -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=emzangoKqwOevEOuNyYymcfP1EorQq3SB43Ua9kIUwc=; b=i/zLZNG4u8axqYvFqYg5sm7qDVuuabxgJlbGsiu0MklOP+jcJbKdgn9Cwvlx0lMMYz +jw4r/uzmwhitDaExY1orcGeFKGnyZ9fwzroj/KAzBLVVAccw7p4zXuhH129CVaBVkRT NkLZj4mLl/ACg4iQDgiGEwXs3NZnP5B/6bT19y7lMR3U/U5HpmOk8uEu9++v6QkEZtxg lAi1KLS5vLeuoS9EkweVkLZQtTepi9a+ylFLeuyRw4ujx/Mb8KtDUyiTwPxTiRryXI6w qNruKxiJor3DbKMB93OuTEW938jSydleLcsm4bj4kYYtKuVMMLxLmtEb5XFCtRnNkGzk GUgw== X-Gm-Message-State: ACrzQf3BwGbHzPksEOEOoqru/7ytQZiKwV3Uw/+Y+JZkyskM/XKPZWTB jtCqBcmUtSO6ka+1pE5iNruCbIVGhuP9kJoUnliaQT+ndL/iUeLpjSUV0U7uvrpYSdcrU9daTsZ h2SCeJ52V2npl1zAMZZNiEk2pxEp2fxqrdg== X-Received: by 2002:a05:6402:13d9:b0:463:398a:75af with SMTP id a25-20020a05640213d900b00463398a75afmr6832962edx.328.1667211982696; Mon, 31 Oct 2022 03:26:22 -0700 (PDT) X-Google-Smtp-Source: AMsMyM6Aq6bWBTsijRlsdCCfnqepoJ9WFfWbTME+Ca5R6Q8cc1UNthr5NclhFBuLO5PQHsFL+0yX3yX+dxhuhM3XXUQ= X-Received: by 2002:a05:6402:13d9:b0:463:398a:75af with SMTP id a25-20020a05640213d900b00463398a75afmr6832947edx.328.1667211982469; Mon, 31 Oct 2022 03:26:22 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jonathan Wakely Date: Mon, 31 Oct 2022 10:26:11 +0000 Message-ID: Subject: Re: [PATCH] libstdc++-v3: support for extended floating point types To: Jakub Jelinek Cc: gcc-patches@gcc.gnu.org, libstdc++@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.8 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,RCVD_IN_MSPIKE_H2,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, 21 Oct 2022 at 16:58, Jakub Jelinek wrote: > > Hi! > > The following patch adds support for extended floating point > types. > C++23 removes the float/double/long double specializations from the spec > and instead adds explicit(bool) specifier on the converting constructor. > The patch uses that for converting constructor of the base template as well > as the float/double/long double specializations's converting constructors > (e.g. so that it handles convertion construction also from complex of extended > floating point types). Copy ctor was already defaulted as the spec now > requires. > The patch also adds partial specialization for the _Float{16,32,64,128} > and __gnu_cxx::__bfloat16_t types because the base template doesn't use > __complex__ but a pair of floating point values. > This patch is on top of > https://gcc.gnu.org/pipermail/libstdc++/2022-October/054849.html > (and if > https://gcc.gnu.org/pipermail/libstdc++/2022-October/054862.html > is also applied, then > https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603665.html > https://gcc.gnu.org/pipermail/gcc-patches/2022-October/604080.html > https://gcc.gnu.org/pipermail/gcc-patches/2022-October/604134.html > are needed as well). > The g++.dg/cpp23/ testcase verifies explicit(bool) works correctly. > > Tested on x86_64-linux, ok for trunk? > > 2022-10-21 Jakub Jelinek > > gcc/testsuite/ > * g++.dg/cpp23/ext-floating12.C: New test. > libstdc++-v3/ > * include/std/complex (complex::complex converting ctor): For C++23 > use explicit specifier with constant expression and explicitly cast > both parts to _Tp. > (__complex_abs, __complex_arg, __complex_cos, __complex_cosh, > __complex_exp, __complex_log, __complex_sin, __complex_sinh, > __complex_sqrt, __complex_tan, __complex_tanh, __complex_pow): Add > __complex__ _Float{16,32,64,128} and __complex__ decltype(0.0bf16) > overloads. > (complex::complex converting ctor, > complex::complex converting ctor, > complex::complex converting ctor): For C++23 implement > as template with explicit specifier with constant expression > and explicit casts. > (__complex_type): New template. > (complex): New partial specialization for types with extended floating > point types. > (__complex_acos, __complex_asin, __complex_atan, __complex_acosh, > __complex_asinh, __complex_atanh): Add __complex__ _Float{16,32,64,128} > and __complex__ decltype(0.0bf16) overloads. > (__complex_proj): Likewise. Add template for complex of extended > floating point types. > * include/bits/cpp_type_traits.h (__is_floating): Specialize for > _Float{16,32,64,128} and __gnu_cxx::__bfloat16_t. > * testsuite/26_numerics/complex/ext_c++23.cc: New test. > > --- libstdc++-v3/include/std/complex.jj 2022-10-21 08:55:43.037675332 +0200 > +++ libstdc++-v3/include/std/complex 2022-10-21 17:05:36.802243229 +0200 > @@ -142,8 +142,14 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION > > /// Converting constructor. > template > +#if __cplusplus > 202002L > + explicit(!requires(_Up __u) { _Tp{__u}; }) > + constexpr complex(const complex<_Up>& __z) > + : _M_real(_Tp(__z.real())), _M_imag(_Tp(__z.imag())) { } Do these casts to _Tp do anything? The _M_real and _M_imag members are already of type _Tp and we're using () initialization not {} so there's no narrowing concern. _M_real(__z.real()) is already an explicit conversion from decltype(__z.real()) to decltype(_M_real) so the extra _Tp is redundant. I think the diff between C++23 and older standards would be smaller done like this: /// Converting constructor. template #if __cplusplus > 202002L explicit(!requires(_Up __u) { _Tp{__u}; }) #endif _GLIBCXX_CONSTEXPR complex(const complex<_Up>& __z) : _M_real(__z.real()), _M_imag(__z.imag()) { } This also means the constructor body is always defined on the same line, which avoids warnings from ld.gold's -Wodr-violations which IIRC is based on simple heuristics like the line where the function is defined. Otherwise this looks great. If the above alternative works, please use that, but OK for trunk either way (once all the other patches it depends on are in).