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 AB1B0386F802 for ; Fri, 10 May 2024 19:42:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org AB1B0386F802 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 AB1B0386F802 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=1715370163; cv=none; b=C7k/zOfN/kDyHy4QO+feJnxZGcvv5NCxCd0rPGzdZDP/liR6QkOCQHqIL6kVz6QfyXo+BuWexepYa9yRransPfIHHiHyeKtmVVVVlMG1kq4Ur1+ssayQMLmKfXtGBHdsyyqkJTLU5ovb/tquYBTzhlEnP/nTRgEyfynMymaHjRg= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1715370163; c=relaxed/simple; bh=65bHw/6/hleIhDTmSjuXtduRVEpnBSzDhgjNXQDRiK0=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=DP2O/2EjgsnAHwGhyFFIX65kT2eNhqKFgGWAgSgp7CmfHpy6bllpROn9ow6vLpg16NzBFKs8zd1KRl9s4s+h77e4J955Xxp3ZDiZGxyan6CV1Sd8aeYXo4mkhxSRA3+k97D3ZO6XJ9dRDqzSPHt/Ln/anBX36eMjf/iDNZvBQF4= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1715370160; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=odaQ5tS0O8cXziA38fkmRxAtpFQAOBcgMSGX6z5tDDg=; b=ggFqNxF6rn8vcbmpL4JHOf3iIGq7NbwlRkwu+29KuxfDP0evqE/Q8Bh9dbtJ/hfv2PxGL3 FJ+8XMZSqiW9GF79fKAGPvbwSWRj4WQfnjhPkBUUoJ6nLSzjbj9RTjfXjDxS3l6oKWNaVI a7384/haYQOmD1O3jqvySxurIirRRis= Received: from mail-qk1-f198.google.com (mail-qk1-f198.google.com [209.85.222.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-570-UxUhfmEsM_26np4xsHHMfQ-1; Fri, 10 May 2024 15:42:19 -0400 X-MC-Unique: UxUhfmEsM_26np4xsHHMfQ-1 Received: by mail-qk1-f198.google.com with SMTP id af79cd13be357-790f306e369so250541585a.3 for ; Fri, 10 May 2024 12:42:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715370138; x=1715974938; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=odaQ5tS0O8cXziA38fkmRxAtpFQAOBcgMSGX6z5tDDg=; b=vO+/KSVb4sC6GKgeja8zXcbxGuwkkFkGOtbmpD5fmxJkLr+crfnBy122OoY+qdr417 Uj6t2R8gWyqOXuSdXXIKhDLmPfJGYQf7he40jbtAPGRR8ZclWmSoxdRAFyA2Tr/UzqRu WCgaVIhZvSEE4f1N9pPpmlrTtp58NuibGoFAxLkv27yMY1P15CNlgeOtrlxafGi6vigl m6acqDQJFaIjQxZCV1t+gP01eylrxMQvgnzJfebgYVGHqGfCaRLGEOxySMkEQDcYurUV 36AGHOOn5quQOG9E0WEKMUhXEKh/5i6DfhQKkfcXLRQCdYRR5vNQIoXB38pUSu2wpLtG 7KnA== X-Forwarded-Encrypted: i=1; AJvYcCWwz2pGZdKpT8JAR3Iu9NzM6uDfvsrlvzrV8mJbVExP0S9hzeiZWFnf+7VIkTLhPxP+U1CeqPVLiV98uM6rq2llbK6lfnbXag== X-Gm-Message-State: AOJu0Yy2bGLEIeMO7NjNB/pKKLurwgNtGHmA2/i80Fb7wfyiWpE0F/Os N8n8y/Zo6bPwXJvu/l+T8rVGlEOu0TO7eEm0yP0P6VDJZXpLRkTbXssOl7hSPyQnYb6tkvC5SlD xv/ZvZmmyhwufwdPh0k1NF+on7oZJnldbhoeXJkOpsxqstSesNgCJZbI= X-Received: by 2002:a05:620a:7f7:b0:792:970a:86a6 with SMTP id af79cd13be357-792c760e8f2mr325722185a.65.1715370138421; Fri, 10 May 2024 12:42:18 -0700 (PDT) X-Google-Smtp-Source: AGHT+IF89K3yg/wyMZy9apYF7xNOoGUIQrL3mJnY0WfeY6Yo3Kim77FdvBWKvN7pcTOooeSN8Dz9zw== X-Received: by 2002:a05:620a:7f7:b0:792:970a:86a6 with SMTP id af79cd13be357-792c760e8f2mr325720885a.65.1715370138071; Fri, 10 May 2024 12:42:18 -0700 (PDT) Received: from [192.168.1.130] (130-44-146-16.s12558.c3-0.arl-cbr1.sbo-arl.ma.cable.rcncustomer.com. [130.44.146.16]) by smtp.gmail.com with ESMTPSA id af79cd13be357-792bf2fc614sm209191685a.88.2024.05.10.12.42.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 10 May 2024 12:42:17 -0700 (PDT) Message-ID: <1954fac4-af79-459a-9554-94b778786e05@redhat.com> Date: Fri, 10 May 2024 15:42:16 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] c++: lvalueness of non-dependent assignment [PR114994] To: Patrick Palka , gcc-patches@gcc.gnu.org References: <20240509202300.2742125-1-ppalka@redhat.com> From: Jason Merrill In-Reply-To: <20240509202300.2742125-1-ppalka@redhat.com> 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=-12.6 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_H4,RCVD_IN_MSPIKE_WL,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 5/9/24 16:23, Patrick Palka wrote: > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look > OK for trunk/14? For trunk as a follow-up I can implement the > mentionted representation change to use CALL_EXPR instead of > MODOP_EXPR for a non-dependent simple assignment expression that > resolved to an operator= overload. > > -- >8 -- > > r14-4111 made us check non-dependent assignment expressions ahead of > time, as well as give them a type. Unlike for compound assignment > expressions however, if a simple assignment resolves to an operator > overload we still represent it as a (typed) MODOP_EXPR instead of a > CALL_EXPR to the selected overload. This, I reckoned, was just a > pessimization (since we'll have to repeat overload resolution at > instantiatiation time) but should be harmless. (And it should be > easily fixable by giving cp_build_modify_expr an 'overload' parameter). > > But it breaks the below testcase ultimately because MODOP_EXPR (of > non-reference type) is always treated as an lvalue according to > lvalue_kind, which is incorrect for the MODOP_EXPR representing x=42. > > We can fix this by representing such assignment expressions as CALL_EXPRs > matching what that of compound assignments, but that turns out to > require some tweaking of our -Wparentheses warning logic which seems > unsuitable for backporting. > > So this patch instead more conservatively fixes this by refining > lvalue_kind to consider the type of a (simple) MODOP_EXPR as we > already do for COND_EXPR. > > PR c++/114994 > > gcc/cp/ChangeLog: > > * tree.cc (lvalue_kind) : Consider the > type of a simple assignment expression. > > gcc/testsuite/ChangeLog: > > * g++.dg/template/non-dependent32.C: New test. > --- > gcc/cp/tree.cc | 7 +++++++ > .../g++.dg/template/non-dependent32.C | 18 ++++++++++++++++++ > 2 files changed, 25 insertions(+) > create mode 100644 gcc/testsuite/g++.dg/template/non-dependent32.C > > diff --git a/gcc/cp/tree.cc b/gcc/cp/tree.cc > index f1a23ffe817..0b97b789aab 100644 > --- a/gcc/cp/tree.cc > +++ b/gcc/cp/tree.cc > @@ -275,6 +275,13 @@ lvalue_kind (const_tree ref) > /* We expect to see unlowered MODOP_EXPRs only during > template processing. */ > gcc_assert (processing_template_decl); > + if (TREE_CODE (TREE_OPERAND (ref, 1)) == NOP_EXPR > + && CLASS_TYPE_P (TREE_TYPE (TREE_OPERAND (ref, 0)))) > + /* As in the COND_EXPR case, but for non-dependent assignment > + expressions created by build_x_modify_expr. */ > + goto default_; This seems overly specific, I'd think the same thing would apply to += and such? Jason