From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) by sourceware.org (Postfix) with ESMTPS id 0989B3858C52 for ; Thu, 28 Sep 2023 19:09:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0989B3858C52 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-il1-x12a.google.com with SMTP id e9e14a558f8ab-3512efed950so34115665ab.2 for ; Thu, 28 Sep 2023 12:09:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695928179; x=1696532979; darn=gcc.gnu.org; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=ynPsDkyOcpPxftLFceLBgLS+esDzHBnI/a1ta6gat7U=; b=cjeEPNvWgWG9o1Vhv9ljxqiyxlbnvPMA5MdPNN1c7bca/l8/wYvzu9CQnVeSpefle8 hR2rTte0bFlGvIMPmUV/nN8M/YRU/D6jW0DhgfRzbTydCneqbWbZoX/q43R6cPKNRKE+ LSouVpdJQBR7qxV7k+Agxrnd9Xr7kSdHd3O2cqRkL5zxYPQu4V8L6dvkEVqbVMRbP9h2 daCpHeUpo/dg7kc/ZlHCOehl3WtJZYQjTaXW3NAfbJMBTLyf7PmEAgkol/2s6LIdYvfN QRbviGol/O/Wwa3i188xjDp3N6s2VrfIpr0hZaEeXde1QENXsfP9eXVjcucgpoJG09Ud jWGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695928179; x=1696532979; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ynPsDkyOcpPxftLFceLBgLS+esDzHBnI/a1ta6gat7U=; b=UyGqWF70e766cq8WJwtVikjxqvL15tDQ5udnjru4u19rwOLuen4g6VS6K7PpU1xzHS 1E+7IEKVRWc9Kc6sA72ujP7yUbSMpuWRs+hBGRu0m8Orttq0ORC+QDL6VJOtdaEOCIiL pePtMeOw2MxGvPqsr8AmiIAFdNPUnkKavoyK/tOAlVwkqWTeAQbDs5KNOA9ZVLbSSm2L 9YG2Bk1m7V34RR7+dudAOydDxOztylHoWY2FYF7sWb1eBvBO/GIiljEh34vSUN8QWN4/ 86ooulLTBGnTSOWzseKnMxyBt3h91gCyuI43u8SqGO3JRET++EUXfp9G1rHID1nAHu+p N4Ug== X-Gm-Message-State: AOJu0YzfTua/LVf4o9R9sSR2cwiFmuLaFIJKbh41nWnaVKCIfpWwV0uZ 4YshL7DUgy40X8AxNTjZ6sM= X-Google-Smtp-Source: AGHT+IEhFeSexJrTtNrw+WblyhUhIeEsagImLAWB6vfdpoDrP9FmqinciEk5T2KFGPgWNS9ipwCjwg== X-Received: by 2002:a05:6e02:e4f:b0:34f:203c:2432 with SMTP id l15-20020a056e020e4f00b0034f203c2432mr1750261ilk.12.1695928179024; Thu, 28 Sep 2023 12:09:39 -0700 (PDT) Received: from [172.31.0.109] ([136.36.130.248]) by smtp.gmail.com with ESMTPSA id gq1-20020a0566382d0100b0042319c38763sm4817652jab.15.2023.09.28.12.09.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 28 Sep 2023 12:09:38 -0700 (PDT) Message-ID: <3e29a0ea-b143-4128-92bf-40f6fc01762b@gmail.com> Date: Thu, 28 Sep 2023 13:09:37 -0600 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] Remove poly_int_pod Content-Language: en-US To: Jason Merrill , gcc-patches@gcc.gnu.org, jakub@redhat.com, richard.sandiford@arm.com References: <8673fdfc-4b16-ff4a-8906-c47403cde825@redhat.com> From: Jeff Law In-Reply-To: <8673fdfc-4b16-ff4a-8906-c47403cde825@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,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 9/28/23 11:26, Jason Merrill wrote: > On 9/28/23 05:55, Richard Sandiford wrote: >> poly_int was written before the switch to C++11 and so couldn't >> use explicit default constructors.  This led to an awkward split >> between poly_int_pod and poly_int.  poly_int simply inherited from >> poly_int_pod and added constructors, with the argumentless constructor >> having an empty body.  But inheritance meant that poly_int had to >> repeat the assignment operators from poly_int_pod (again, no C++11, >> so no "using" to inherit base-class implementations). >> >> All that goes away if we switch to using default constructors. >> >> The main complication is ensuring that braced initialisation still >> gives a constexpr, so that static variables can be initialised without >> runtime code.  The two problems here are: >> >> (1) When initialising a poly_int with fewer than N >>      coefficients, the other coefficients need to be a zero of >>      the same precision as the explicit coefficients.  This was >>      previously done in a for loop using wi::ints_for<...>::zero, >>      but C++11 constexpr constructors can't have function bodies. >>      The patch instead uses a series of delegated initialisers to >>      fill in the implicit coefficients. > > Perhaps it's time to update the bootstrap requirement to C++14 (i.e. GCC > 5, from eight years ago).  Not that this would affect this particular > patch. IIRC the primary reason we settled on gcc-4.8.x was RHEL7/Centos7. With RHEL 7 approaching EOL moving the baseline forward would seem to make sense. I'd want to know if this affects folks using SuSE's enterprise distro before actually making the change, but I'm broadly in favor of moving forward it it's not going to have a major impact on users that are using enterprise distros. jeff