From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16940 invoked by alias); 15 Oct 2014 15:35:28 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 16929 invoked by uid 89); 15 Oct 2014 15:35:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 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 (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 15 Oct 2014 15:35:27 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9FFZNVA007692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 15 Oct 2014 11:35:23 -0400 Received: from tucnak.zalov.cz (ovpn-116-116.ams2.redhat.com [10.36.116.116]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9FFZL3V018061 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Wed, 15 Oct 2014 11:35:22 -0400 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.14.9/8.14.9) with ESMTP id s9FFZKm6022505; Wed, 15 Oct 2014 17:35:20 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.14.9/8.14.9/Submit) id s9FFZIQ7022494; Wed, 15 Oct 2014 17:35:18 +0200 Date: Wed, 15 Oct 2014 15:39:00 -0000 From: Jakub Jelinek To: Ilya Verbin Cc: gcc-patches@gcc.gnu.org, Bernd Schmidt , Thomas Schwinge , Kirill Yukhin , Andrey Turetskiy Subject: Re: [PATCH 7/n] OpenMP 4.0 offloading infrastructure: testsuite Message-ID: <20141015153518.GS10376@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <20141015145752.GB46277@msticlxl57.ims.intel.com> <20141015150543.GR10376@tucnak.redhat.com> <20141015152837.GC46277@msticlxl57.ims.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141015152837.GC46277@msticlxl57.ims.intel.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2014-10/txt/msg01372.txt.bz2 On Wed, Oct 15, 2014 at 07:28:37PM +0400, Ilya Verbin wrote: > On 15 Oct 17:05, Jakub Jelinek wrote: > > > This patch adds all examples with '#pragma omp target' from [1] to libgomp > > > testsuite. Without an accelerator or emulator, these tests are UNSUPPORTED. > > > > Why? Most of the tests should work just fine with host fallback. > > Yeah, from Examples 4.0.1 I'm aware of some tests which assume that host > > fallback doesn't happen, but they should be in minority. > > So, can you temporarily change check_effective_target_offload_device to > > always return 0 from main, run the testsuite with OMP_DEFAULT_DEVICE=10000 > > in the environment and see what testcases really need > > { dg-require-effective-target offload_device } ? > > Yes, they will work fine with host fallback, however we want to be sure that > tests are running on device (or emulator). If there were some issue with > offloading, and a test actually were running in fallback mode, we would never > know about it. That's why we added dg-require-effective-target to all tests. But we do want to test them with host fallback, which those lines preclude. Just a single dg-require-effective-target offload_device guarded test (which there necessarily is, e.g. the 57.* ones) should be sufficient for your purposes (if you want to diff UNSUPPORTED vs. PASS tests between runs). Right now the result of that test turns all tests in the directory into UNSUPPORTED, with the removals you'd just turn a single one or a dozen or how many would really need it. The fact that the tcl offload_device check succeeded doesn't mean that all tests don't use host fallback anyway. Additionally to a handful of dg-require-effective-target offload_device you could have one which just prints something on stdout depending on if it is offloaded or not, you can grep for the output of that in your libgomp.log. Jakub