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 A1BE33858D20 for ; Fri, 27 Jan 2023 23:17:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A1BE33858D20 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=1674861424; 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=3fRyHjFJ2BLHrPz+KKUEAKFLBnwrhBNKnNAXoMxtZKQ=; b=Mp3vpmUP1GaVTrtdOc6pd2l6Gdw4tYBju87caCSKEtrPzLldTSSRu6o8ecReTAwKZye1pi 3Rmxitad7Ra5WaFUsupN9YtQdaCxV95Aoav8CBYKvoOvaCmgIdYfSE3Qql2kohploOLu9O 6cQCnvlwCuQug+N8vv+MhQkO0ucpp+Q= Received: from mail-qv1-f72.google.com (mail-qv1-f72.google.com [209.85.219.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-25-EeDwOCIeMtW5AzhUiAsU2g-1; Fri, 27 Jan 2023 18:17:03 -0500 X-MC-Unique: EeDwOCIeMtW5AzhUiAsU2g-1 Received: by mail-qv1-f72.google.com with SMTP id px22-20020a056214051600b00537657b0449so3593625qvb.23 for ; Fri, 27 Jan 2023 15:17:02 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=3fRyHjFJ2BLHrPz+KKUEAKFLBnwrhBNKnNAXoMxtZKQ=; b=rsSU8647SLrpnzTgdEQdL1HJYUns1YKtEQDtWa8EylZdQsAIP41TF0UaUo+AFmaebZ CCjNfpq7stUd09A/3SR1a+GEO6KuMWKFyGxIrmggtibnc9VDbz8ljy+iYfJX2xIu8L+i ef7D4s+bh4DkGVtWdPRCEQZvYIU83h/o6dpVAMODZgfbp1L5Mz9o5QeGDgtYiiHMA0R7 Ts5XhD1tqn1H9c1CwTWVYT558MgthPapBWFVe4cBTSAmS27rq/TthxwEK01Gx1cWcp2K ux2pT/f+GhDszUx6a/Zl4VeSbM3UXvqwrp50JWzBxclkuYmPPwDy/JC4a03MRqtTyrHQ vhZA== X-Gm-Message-State: AO0yUKXGDf9dRyx+kJU7cfzt4N8td2pZqy87Ny0kqIqDtDRpilTLcEfH EOGai/cyMBBHh/LnnCH+68XymzQXvnzqbDpnvPwMJ2jRhVsL0aMMZ0w1D6BWw7AvMr8u4wgSuXL kQ5JDKzDPZ1EM11Se1w== X-Received: by 2002:a05:622a:44f:b0:3b8:312e:bafb with SMTP id o15-20020a05622a044f00b003b8312ebafbmr979501qtx.46.1674861422528; Fri, 27 Jan 2023 15:17:02 -0800 (PST) X-Google-Smtp-Source: AK7set+6xcryvhIWDAxoRbzUKUM8KKtejcdK4++brSdcoUUlIkhdlpoQH3/KXsjilu3Ijc7dNOPqIw== X-Received: by 2002:a05:622a:44f:b0:3b8:312e:bafb with SMTP id o15-20020a05622a044f00b003b8312ebafbmr979472qtx.46.1674861422253; Fri, 27 Jan 2023 15:17:02 -0800 (PST) Received: from [192.168.1.130] (ool-457670bb.dyn.optonline.net. [69.118.112.187]) by smtp.gmail.com with ESMTPSA id d10-20020ac800ca000000b003b0b903720esm3552022qtg.13.2023.01.27.15.17.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 27 Jan 2023 15:17:01 -0800 (PST) From: Patrick Palka X-Google-Original-From: Patrick Palka Date: Fri, 27 Jan 2023 18:17:00 -0500 (EST) To: Marek Polacek cc: Patrick Palka , Jason Merrill , GCC Patches Subject: Re: [PATCH] c++: fix ICE with -Wduplicated-cond [PR107593] In-Reply-To: Message-ID: References: <20230126221732.617749-1-polacek@redhat.com> <6cd96b09-828b-8820-e1f7-7f11a90e0f54@idea> 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=-13.9 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_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 Fri, 27 Jan 2023, Marek Polacek wrote: > On Fri, Jan 27, 2023 at 05:15:00PM -0500, Patrick Palka wrote: > > On Thu, 26 Jan 2023, Marek Polacek via Gcc-patches wrote: > > > > > Here we crash because a CAST_EXPR, representing T(), doesn't have > > > its operand, and operand_equal_p's STRIP_ANY_LOCATION_WRAPPER doesn't > > > expect that. (o_e_p is called from warn_duplicated_cond_add_or_warn.) > > > > > > In the past we've adjusted o_e_p to better cope with template codes, > > > but in this case I think we just want to avoid attempting to warn > > > about inst-dependent expressions; I don't think I've ever envisioned > > > -Wduplicated-cond to warn about them. > > > > > > The ICE started with r12-6022, two-stage name lookup for overloaded > > > operators, which gave dependent operators a TREE_TYPE (in particular, > > > DEPENDENT_OPERATOR_TYPE), so we no longer bail out here in o_e_p: > > > > > > /* Similar, if either does not have a type (like a template id), > > > they aren't equal. */ > > > if (!TREE_TYPE (arg0) || !TREE_TYPE (arg1)) > > > return false; > > > > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > > > > > PR c++/107593 > > > > > > gcc/cp/ChangeLog: > > > > > > * parser.cc (cp_parser_selection_statement): Don't do > > > -Wduplicated-cond when the condition is dependent. > > > > > > gcc/testsuite/ChangeLog: > > > > > > * g++.dg/warn/Wduplicated-cond3.C: New test. > > > --- > > > gcc/cp/parser.cc | 3 +- > > > gcc/testsuite/g++.dg/warn/Wduplicated-cond3.C | 38 +++++++++++++++++++ > > > 2 files changed, 40 insertions(+), 1 deletion(-) > > > create mode 100644 gcc/testsuite/g++.dg/warn/Wduplicated-cond3.C > > > > > > diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc > > > index 4cdc1cd472f..3df85d49e16 100644 > > > --- a/gcc/cp/parser.cc > > > +++ b/gcc/cp/parser.cc > > > @@ -13209,7 +13209,8 @@ cp_parser_selection_statement (cp_parser* parser, bool *if_p, > > > /* Add the condition. */ > > > condition = finish_if_stmt_cond (condition, statement); > > > > > > - if (warn_duplicated_cond) > > > + if (warn_duplicated_cond > > > + && !instantiation_dependent_expression_p (condition)) > > > warn_duplicated_cond_add_or_warn (token->location, condition, > > > &chain); > > > > I noticed warn_duplicated_cond_add_or_warn already has logic to handle > > TREE_SIDE_EFFECTS conditions by invaliding the entire chain. I wonder > > if we'd want to do the same for instantiation-dep conditions? > > warn_duplicated_cond_add_or_warn lives in c-family/c-warn.cc so I can't > use instantiation_dependent_expression_p there. Sure, I could write a > C++ wrapper but with my patch we just won't add CONDITION to the chain > which I thought would work just as well. Ah that's unfortunate :( ISTM desirable to conservatively assume an inst-dep cond has side effects though (possibly directly from cp_parser_selection_statement), to avoid false positives as in: int n; template bool g() { n = 42; } template void f() { if (n) ; else if (g()) ; else if (n) ; }