OpenACC: initialization with unsupported acc_device_t (was: [PR testsuite/65205, libgomp/65993] Fix dg-shouldfail usage in OpenACC libgomp tests)

[Thomas Schwinge]

Hi!

On Tue, 5 May 2015 08:43:48 -0400, John David Anglin <dave.anglin@bell.net> wrote:
> On 2015-05-05 5:43 AM, Thomas Schwinge wrote:
> >> FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/lib-62.c
> >> >-DACC_DEVICE_TYPE_hos
> >> >t=1 -DACC_MEM_SHARED=1 output pattern test, is , should match invalid size
> > With this one I'll need your help: please cite from libgomp.log (or, from
> > a manual run) the actual output message that you're getting.
> There's no output message:
> # ./lib-62.exe
> Segmentation fault (core dumped)

Thanks for having a look!

> (gdb) r
> Starting program: 
> /test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libgomp/testsuite/lib-62.exe
> warning: Private mapping of shared library text was not specified
> by the executable; setting a breakpoint in a shared library which
> is not privately mapped will not work.  See the HP-UX 11i v3 chatr
> manpage for methods to privately map shared library text.
> 
> Program received signal SIGSEGV, Segmentation fault.
> acc_init (d=acc_device_nvidia) at ../../../gcc/libgomp/oacc-init.c:178
> 178       ndevs = base_dev->get_num_devices_func ();
> (gdb) disass $pc-16,$pc+16
> Dump of assembler code from 0xc12731c8 to 0xc12731e8:
>     0xc12731c8 <acc_init+64>:    copy r4,r19
>     0xc12731cc <acc_init+68>:    copy r6,r26
>     0xc12731d0 <acc_init+72>:    b,l 0xc1272af0 <resolve_device>,rp
>     0xc12731d4 <acc_init+76>:    copy r19,r4
> => 0xc12731d8 <acc_init+80>:    ldw 1c(ret0),r22
>     0xc12731dc <acc_init+84>:    copy r4,r19
>     0xc12731e0 <acc_init+88>:    copy ret0,r3
>     0xc12731e4 <acc_init+92>:    copy r19,r4
> End of assembler dump.
> (gdb) p/x $ret0
> $1 = 0x0
> 
> It would seem resolve_device returned 0.

On Tue, 5 May 2015 09:10:06 -0400, John David Anglin <dave.anglin@bell.net> wrote:
> dispatchers[acc_device_nvidia] is zero when resolve_device is called.

As this is a PA-RISC HP-UX system, I feel certain that you don't actually
have nvptx offloading available (so, the nvptx libgomp plugin is not
being built).  However, this test case, contains an unconditional
acc_init call for acc_device_nvidia, and I would then guess that this
situation is not (not anymore?) correctly handled (abort with »offloading
to [...] not possible«, or similar; see
libgomp.oacc-c-c++-common/lib-4.c) in libgomp -- Julian, could this be
due to your recent libgomp OpenACC initialization changes?  (When working
on this in a build that does have nvptx offloading configured, I think
you should be able to simulate the situation by "hiding" (temporarily
deleting, or similar) the nvptx libgomp plugin?)  I think they're using
some of the same code paths, so make sure that when fixing acc_init, you
don't regress acc_get_num_devices, which should then still return 0 when
queried for acc_device_nvidia, and should not abort.


Then, I don't know why libgomp.oacc-c-c++-common/lib-62.c contains this
explicit acc_init call with acc_device_nvidia -- generally, the test
cases should not contain such unconditional statements.  So, let's then
please remove this.  See
libgomp/testsuite/libgomp.oacc-c-c++-common/lib-66.c for a very similar
test case, which does this differently.


Grüße,
 Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20150505/6b97c1ac/attachment.sig>