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 D32B13858426 for ; Sun, 7 Jan 2024 16:40:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D32B13858426 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org D32B13858426 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704645646; cv=none; b=TCsONWyjkLeTc4x+fLv2a3o9huYLEeTfHwx7KuOaGC+x7T3E27Q7wju504Eu2t17GLVtn/ECR1qk1r1IuYjA9x+yHycgtLSgsTZ3vaC4Pok6DaaYGOCqyreSEbrZgMT2SxKRm2HbnRnRcCjMSbWwQtyroliiX3DZq7p1DuV3lXY= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704645646; c=relaxed/simple; bh=PD8+qTWdptrdiLFzA80ADKv7X/RM6WRpYAsycJGtPNE=; h=DKIM-Signature:From:Date:To:Subject:Message-ID:MIME-Version; b=LtMnTL6iwu5Z0kyoXjwKy/w293AXlCBBMabGRFU74Dprm+5Cb83Pny6Oov3D0G4R1TAmGviIIHUCQX4nW91sePAN4NAizsHN0tJ+4NF+g1NCSoFT9Rw/IOv0q2KOf5TUiutlNxVMhdxPDMdSIlGZJiSuMx7/1ugrIF8NVJ8OeF4= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1704645644; 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=mvKVnzYDcYJctNc2cICiFhoj6DaJpEIGg5a3ufP82Zo=; b=KD3qDMHFkPlk3rgOZUIce/0wJr9U+4wVM1FoVdbGifiBb8P6hInVxNAV7FRGppNGAuZlCH YjENZdNJQIk7os1PohkkpfIGUzJRNngDpVCZeDb9xy25r+RKpqUTup6kUA6ogvH1hFMGJe 95oiRxG3E5/ZRQj7n5xD1zycgcNgDQ0= Received: from mail-qv1-f70.google.com (mail-qv1-f70.google.com [209.85.219.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-616-S5Sck1rfPq6hpdbsWyFyTA-1; Sun, 07 Jan 2024 11:40:41 -0500 X-MC-Unique: S5Sck1rfPq6hpdbsWyFyTA-1 Received: by mail-qv1-f70.google.com with SMTP id 6a1803df08f44-680b5b8bd27so15197456d6.3 for ; Sun, 07 Jan 2024 08:40:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704645640; x=1705250440; h=mime-version:references:message-id:in-reply-to:subject:cc:to:date :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=mvKVnzYDcYJctNc2cICiFhoj6DaJpEIGg5a3ufP82Zo=; b=nh2ZPBNNSVoRFZR03EryW1vE3Gl0RP3/xva/jTM6sbHcpkRUwtkv2blvYnjzQ89Rk+ Lj2qssBBWZWSN990ZCnM6/wkpO8EeDYb0RZ/pZ7U8qSLT60jtl6pyzfwF3VhLyMO7/fC gYoVOVaVd16eC/lIqK7mef+MIVwTIkeqL40Rty1KHhIQ3VbaR6FB5wX3Rxfrjopkcyh0 VF9ZWI9o53OECxdnit3sYq2+1QwKMK0+VyeWT9EZBVjQnZSPt4uXKszAvQcskB572TyD l5uU4yvY2t6rGWzA4eGoo7Bm9zpmzf5SyMh/cmbDiblMndxyVd+xiYTAcbXTVPKj2MdM +yYA== X-Gm-Message-State: AOJu0YwHVf2fuS6a/XSBe8bAsa8ts48liBf0IwQIAr7msAKtp7K79NtN mfsOfG5KvSs8uQ/IcbBO6BUzOGfGz0fSfoSgz7PRzeox9qrywuR0xFmOD8khQMtousRnPC9MRXW D3K23ehpc9U1vC1DMNXvFp1dbjQ== X-Received: by 2002:a05:6214:2b0f:b0:680:c741:2661 with SMTP id jx15-20020a0562142b0f00b00680c7412661mr1912644qvb.92.1704645640680; Sun, 07 Jan 2024 08:40:40 -0800 (PST) X-Google-Smtp-Source: AGHT+IGosFsAHw5s0R35tgEByyKw1y6c0ljqr5s0lnaHOJnVB6IYFAM2b0XBvUk5kXULpuMc43WMnw== X-Received: by 2002:a05:6214:2b0f:b0:680:c741:2661 with SMTP id jx15-20020a0562142b0f00b00680c7412661mr1912637qvb.92.1704645640446; Sun, 07 Jan 2024 08:40:40 -0800 (PST) Received: from [192.168.1.130] (ool-457670bb.dyn.optonline.net. [69.118.112.187]) by smtp.gmail.com with ESMTPSA id dm4-20020ad44e24000000b00680613267d5sm2203931qvb.115.2024.01.07.08.40.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 07 Jan 2024 08:40:40 -0800 (PST) From: Patrick Palka X-Google-Original-From: Patrick Palka Date: Sun, 7 Jan 2024 11:40:39 -0500 (EST) To: Jonathan Wakely cc: Jason Merrill , gcc-patches@gcc.gnu.org, libstdc++@gcc.gnu.org Subject: Re: [PATCH RFC] c++: mangle function template constraints In-Reply-To: Message-ID: References: <20231120025547.2938444-1-jason@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-14.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE 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 Tue, 5 Dec 2023, Jonathan Wakely wrote: > On Wed, 22 Nov 2023 at 14:50, Jonathan Wakely wrote: > > > > On Mon, 20 Nov 2023 at 02:56, Jason Merrill wrote: > > > > > > Tested x86_64-pc-linux-gnu. Are the library bits OK? Any comments before I > > > push this? > > > > The library parts are OK. > > > > The variable template is_trivially_copyable_v just uses > > __is_trivially_copyable so should be just as efficient, and the change > > to is fine. > > > > The variable template is_trivially_destructible_v instantiates the > > is_trivially_destructible type trait, which instantiates > > __is_destructible_safe and __is_destructible_impl, which is probably > > why we used the built-in directly in . But that's an > > acceptable overhead to avoid using the built-in in a mangled context, > > and it would be good to optimize the variable template anyway, as a > > separate change. > > This actually causes a regression: > > FAIL: 20_util/variant/87619.cc -std=gnu++20 (test for excess errors) > FAIL: 20_util/variant/87619.cc -std=gnu++23 (test for excess errors) > FAIL: 20_util/variant/87619.cc -std=gnu++26 (test for excess errors) > > It's OK for C++17 because the changed code is only used for C++20 and later. > > That test instantiates a very large variant to check that we don't hit > our template instantiation depth limit. Using the variable template > (which uses the class template) instead of the built-in causes it to > fail now. Could we pass down __trivially_destructible from _Variadic_storage to _Variadic_union and use that as the dtor's constraint instead of recursively re-computing it? This reduces the maximum template instantiation depth for 87619.cc to ~270 from ~780 so that the depth is roughly #variants rather than 4 * #variants. diff --git a/libstdc++-v3/include/std/variant b/libstdc++-v3/include/std/variant index 20a76c8aa87..4b9002e0917 100644 --- a/libstdc++-v3/include/std/variant +++ b/libstdc++-v3/include/std/variant @@ -392,7 +392,7 @@ namespace __variant }; // Defines members and ctors. - template + template union _Variadic_union { _Variadic_union() = default; @@ -401,8 +401,8 @@ namespace __variant _Variadic_union(in_place_index_t<_Np>, _Args&&...) = delete; }; - template - union _Variadic_union<_First, _Rest...> + template + union _Variadic_union<__trivially_destructible, _First, _Rest...> { constexpr _Variadic_union() : _M_rest() { } @@ -427,13 +427,12 @@ namespace __variant ~_Variadic_union() = default; constexpr ~_Variadic_union() - requires (!is_trivially_destructible_v<_First>) - || (!is_trivially_destructible_v<_Variadic_union<_Rest...>>) + requires (!__trivially_destructible) { } #endif _Uninitialized<_First> _M_first; - _Variadic_union<_Rest...> _M_rest; + _Variadic_union<__trivially_destructible, _Rest...> _M_rest; }; // _Never_valueless_alt is true for variant alternatives that can @@ -514,7 +513,7 @@ namespace __variant return this->_M_index != __index_type(variant_npos); } - _Variadic_union<_Types...> _M_u; + _Variadic_union _M_u; using __index_type = __select_index<_Types...>; __index_type _M_index; }; @@ -552,7 +551,7 @@ namespace __variant return this->_M_index != static_cast<__index_type>(variant_npos); } - _Variadic_union<_Types...> _M_u; + _Variadic_union _M_u; using __index_type = __select_index<_Types...>; __index_type _M_index; }; > > So optimizing the variable template is now a priority. > >