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 993A23856DCF for ; Sat, 17 Sep 2022 08:59:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 993A23856DCF 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=1663405141; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=C0gUwK5AhL1D15t0l1w60b8vy9kfWK7mItY5GrxeI2c=; b=IQ4EYXVti0/mwol1Un5nv2uD2uKmx+LhaFq9cMIpWhGgEmJrcesh8q6T4djubqetRpHAS/ 7A8Dx6W78uaDu6dbzXQwBNMz4ZHNDxIpnqtnWuxC5iBvBhiAvoJmYO+86Juu3Zte1EsJjC f4sFSsb05dXLAC7gN0ZuCLMIJR4RwhE= Received: from mail-ed1-f71.google.com (mail-ed1-f71.google.com [209.85.208.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-458-HwqZQutyONSkE8QlT1bz4A-1; Sat, 17 Sep 2022 04:58:58 -0400 X-MC-Unique: HwqZQutyONSkE8QlT1bz4A-1 Received: by mail-ed1-f71.google.com with SMTP id f10-20020a0564021e8a00b00451be6582d5so12748243edf.15 for ; Sat, 17 Sep 2022 01:58:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date; bh=C0gUwK5AhL1D15t0l1w60b8vy9kfWK7mItY5GrxeI2c=; b=yo8+rU2mpSicuvIzL2nnKOTM2iYqsgVUXVf/gYhNxgdiNcKpMKRKCbzrdjbTBdjbkE pA7GfJ32bVnhAvKU3MeGGyNaPwdOngtElL6EehL49u3I6wxFYWuIi/nMhou5GQVKOMZ/ o6OTMShy/ZYsvrU0sd3tXXnGS5XFaWiqtyGNCre/pcHQsHd3zC12yPNhimyWgIq5SHFQ G1+l7P9omFTkbh5tzbiDGMwpWrAb1rbHyuEL8FbrfVxPLUw8K9j8sFezZoxfSRT37cnI thXk6cvA/RkrmTIdpuAYsSFqpbPFLXIaFnCrWl01neCjrJwPiqzBPWXbvw+RD6CuFtm5 E6JA== X-Gm-Message-State: ACrzQf1N++syjfkJ7HADJZF4glx/RM51GxbTsNIJLNf+E/GIMSghly9+ 5u/ZL0XZGkuuiOyyCVPSPldpCt7c2lKCW5RR6nY5MMRHjzYh5yvasLsqDU/CyHIslkanjMdTJMw CC0xWSC348Ok7puS+hg== X-Received: by 2002:a05:6402:1943:b0:443:5ffb:b04e with SMTP id f3-20020a056402194300b004435ffbb04emr7088054edz.230.1663405137037; Sat, 17 Sep 2022 01:58:57 -0700 (PDT) X-Google-Smtp-Source: AMsMyM5wEAkc2dZlcxT/2UJa4ROaVz1pqfA6NcvhBqL2S+02KO4UXQqxuxMIG2dHpMGhD3LTKQwd2g== X-Received: by 2002:a05:6402:1943:b0:443:5ffb:b04e with SMTP id f3-20020a056402194300b004435ffbb04emr7088038edz.230.1663405136752; Sat, 17 Sep 2022 01:58:56 -0700 (PDT) Received: from [10.9.7.96] (vpn-konference.ms.mff.cuni.cz. [195.113.20.101]) by smtp.gmail.com with ESMTPSA id r17-20020a17090609d100b0077ce503bd77sm9372283eje.129.2022.09.17.01.58.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 17 Sep 2022 01:58:55 -0700 (PDT) Message-ID: <0096284c-ef12-9538-da0a-1d430300b8a5@redhat.com> Date: Sat, 17 Sep 2022 10:58:54 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.13.0 Subject: Re: [PATCH] c++: Implement P1467R9 - Extended floating-point types and standard names compiler part except for bfloat16 [PR106652] To: Jakub Jelinek Cc: Jonathan Wakely , "Joseph S. Myers" , Bruce Korb , gcc-patches@gcc.gnu.org References: From: Jason Merrill In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-7.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_NONE,TXREP,URIBL_BLACK 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 9/16/22 13:34, Jakub Jelinek wrote: > On Fri, Sep 16, 2022 at 01:48:54PM +0200, Jason Merrill wrote: >> On 9/12/22 04:05, Jakub Jelinek wrote: >>> The following patch implements the compiler part of C++23 >>> P1467R9 - Extended floating-point types and standard names compiler part >>> by introducing _Float{16,32,64,128} as keywords and builtin types >>> like they are implemented for C already since GCC 7. >>> It doesn't introduce _Float{32,64,128}x for C++, those remain C only >>> for now, mainly because https://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangling >>> has mangling for: >>> ::= DF _ # ISO/IEC TS 18661 binary floating point type _FloatN (N bits) >>> but doesn't for _FloatNx. And it doesn't add anything for bfloat16_t >>> support, see below. >>> Regarding mangling, I think mangling _FloatNx as DF x _ would be >>> possible, but would need to be discussed and voted in. >> >> As you've seen, I opened a pull request for these. I think we can go ahead >> and implement that and make sure it's resolved before the GCC 13 release. >> >> Or we could temporarily mangle them as an extension, i.e. u9_Float32x. >> >> I would expect _Float64x, at least, to be fairly popular. > > If we get the mangling for _Floatx agreed on, whether it is DFx_ as > you proposed, or DFx or DFx_, sure, I agree we should just enable > those too and will tweak the patch. It would then fix also PR85518. > > Though, when we add support for _Floatx and declare they are extended > floating-point types, the question is about subrank comparisons, shall those > have lower conversion subrank than _Float type with the same conversion > rank or the other way around? Say on x86_64 where _Float32x and _Float64 > has the same rank, shall (_Float32x) x + 0.0f64 have _Float32x type or > _Float64? > And, shall we support f32x etc. constant literal suffixes (with pedwarn > always even in C++23)? > >>> The patch wants to keep backwards compatibility with how __float128 has >>> been handled in C++ before, both for mangling and behavior in binary >>> operations, overload resolution etc. So, there are some backend changes >>> where for C __float128 and _Float128 are the same type (float128_type_node >>> and float128t_type_node are the same pointer), but for C++ they are distinct >>> types which mangle differently and _Float128 is treated as extended >>> floating-point type while __float128 is treated as non-standard floating >>> point type. >> >> How important do you think this backwards compatibility is? >> >> As I mentioned in the ABI proposal, I think it makes sense to make >> __float128 an alias for std::float128_t, and continue using the current >> mangling for __float128. > > I thought it is fairly important because __float128 has been around in GCC > for 19 years already. To be precise, I think e.g. for x86_64 GCC 3.4 > introduced it, but mangling was implemented only in GCC 4.1 (2006), before we ICEd > on those. Until glibc 2.26 (2017) one had to use libquadmath when > math library functions were needed, but since then one can just use libm. > __float128 is on some targets (e.g. PA) just another name for long double, > not a distinct type. I think we certainly want to continue to support __float128, what I'm wondering is how much changing it to mean _Float128 will affect existing code. I would guess that a lot of code that just works on __float128 will continue to work without modification. Does anyone know of significant existing uses of __float128? > Another thing are the PowerPC __ieee128 and __ibm128 type, I think for the > former we can't make it the same type as _Float128, because e.g. libstdc++ > code relies on __ieee128 and __ibm128 being long double type of the other > ABI, so they should mangle as long double of the other ABI. But in that > case they can't act as distinct types when long double should mangle the > same as they do. And it would be weird if those types in one > -mabi=*longdouble mode worked as standard floating-point type and in another > as extended floating-point type, rather than just types which are neither > standard nor extended as before. Absolutely we don't want to mess with __ieee128 and __ibm128. And I guess that means that we need to preserve the non-standard type handling for the alternate long double. I think we can still change __float128 to be _Float128 on PPC and other targets where it's currently an alias for long double. It seems to me that it's a question of what provides the better transition path for users. I imagine we'll want to encourage people to replace __float128 with std::float128_t everywhere. In the existing model, it's not portable whether void f(long double) { } void f(__float128) { } is an overload or an erroneous redefinition. In the new model, you can portably write void f(long double) { } void f(std::float128_t) { } and existing __float128 code will call the second one. Old code that had conditional __float128 overloads when it's different from long double will need to change to have unconditional _Float128 overloads. If we don't change __float128 to mean _Float128, we require fewer immediate changes for a library that does try to support all floating-point types, but it will need changes to support _Float128 and will need to keep around conditional __float128 overloads indefinitely. >> I don't think we want the two types to have different semantics. If we want >> to support existing __float128 code that relies on implicit narrowing >> conversions, we could allow them generally with a pedwarn using the 'bad' >> conversion machinery. That's probably useful anyway for better diagnostics. > > So you mean instead of > + if (fcode == REAL_TYPE > + && tcode == REAL_TYPE > + && (extended_float_type_p (from) > + || extended_float_type_p (to)) > + && cp_compare_floating_point_conversion_ranks (from, to) >= 2) > + return NULL; > before conv = build_conv (ck_std, to, conv); do those checks in else if > after: > if ((same_type_p (to, type_promotes_to (from)) > || (underlying_type && same_type_p (to, underlying_type))) > && next_conversion (conv)->rank <= cr_promotion) > conv->rank = cr_promotion; > and pedwarn there (or somewhere later?) and set conv->bad_p = true;? > I can certainly try that what will it do on the tests in the patch. Set bad_p there; the pedwarn should go in the bad_p handling in convert_like_internal. Jason