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 616EE3857C56 for ; Wed, 14 Sep 2022 12:45:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 616EE3857C56 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=1663159505; h=from:from:reply-to: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=HhxXicE2DEDmnss1w3b6B3wSfQ2FiPSAS9mp/gWFupQ=; b=X3a38kbaeiVdjrTVH/EHBjML/XkJE/thsTH9r6Px6qX6X+z8QFQgM9IQ9Tay3p037goemi c3/Mh9tDrLVvKBJQf9dBZ52+e6veq7vJbNPHNHb+PDLOcjMZX6fb8WPUXAokp772TnJAnA IcudNCvqz/CMCXlP8KbMLX+n25cDZHQ= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-567-07RhdsIrNYClSf9REeSNUA-1; Wed, 14 Sep 2022 08:44:59 -0400 X-MC-Unique: 07RhdsIrNYClSf9REeSNUA-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 2EC2B800B30; Wed, 14 Sep 2022 12:44:59 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.41]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E49F1C15BA8; Wed, 14 Sep 2022 12:44:58 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 28ECitiQ1975934 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 14 Sep 2022 14:44:56 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 28ECitlP1975933; Wed, 14 Sep 2022 14:44:55 +0200 Date: Wed, 14 Sep 2022 14:44:54 +0200 From: Jakub Jelinek To: Julian Brown Cc: gcc-patches@gcc.gnu.org, fortran@gcc.gnu.org, tobias@codesourcery.com, cltang@codesourcery.com Subject: Re: [PATCH v3 05/11] OpenMP: push attaches to end of clause list in "target" regions Message-ID: Reply-To: Jakub Jelinek References: <479bff9d51ee4db1ff46e0edaaf24d2a601f7a0d.1663101299.git.julian@codesourcery.com> MIME-Version: 1.0 In-Reply-To: <479bff9d51ee4db1ff46e0edaaf24d2a601f7a0d.1663101299.git.julian@codesourcery.com> X-Scanned-By: MIMEDefang 3.1 on 10.11.54.8 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.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=unavailable 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 Tue, Sep 13, 2022 at 02:03:15PM -0700, Julian Brown wrote: > This patch moves GOMP_MAP_ATTACH{_ZERO_LENGTH_ARRAY_SECTION} nodes to > the end of the clause list, for offload regions. This ensures that when > we do the attach operation, both the "attachment point" and the target > region have both already been mapped on the target. This avoids a > pathological case that can otherwise happen with struct sibling-list > handling. > > 2022-09-13 Julian Brown > > gcc/ > * gimplify.cc (omp_segregate_mapping_groups): Update comment. > (omp_push_attaches_to_end): New function. > (gimplify_scan_omp_clauses): Use omp_push_attaches_to_end for offloaded > regions. Shouldn't this be done at the end of gimplify_adjust_omp_clauses? I mean, can't further attach clauses appear because of declare mapper for implicitly mapped variables? Other than that, it is yet another walk of the whole clause list, so would be nicer if it could be done in an existing walk over the clauses or at least have a flag whether there are any such clauses present and do it only in that case. If it could be done in the main gimplify_adjust_omp_clauses loop, nice, if it can appear also during splay_tree_foreach (ctx->variables, gimplify_adjust_omp_clauses_1, &data); that isn't the case. Jakub