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.129.124]) by sourceware.org (Postfix) with ESMTPS id 522DF385841C for ; Fri, 18 Nov 2022 16:24:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 522DF385841C 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=1668788696; 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=a7hjcjAhqTA4OFGK6CtbvL1LZSepRSSLKN3ECi+tF18=; b=Qz+Ubox0MlxnYUK2Ui5ObUXiontz3Jst4Mtsteih58oRELGp6+OI6qZkGsql9m88dTz476 FYzPxZqVabbVVFQgoz+j1Ok7ATe1jEJ24NYqDG9Nh64RS8ZDXjpZa983cdEmXoQP38krPq VD3z13pWM/u/ntzHSOV4unPkim+xvjs= 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_128_GCM_SHA256) id us-mta-637-cQmymNklORenmzD1GUeCJA-1; Fri, 18 Nov 2022 11:24:48 -0500 X-MC-Unique: cQmymNklORenmzD1GUeCJA-1 Received: by mail-qv1-f70.google.com with SMTP id h13-20020a0ceecd000000b004c6964dc952so1795848qvs.13 for ; Fri, 18 Nov 2022 08:24:48 -0800 (PST) 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:message-id:reply-to; bh=a7hjcjAhqTA4OFGK6CtbvL1LZSepRSSLKN3ECi+tF18=; b=WYUSxNwI36+zwArbxVOtSoFAsuOyKrTHEI7NRkmiCy9r1MuzLMx4u7cI1ItSNfshf2 tEMiIsi605CIfx2e6+ZwO87QU1LFJ3Zgw3844bGidwI1LY/K4xWdKz+ek8esoEp4xA0L na8qfwlqcJTaDEn0D3j6z2DVmSj3M/baGobckMfz6DyZPQvGpN3XDusmr69EOpf9tqFt lNGIQUdZaITj/WkbdY3Hz6hk6hIwa+GKcpvgChK+IUymv4LRnx7w/bXyxC+m1DwjtUma YmUncWE/0Qd/S75CzD4mC47P/kbszxP5meeu9c8uRSFp+kqs57gqthzgT+Ir4pr8BENO wyqA== X-Gm-Message-State: ANoB5pl0MXKnzGe+2NOu+oQOxHo0emu5DXEuAZDSPuLRWn4Eo10wCXEP KjiKsZXTMholyHyZrG/Ked0QNBkAhdXeTWpjYHsGj4CAiE5kIUz5C5ACz67+mNF7LpDR9Q7n44e MS7A1sqEtZHQ9i3Uuuw== X-Received: by 2002:ac8:13c7:0:b0:3a5:36cd:a5a4 with SMTP id i7-20020ac813c7000000b003a536cda5a4mr7554457qtj.81.1668788687560; Fri, 18 Nov 2022 08:24:47 -0800 (PST) X-Google-Smtp-Source: AA0mqf5N18/ylgcTnXqxD8I3JOT4MxbadmjVONLRUHN9pXSV/9wc0zJ8U6hY/tE2T1rhmYUrIRz7wQ== X-Received: by 2002:ac8:13c7:0:b0:3a5:36cd:a5a4 with SMTP id i7-20020ac813c7000000b003a536cda5a4mr7554435qtj.81.1668788687221; Fri, 18 Nov 2022 08:24:47 -0800 (PST) Received: from [192.168.1.101] (130-44-159-43.s15913.c3-0.arl-cbr1.sbo-arl.ma.cable.rcncustomer.com. [130.44.159.43]) by smtp.gmail.com with ESMTPSA id c9-20020ac81109000000b003a569a0afcasm2162881qtj.66.2022.11.18.08.24.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 18 Nov 2022 08:24:46 -0800 (PST) Message-ID: <529c47ee-b6ff-b5dd-8d4b-1844c46ddbd6@redhat.com> Date: Fri, 18 Nov 2022 11:24:45 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 Subject: Re: [PATCH] c++, v4: Implement C++23 P2647R1 - Permitting static constexpr variables in constexpr functions To: Marek Polacek , Jakub Jelinek Cc: Jonathan Wakely , gcc-patches@gcc.gnu.org References: <016f168b-f143-baff-5f71-c48d4611ae11@redhat.com> <740b5e1e-7143-c291-5594-af937867fbc3@redhat.com> 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=-6.4 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_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 11/18/22 10:03, Marek Polacek wrote: > On Fri, Nov 18, 2022 at 08:48:32AM +0100, Jakub Jelinek wrote: >> On Thu, Nov 17, 2022 at 07:15:05PM -0500, Marek Polacek wrote: >>>> --- gcc/cp/decl.cc.jj 2022-11-16 14:44:43.692339668 +0100 >>>> +++ gcc/cp/decl.cc 2022-11-17 20:53:44.102011594 +0100 >>>> @@ -5600,6 +5600,57 @@ groktypename (cp_decl_specifier_seq *typ >>>> return type; >>>> } >>>> >>>> +/* For C++17 and older diagnose static or thread_local decls in constexpr >>>> + or consteval functions. For C++20 similarly, except if they are >>> >>> In C++17 we don't support consteval so I guess drop the "or consteval "? >> >> I just forgot to update the function comment. >> >> Anyway, I think: >> >>> BTW, I notice that the patch breaks >>> g++.dg/cpp1y/lambda-generic-func1.C >>> g++.dg/cpp1z/constexpr-lambda16.C >>> Maybe they just need dg- tweaks. >> >> this is actually a real bug and I'm not sure how to resolve that. >> >> We have there: >> >> int main() >> { >> [](auto i) { if (i) { int j; static int k; return i + j; } return i; }(0); >> } >> >> and for C++17/20 I presume something (haven't figured out yet what) marks > > Right, that's the C++17 implicit constexpr for lambdas, finish_function: > > /* Lambda closure members are implicitly constexpr if possible. */ > if (cxx_dialect >= cxx17 > && LAMBDA_TYPE_P (CP_DECL_CONTEXT (fndecl))) > DECL_DECLARED_CONSTEXPR_P (fndecl) > = ((processing_template_decl > || is_valid_constexpr_fn (fndecl, /*complain*/false)) > && potential_constant_expression (DECL_SAVED_TREE (fndecl))); Yeah, I guess potential_constant_expression needs to be stricter in a lambda. Or perhaps any function that isn't already DECL_DECLARED_CONSTEXPR_P? >> the lambda operator() when still a template as constexpr and then >> cp_finish_decl -> diagnose_static_in_constexpr pedwarns on it. >> For the above perhaps we could figure out there is a static int k; in the >> operator() and don't turn it into constexpr, but what if there is >> something that would e.g. satisfy decl_maybe_constant_var_p but not >> decl_constant_var_p when actually instantiated? I'd expect the above change to potential_c_e to handle that case. Jason