From patchwork Sun Mar 13 19:10:08 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Thomas Schwinge X-Patchwork-Id: 596802 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org 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 3qNVpG0WT1z9sdt for ; Mon, 14 Mar 2016 06:10:45 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b=lBmGwEXh; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:cc:subject:in-reply-to:references:date:message-id :mime-version:content-type; q=dns; s=default; b=c/AUVrOcTpJQsvhb VRSA9LYqV7DPbB5rjDVH90po7NHck/ZLMlv7KjnMqWm1nI2H+MfHvyEvnyeypkEu q6no3w8vYNeH0G7BbW0Gl8Zbmp+BPqrNIGoJeliyaBPC7284MZF6cKSaKjmFiZl5 KraIyG59IT1B/+wUdoI2QPwBfpg= 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:from :to:cc:subject:in-reply-to:references:date:message-id :mime-version:content-type; s=default; bh=T8bjbetkUJM+39xgCAyloQ MF5yw=; b=lBmGwEXhOg1LLklcubgci5FMsGv2f9Je8n0Mu+6UMeneAeTpx6qgLg pGo4Lc0nzX9v9S+EIobo0tUmn/lxmVqlOpUNrrH+uxiD/Ht7kRkRVMHYLiI6IEYd pBu4igkmNV+8zCuzr4b/MyIF+qbyHh54dwobvbA+9Ic3p4l9w+Gfc= Received: (qmail 39886 invoked by alias); 13 Mar 2016 19:10:37 -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 39000 invoked by uid 89); 13 Mar 2016 19:10:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_NONE, SPF_PASS autolearn=ham version=3.3.2 spammy=Suddenly, upgrades, H*r:0700, H*r:PDT X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Sun, 13 Mar 2016 19:10:22 +0000 Received: from svr-orw-fem-05.mgc.mentorg.com ([147.34.97.43]) by relay1.mentorg.com with esmtp id 1afBP9-0006op-43 from Thomas_Schwinge@mentor.com ; Sun, 13 Mar 2016 12:10:19 -0700 Received: from tftp-cs (147.34.91.1) by svr-orw-fem-05.mgc.mentorg.com (147.34.97.43) with Microsoft SMTP Server id 14.3.224.2; Sun, 13 Mar 2016 12:10:18 -0700 Received: by tftp-cs (Postfix, from userid 49978) id 50167C230F; Sun, 13 Mar 2016 12:10:18 -0700 (PDT) From: Thomas Schwinge To: Ilya Verbin , Jakub Jelinek , CC: Kirill Yukhin Subject: Re: [PATCH 4/4] OpenMP 4.0 offloading to Intel MIC: non-fallback testing In-Reply-To: <20141030114001.GA34120@msticlxl57.ims.intel.com> References: <20141021171323.GA47586@msticlxl57.ims.intel.com> <20141030114001.GA34120@msticlxl57.ims.intel.com> User-Agent: Notmuch/0.9-125-g4686d11 (http://notmuchmail.org) Emacs/24.5.1 (i586-pc-linux-gnu) Date: Sun, 13 Mar 2016 20:10:08 +0100 Message-ID: <87io0qurcf.fsf@kepler.schwinge.homeip.net> MIME-Version: 1.0 Hi! On Thu, 30 Oct 2014 14:40:01 +0300, Ilya Verbin wrote: > This patch allows to run non-fallback 'make check-target-libgomp'. It passes to > the host compiler additional -B options with the paths to the offload compilers, > since non-installed host compiler doesn't know where to find mkoffload tools. > Also in case of intelmic offload targets it appends paths to liboffloadmic lib. > --- a/libgomp/testsuite/lib/libgomp.exp > +++ b/libgomp/testsuite/lib/libgomp.exp > @@ -107,6 +110,20 @@ proc libgomp_init { args } { > # Compute what needs to be put into LD_LIBRARY_PATH > set always_ld_library_path ".:${blddir}/.libs" > > + # Add liboffloadmic build directory in LD_LIBRARY_PATH to support > + # non-fallback testing for Intel MIC targets > + if { [string match "*-intelmic-*" $offload_targets] > + || [string match "*-intelmicemul-*" $offload_targets] } { > + append always_ld_library_path ":${blddir}/../liboffloadmic/.libs" > + append always_ld_library_path ":${blddir}/../liboffloadmic/plugin/.libs" > + # libstdc++ is required by liboffloadmic > + append always_ld_library_path ":${blddir}/../libstdc++-v3/src/.libs" > + } > + > + if { $offload_additional_lib_paths != ""} { > + append always_ld_library_path "${offload_additional_lib_paths}" > + } Hmm, looking at this again. Suddenly/unexpectedly (after a long-overdue system reboot, software upgrades, etc.), the libgomp.oacc-c/../libgomp.oacc-c-c++-common/context-1.c execution test (on gomp-4_0-branch) regressed from PASS to FAIL, with the very first cublasCreate call not returning the exptected CUBLAS_STATUS_SUCCESS. While I could never figure out what exactly is going wrong in/with libcublas, I did figure out that the problem comes to existence in GCC configurations with Intel MIC offloading enabled, where the above stanza is active. Remember that offload_additional_lib_paths specifies paths to the Intel MIC offloading libraries' builds (x86_64-intelmicemul-linux-gnu), and these are prepended by paths to satisfy liboffloadmic's dependencies: libstdc++ (x86_64-pc-linux-gnu). But: libstdc++ depends on libgcc_s, whose path is not specified here, but a path to libgcc_s is specified with offload_additional_lib_paths, but that's the variant for Intel MIC offloading (x86_64-intelmicemul-linux-gnu), not the regular target library (x86_64-pc-linux-gnu). And, for some reason this caused breakage in/with libcublas. All in all, this whole setup still seems fragile to me (I wondered/worried about this before): as the x86_64-pc-linux-gnu (target) and x86_64-intelmicemul-linux-gnu (Intel MIC offloading) libraries are ABI compatible, ld.so is free to intermix these... For certain libraries it may not matter, but certainly the libgomp builds for x86_64-pc-linux-gnu vs. x86_64-intelmicemul-linux-gnu will have different semantics for certain functions, for example. In r234170, I applied the following fix as obvious, but this may still need further attention; compare the stanza cited above to the potentially more compilated dependencies of libstdc++. See libgomp/testsuite/libgomp.c++/c++.exp, and libstdc++-v3/testsuite/lib/libstdc++.exp:libstdc++_init mentions that in certain configurations, also libvtv may be a dependency of libstdc++, for example. Also, is the stanza cited above doing the right thing for GCC multilib configurations? commit 16603d6b5b9073537c00b706b854f0a87101b991 Author: tschwinge Date: Sun Mar 13 19:08:21 2016 +0000 libgcc_s is required by libstdc++ libgomp/ * testsuite/lib/libgomp.exp (libgomp_init): Potentially append to always_ld_library_path the path to libgcc_s. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@234170 138bc75d-0d04-0410-961f-82ee72b054a4 --- libgomp/ChangeLog | 5 +++++ libgomp/testsuite/lib/libgomp.exp | 2 ++ 2 files changed, 7 insertions(+) Grüße Thomas diff --git libgomp/ChangeLog libgomp/ChangeLog index 7293e69..5a91504 100644 --- libgomp/ChangeLog +++ libgomp/ChangeLog @@ -1,3 +1,8 @@ +2016-03-13 Thomas Schwinge + + * testsuite/lib/libgomp.exp (libgomp_init): Potentially append to + always_ld_library_path the path to libgcc_s. + 2016-03-10 Cesar Philippidis PR testsuite/70009 diff --git libgomp/testsuite/lib/libgomp.exp libgomp/testsuite/lib/libgomp.exp index 0d5b6d4..1cb4991 100644 --- libgomp/testsuite/lib/libgomp.exp +++ libgomp/testsuite/lib/libgomp.exp @@ -142,6 +142,8 @@ proc libgomp_init { args } { append always_ld_library_path ":${blddir}/../liboffloadmic/plugin/.libs" # libstdc++ is required by liboffloadmic append always_ld_library_path ":${blddir}/../libstdc++-v3/src/.libs" + # libgcc_s is required by libstdc++ + append always_ld_library_path ":${blddir}/../libgcc" } global offload_additional_lib_paths