From patchwork Wed Oct 9 07:37:33 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 1173662 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=gcc.gnu.org (client-ip=209.132.180.131; helo=sourceware.org; envelope-from=gcc-patches-return-510514-incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="VA0RQmjP"; dkim-atps=neutral Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 46p5fQ6bSRz9sDQ for ; Wed, 9 Oct 2019 18:37:48 +1100 (AEDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:subject:message-id:reply-to:mime-version:content-type; q=dns; s=default; b=NF3903AJn6kSWLB3WT4mE1BszQ+kYo0fsNssLdDPyoV 6HoW4KabqucGte3rYyrWsNnCMZK3rwf3NaYrPLBFZJYHuW/HlUPGm6IbU9MWx8lf vgHYDb7mrfgT2n/RhuTmwqrRt4sT88ggemoyAu5dU40P2UokeZfh38uaYw1n3vV4 = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:subject:message-id:reply-to:mime-version:content-type; s=default; bh=0CsiAm4lDLZPkVFPvRxYrvAJvAQ=; b=VA0RQmjP/tpS5knMO yaxj/CHtmoSjmkT80WMhBIQm0A+fWzF9L8eeBUbLUlGXEs2hV8zTxaQsQiJrRC4z VdIXT1ZnQQqA3J3fjFbIQZy+77M2oXeHS1pFbIqtcNSq1Rt+2ZAbsxEhz2Ey0QEK Xsy8SErSZcqSluPcfdRQyLPbjs= Received: (qmail 67708 invoked by alias); 9 Oct 2019 07:37:40 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 67700 invoked by uid 89); 9 Oct 2019 07:37:40 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-7.6 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_2, GIT_PATCH_3, SPF_HELO_PASS autolearn=ham version=3.3.1 spammy= X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 09 Oct 2019 07:37:39 +0000 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 mx1.redhat.com (Postfix) with ESMTPS id EEC936B for ; Wed, 9 Oct 2019 07:37:37 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-116-90.ams2.redhat.com [10.36.116.90]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 98DBA60A9F for ; Wed, 9 Oct 2019 07:37:37 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id x997bZri025962 for ; Wed, 9 Oct 2019 09:37:35 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id x997bXTx025961 for gcc-patches@gcc.gnu.org; Wed, 9 Oct 2019 09:37:33 +0200 Date: Wed, 9 Oct 2019 09:37:33 +0200 From: Jakub Jelinek To: gcc-patches@gcc.gnu.org Subject: [committed] Fix libgomp use_device_* handling (PR libgomp/92028) Message-ID: <20191009073733.GY15914@tucnak> Reply-To: Jakub Jelinek MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.11.3 (2019-02-01) X-IsSubscribed: yes Hi! The following is what I've intended to do but actually ended up committing a weird if (!not_found_cnt) { } else ... The code used to be at the indentation level of if, so my suspicion is that I've marked the block in an editor and tried to move that block into the body, but as it was inside of the block it just removed it instead and I haven't noticed. Anyway, the comment which Thomas requested in the PR should hopefully explain why this needs to be done. Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk. 2019-10-09 Jakub Jelinek PR libgomp/92028 * target.c (gomp_map_vars_internal): Readd the previous GOMP_MAP_USE_DEVICE_PTR handling code in the first loop, though do that just in the !not_found_cnt case. Jakub --- libgomp/target.c.jj 2019-10-07 13:09:07.038253353 +0200 +++ libgomp/target.c 2019-10-08 15:19:16.249439849 +0200 @@ -593,6 +593,30 @@ gomp_map_vars_internal (struct gomp_devi tgt->list[i].key = NULL; if (!not_found_cnt) { + /* In OpenMP < 5.0 and OpenACC the mapping has to be done + on a separate construct prior to using use_device_{addr,ptr}. + In OpenMP 5.0, map directives need to be ordered by the + middle-end before the use_device_* clauses. If + !not_found_cnt, all mappings requested (if any) are already + mapped, so use_device_{addr,ptr} can be resolved right away. + Otherwise, if not_found_cnt, gomp_map_lookup might fail + now but would succeed after performing the mappings in the + following loop. We can't defer this always to the second + loop, because it is not even invoked when !not_found_cnt + after the first loop. */ + cur_node.host_start = (uintptr_t) hostaddrs[i]; + cur_node.host_end = cur_node.host_start; + splay_tree_key n = gomp_map_lookup (mem_map, &cur_node); + if (n == NULL) + { + gomp_mutex_unlock (&devicep->lock); + gomp_fatal ("use_device_ptr pointer wasn't mapped"); + } + cur_node.host_start -= n->host_start; + hostaddrs[i] + = (void *) (n->tgt->tgt_start + n->tgt_offset + + cur_node.host_start); + tgt->list[i].offset = ~(uintptr_t) 0; } else tgt->list[i].offset = 0;