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 5D36B385C32F for ; Mon, 31 Oct 2022 10:26:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5D36B385C32F 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=1667211985; 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=H+QXg0i4ZiVBmUFMAbnZnXlX6OkCbEWikWvEerRsZvqHclmHXv0Ptg/UgVwQscnbKKD6Ap t3gGrIh6taCy2HTigBUC3oSKTNAII6bdxbV7btA1IcoWd5CdZQzrBvFoXFlo0s/6+5N15G QLhnfKIb+mghSeVb1gabYGWx0DPxi/8= 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-224-xdfd-pvFNLCXUzD8Xrd3kw-1; Mon, 31 Oct 2022 06:26:23 -0400 X-MC-Unique: xdfd-pvFNLCXUzD8Xrd3kw-1 Received: by mail-ed1-f70.google.com with SMTP id i17-20020a05640242d100b0044f18a5379aso7597914edc.21 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=uCci3VWHh3Jrbfi1wGJSCaZ7PpNVX6fg7kwFiY3TjyXFVwSvFI/2U62rd5qBtr9ZFi GjBdBfwd6Rc73VoP8GEkGlVD7phBrvxY6thRIaDnUUCsu4QqhxEBObuJHTwBlkEQmqRP bHgx4cHpwMRAkWRkeS5J12Ou1Eaq6dXKVYLRjQA7cYhAXOg8dhkXN7TydFTyshw97R5T Txw4Lfb95DAdvfKbjkX9xVdeeT2EuTpgUqatcglfqse0i/e1UuV6zyocIjKQVfY2TcEf 25ZH93HCMr3/wjlyHvlQ5Sywc4cLOwkj4UB2vMXPq0pSNw8K2DWlvN0n9F09iva+81gX C2fg== X-Gm-Message-State: ACrzQf07dFcpOS0ZngfrHTOyJkTV+SLMxVZOYthO4thLGkCTEa74zuuq 3sE4EYg09jxVUEtUy+c6xiZba5vr2uJRM7k+Ce9RquoH3J37M9EPSOYVyrax9koiPhr8ANmC1KU cyvh4BcjGhY3DtrWvVESLjDdTTgUgH/o= X-Received: by 2002:a05:6402:13d9:b0:463:398a:75af with SMTP id a25-20020a05640213d900b00463398a75afmr6832964edx.328.1667211982698; 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).