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 [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id 56901394480A for ; Thu, 26 Nov 2020 10:02:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 56901394480A Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-185-YcZXzyeiMfW5CtBvhG4vFw-1; Thu, 26 Nov 2020 05:02:38 -0500 X-MC-Unique: YcZXzyeiMfW5CtBvhG4vFw-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id C5817185E489; Thu, 26 Nov 2020 10:02:36 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-113-127.ams2.redhat.com [10.36.113.127]) by smtp.corp.redhat.com (Postfix) with ESMTPS id F204160855; Thu, 26 Nov 2020 10:02:35 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.16.1/8.16.1) with ESMTPS id 0AQA2Xtv2354800 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Thu, 26 Nov 2020 11:02:33 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.16.1/8.16.1/Submit) id 0AQA2Wwh2354799; Thu, 26 Nov 2020 11:02:32 +0100 Date: Thu, 26 Nov 2020 11:02:32 +0100 From: Jakub Jelinek To: Thomas Schwinge Cc: gcc-patches@gcc.gnu.org, Sandra Loosemore , David Malcolm Subject: Re: Don't create location wrapper nodes within OpenACC clauses (was: [WIP] Fold 'NON_LVALUE_EXPR' some more (was: C++ 'NON_LVALUE_EXPR' in OMP array section handling)) Message-ID: <20201126100232.GW3788@tucnak> Reply-To: Jakub Jelinek References: <874lb9qr2u.fsf@euler.schwinge.homeip.net> <5a782157-d5ab-e9af-9a6a-78d97fc4fb07@codesourcery.com> <87ft4wbgt0.fsf@euler.schwinge.homeip.net> MIME-Version: 1.0 In-Reply-To: <87ft4wbgt0.fsf@euler.schwinge.homeip.net> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-5.9 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, 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, 26 Nov 2020 10:02:43 -0000 On Thu, Nov 26, 2020 at 10:36:43AM +0100, Thomas Schwinge wrote: > So, I understand, 'NON_LVALUE_EXPR's are primarily a C/C++ (only?) front > end construct to wrap nodes that must not be used as a lvalue (per the > programming language standards); rejecting code like 'int x; &(x + 0);', > I suppose. The NON_LVALUE_EXPRs serve two purposes, one is indeed to indicate something is not an lvalue, even when its operand is, and another is holding location info (I think currently only in the C++ FE), so that diagnostics can report correct locations even for e.g. constants or uses of variables. So, it is undesirable to avoid adding those location wrappers, but instead when we want to look at the value of the expression we should be using appropriate APIs (e.g. for_fold_warn, or maybe_constant_value). And generally, cp_fold_function should be also stripping them away from everything. Jakub