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 [63.128.21.124]) by sourceware.org (Postfix) with ESMTP id D3B193854832 for ; Thu, 29 Oct 2020 15:15:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org D3B193854832 Received: from mail-qt1-f198.google.com (mail-qt1-f198.google.com [209.85.160.198]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-404-DCUfZCYcMGO9d_nCFLagkQ-1; Thu, 29 Oct 2020 11:15:35 -0400 X-MC-Unique: DCUfZCYcMGO9d_nCFLagkQ-1 Received: by mail-qt1-f198.google.com with SMTP id e92so2041681qtd.20 for ; Thu, 29 Oct 2020 08:15:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=IkBIkxlRhtFaK4//VIyeN1gmW/uUGhQZwpCKAwcdKzU=; b=ThHm2uzdwKmndipGHCYIUsxQS3TIYaQ/ZpZHhs7pXTXGQ8tIopYV/otEisLXN21eyL 1SogXxBl8zdiqScMwsOSeDzdxOdORa8+UL2LCThckTuu8n1dZga68ImB15sZap9AOhTo dnv1oSyvPobFK5QQ34snIE6/P2HuD/x6gMHsPJmQRMOwYbITTO0XVdLuSOzCC3ai1WZ4 ppgx8zIlIn2ZK/Ur3WalcSNp7iHt/kU4WQbs4HY78eUE0IPYlFIsDnQeQE0rmyPIgW9I fzQNZezkrNTSeD3cBZ1it3zeQuNFy5wa5kmVQCH0yiEE1gxIomv0qx3PZSJZt34L4FeY t+mw== X-Gm-Message-State: AOAM530WMJynHK2MCsj/iCHIc7aypypI/wjBBLGgfwUiBgSUC876rshj 0OOejFITxqbu7KFF3fAveTFZUK0+K8FYZ/vZ9RkO6u3LIDtkEQxpmVaQTO+zYdhbeemhgMFbJ+G vMhyfa0T/0iRh+SuXSg== X-Received: by 2002:ac8:3568:: with SMTP id z37mr4095021qtb.20.1603984533648; Thu, 29 Oct 2020 08:15:33 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzfYMidlDQdQx1rdRzv2A1NIiDJlRw0kyf7Ugup0DAnubT+q7B6vaXKkBCsGMkqUjd3mWlWIA== X-Received: by 2002:ac8:3568:: with SMTP id z37mr4094991qtb.20.1603984533328; Thu, 29 Oct 2020 08:15:33 -0700 (PDT) Received: from [192.168.1.148] (209-6-216-142.s141.c3-0.smr-cbr1.sbo-smr.ma.cable.rcncustomer.com. [209.6.216.142]) by smtp.gmail.com with ESMTPSA id v17sm1252428qkb.13.2020.10.29.08.15.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Oct 2020 08:15:32 -0700 (PDT) Subject: Re: [PATCH v2] c++: Prevent warnings for value-dependent exprs [PR96742] To: Marek Polacek Cc: GCC Patches References: <20201024225231.2369564-1-polacek@redhat.com> <20201028180029.GB26929@redhat.com> <4c9889ae-8f4e-5b8b-9c8e-0aa3ccacd40a@redhat.com> <20201028212947.GC26929@redhat.com> <7f4732cf-402a-972b-6c57-8a1860e39935@redhat.com> <20201029024536.GA104335@redhat.com> From: Jason Merrill Message-ID: <46360592-f58a-8845-6074-40a9e604257c@redhat.com> Date: Thu, 29 Oct 2020 11:15:32 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <20201029024536.GA104335@redhat.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-16.6 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H5, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2020 15:15:38 -0000 On 10/28/20 10:45 PM, Marek Polacek wrote: > On Wed, Oct 28, 2020 at 05:48:08PM -0400, Jason Merrill wrote: >> On 10/28/20 5:29 PM, Marek Polacek wrote: >>> On Wed, Oct 28, 2020 at 02:46:36PM -0400, Jason Merrill wrote: >>>> On 10/28/20 2:00 PM, Marek Polacek wrote: >>>>> On Tue, Oct 27, 2020 at 01:36:30PM -0400, Jason Merrill wrote: >>>>>> On 10/24/20 6:52 PM, Marek Polacek wrote: >>>>>>> Here, in r11-155, I changed the call to uses_template_parms to >>>>>>> type_dependent_expression_p_push to avoid a crash in C++98 in >>>>>>> value_dependent_expression_p on a non-constant expression. But that >>>>>>> prompted a host of complaints that we now warn for value-dependent >>>>>>> expressions in templates. Those warnings are technically valid, but >>>>>>> people still don't want them because they're awkward to avoid. So let's >>>>>>> partially revert my earlier fix and make sure that we don't ICE in >>>>>>> value_dependent_expression_p by checking potential_constant_expression >>>>>>> first. >>>>>>> >>>>>>> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/10? >>>>>>> >>>>>>> gcc/cp/ChangeLog: >>>>>>> >>>>>>> PR c++/96675 >>>>>>> PR c++/96742 >>>>>>> * pt.c (tsubst_copy_and_build): Call uses_template_parms instead of >>>>>>> type_dependent_expression_p_push. Only call uses_template_parms >>>>>>> for expressions that are potential_constant_expression. >>>>>>> >>>>>>> gcc/testsuite/ChangeLog: >>>>>>> >>>>>>> PR c++/96675 >>>>>>> PR c++/96742 >>>>>>> * g++.dg/warn/Wdiv-by-zero-3.C: Turn dg-warning into dg-bogus. >>>>>>> * g++.dg/warn/Wtautological-compare3.C: New test. >>>>>>> * g++.dg/warn/Wtype-limits5.C: New test. >>>>>>> * g++.old-deja/g++.pt/crash10.C: Remove dg-warning. >>>>>>> --- >>>>>>> gcc/cp/pt.c | 6 ++++-- >>>>>>> gcc/testsuite/g++.dg/warn/Wdiv-by-zero-3.C | 6 ++++-- >>>>>>> gcc/testsuite/g++.dg/warn/Wtautological-compare3.C | 11 +++++++++++ >>>>>>> gcc/testsuite/g++.dg/warn/Wtype-limits5.C | 11 +++++++++++ >>>>>>> gcc/testsuite/g++.old-deja/g++.pt/crash10.C | 1 - >>>>>>> 5 files changed, 30 insertions(+), 5 deletions(-) >>>>>>> create mode 100644 gcc/testsuite/g++.dg/warn/Wtautological-compare3.C >>>>>>> create mode 100644 gcc/testsuite/g++.dg/warn/Wtype-limits5.C >>>>>>> >>>>>>> diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c >>>>>>> index dc664ec3798..8aa0bc2c0d8 100644 >>>>>>> --- a/gcc/cp/pt.c >>>>>>> +++ b/gcc/cp/pt.c >>>>>>> @@ -19618,8 +19618,10 @@ tsubst_copy_and_build (tree t, >>>>>>> { >>>>>>> /* If T was type-dependent, suppress warnings that depend on the range >>>>>>> of the types involved. */ >>>>>>> - bool was_dep = type_dependent_expression_p_push (t); >>>>>>> - >>>>>>> + ++processing_template_decl; >>>>>>> + const bool was_dep = (!potential_constant_expression (t) >>>>>>> + || uses_template_parms (t)); >>>>>> >>>>>> We don't want to suppress warnings for a non-constant expression that uses >>>>>> no template parms. So maybe >>>>> >>>>> Fair enough. >>>>> >>>>>> potential_c_e ? value_d : type_d >>>>> >>>>> That works for all the cases I have. >>>>> >>>>>> ? Or perhaps instantiation_dependent_expression_p. >>>>> >>>>> i_d_e_p would still crash in C++98 :(. >>>> >>>> Perhaps we should protect the value_d call in i_d_e_p with potential_c_e? >>> >>> Yeah, probably. But then we should also guard the call to value_d in >>> uses_template_parms. I can apply such a patch if it tests fine, if you >>> want. >> >> Or change uses_template_parms to use i_d. > > Experimenting with this revealed a curious issue: when we have > __PRETTY_FUNCTION__ in a template function, we set its DECL_VALUE_EXPR > to error_mark_node (cp_make_fname_decl), so potential_c_e returns false > when it gets it, but value_dependent_expression_p handles it specially > and says true. So this patch > > --- a/gcc/cp/pt.c > +++ b/gcc/cp/pt.c > @@ -27277,7 +27277,8 @@ bool > instantiation_dependent_expression_p (tree expression) > { > return (instantiation_dependent_uneval_expression_p (expression) > - || value_dependent_expression_p (expression)); > + || (potential_constant_expression (expression) > + && value_dependent_expression_p (expression))); > } > > /* Like type_dependent_expression_p, but it also works while not processing > > breaks lambda-generic-pretty1.C. ISTM that potential_c_e should return > true for a DECL_PRETTY_FUNCTION_P with error DECL_VALUE_EXPR. Agreed. Jason