Hi! On Tue, 5 May 2015 08:43:48 -0400, John David Anglin <dave.ang...@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.ang...@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
pgpd9CKnBQ2uZ.pgp
Description: PGP signature
