public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Ilya Verbin <iverbin@gmail.com>
Cc: gcc-patches@gcc.gnu.org, Bernd Schmidt <bernds@codesourcery.com>,
	       Thomas Schwinge <thomas@codesourcery.com>,
	       Kirill Yukhin <kirill.yukhin@gmail.com>,
	       Andrey Turetskiy <andrey.turetskiy@gmail.com>
Subject: Re: [PATCH 7/n] OpenMP 4.0 offloading infrastructure: testsuite
Date: Wed, 15 Oct 2014 15:39:00 -0000	[thread overview]
Message-ID: <20141015153518.GS10376@tucnak.redhat.com> (raw)
In-Reply-To: <20141015152837.GC46277@msticlxl57.ims.intel.com>

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

  reply	other threads:[~2014-10-15 15:35 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-15 15:06 Ilya Verbin
2014-10-15 15:07 ` Jakub Jelinek
2014-10-15 15:35   ` Ilya Verbin
2014-10-15 15:39     ` Jakub Jelinek [this message]
2014-10-17 14:08       ` Ilya Verbin
2014-10-17 14:16         ` Jakub Jelinek
2014-10-17 15:11           ` Ilya Verbin
2014-10-17 15:17             ` Jakub Jelinek
2014-10-17 15:18               ` Ilya Verbin
2014-10-17 15:29                 ` Jakub Jelinek
2014-10-17 15:34                   ` Ilya Verbin
2014-10-17 15:41                     ` Jakub Jelinek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20141015153518.GS10376@tucnak.redhat.com \
    --to=jakub@redhat.com \
    --cc=andrey.turetskiy@gmail.com \
    --cc=bernds@codesourcery.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=iverbin@gmail.com \
    --cc=kirill.yukhin@gmail.com \
    --cc=thomas@codesourcery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).