Re: [gomp4] libgomp.c/target-1.c failing in fn2's GOMP_target_update

[Thomas Schwinge <thomas at codesourcery dot com>]

Hi!

On Fri, 8 Nov 2013 16:40:00 +0100, Jakub Jelinek <jakub@redhat.com> wrote:
> On Fri, Nov 08, 2013 at 04:29:03PM +0100, Thomas Schwinge wrote:
> > 
> > On the gomp-4_0-branch, when using the ID 257 device (host fallback but
> > with non-shared memory), I see the libgomp.c/target-1.c test fail in
> > fn2's GOMP_target_update call:
> > 
> >     libgomp: Trying to update [0x601a80..0x601a84) object that is not mapped
> > 
> > Is this a known issue?  (I have not yet started debugging that, and
> > figured someone more familiar with the code may perhaps easily be able to
> > tell what's going wrong.)
> 
> That is expected, device 257 is just a temporary testing hack, which doesn't support
> variables with "omp declare target" attribute.
> So, you can only use it for testcases that don't have any #pragma omp
> declare target variables, or if they do, they only access them in #pragma
> omp declare target functions, but never try to use them or anything related
> to them in map/to/from clauses.
> The plan is that using the two proposed tables (host table of host_addr, size
> pairs and corresponding target table of target_addr) during initialization
> of offloading for a particular shared library resp. binary libgomp will
> register all those ranges in the mapping table.

> [...], once we have at least one supported offloading target,
> hopefully we'll nuke device 257.

Hmm, in contrast, I'd advocate to preserve that device, under a proper
ID, for two (similar) reasons: even if it's the same architecture, we'll
still want a generic non-shared-memory "offloading target" for GCC
testsuite usage.  We can't assume that any of the "real hardware"
acceleration devices to be available, but will still want to test the
non-shared-memory stuff.  And likewise, GCC users can use this for
testing their code for shared-memory host (fallback) execution vs.
non-shared-memory execution.  So basically, just like a user can decide
to use OpenMP/libgomp, but tie the runtime down to just one thread; but
that's still different from host fallback execution.  Makes sense?


GrÃÃe,
 Thomas

Attachment: pgpQ5rfoQZUol.pgp
Description: PGP signature