From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-74.mimecast.com (us-smtp-delivery-74.mimecast.com [170.10.129.74]) by sourceware.org (Postfix) with ESMTPS id E154A3857432 for ; Thu, 5 May 2022 12:40:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E154A3857432 Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-457-tg5R_nVVPMSxlhBzzr4UoQ-1; Thu, 05 May 2022 08:40:42 -0400 X-MC-Unique: tg5R_nVVPMSxlhBzzr4UoQ-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 56A4B299E745; Thu, 5 May 2022 12:40:42 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.16]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 1813D111D78A; Thu, 5 May 2022 12:40:41 +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 245CediX1708368 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Thu, 5 May 2022 14:40:39 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.16.1/8.16.1/Submit) id 245CecmG1708367; Thu, 5 May 2022 14:40:38 +0200 Date: Thu, 5 May 2022 14:40:38 +0200 From: Jakub Jelinek To: Julian Brown Cc: gcc-patches Subject: Re: [PATCH, OpenMP, C/C++] Handle array reference base-pointers in array sections Message-ID: Reply-To: Jakub Jelinek References: <65e1462e-d17f-2975-1401-358fe9c69e28@codesourcery.com> <20220505124629.10ff0d33@squid.athome> MIME-Version: 1.0 In-Reply-To: <20220505124629.10ff0d33@squid.athome> X-Scanned-By: MIMEDefang 2.78 on 10.11.54.3 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=-4.6 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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, 05 May 2022 12:40:45 -0000 On Thu, May 05, 2022 at 12:46:29PM +0100, Julian Brown wrote: > All the above (at least) has been done as part of the patch series > posted here: > > https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591973.html Ah, ok, so is this patch superseded by that series, or do you want to apply it just to be removed again? > > At least for the C FE maybe we'll > > need to arrange for less folding to be done because C still folds too > > much stuff prematurely. Then when finishing clauses verify that > > OMP_ARRAY_SECTION trees appear only where we allow them and not > > elsewhere (say foo (1, 2, 3)[:36] > > would be ok if foo returns a pointer, but > > foo (ptr[0:13], 2, 3) > > would not) and then need to differentiate between the cases listed in > > the standard which we handle for each . -> [idx] when starting from a > > var (in such a case I vaguely recall there are rules for pointer > > attachments etc.) or other arbitrary expressions (in that case we > > just evaluate those expressions and e.g. in the foo (1, 2, 3)[:36] > > case basically do tmp = foo (1, 2, 3); > > and mapping of tmp[:36]. > > ...which also changes/refactors quite a lot regarding how lowering > clauses into mapping nodes works (the "address inspector" bits). > "Weird" cases like mapping the return value from functions doesn't > necessarily DTRT yet -- it wasn't entirely clear how that should/could > work, I don't think. I vaguely remember that the ./-/[] handling applies only when it starts from a variable and as soon as one triggers something else, perhaps including just *& or similar stuff then only the final lvalue is mapped and nothing else, but dunno if it is from just discussions about the topic or what is actually written in the spec, will need to look it up. Jakub