Hi Nicolas, > Because they were originally intended for the gfortran test suite, but I > couldn't run it there because of libpthread. I will change the numbering > scheme.
the way that libpthread dependency is currently handled seems weird to me: right now it is only dragged in via -fopenmp, although libgomp isn't otherwise used AFAICS. Is this really supposed to work this way? And what about targets that don't have pthreads? Isn't <gthr.h> supposed to abstract away from the details of the underlying threading library? If async io needs libpthread (or whatever else), the gfortran driver needs to drag that in, maybe under the control of some option, instead of relying on libgomp that happens to use it already. Maybe have a look at what libobjc and libstdc++ (the other consumers of gthr.h) do here. >> ... and asynchronous_9.f90 is missing from the ChangeLog, which >> ..._7.f90 is missing from the sequence. > > asynchronous_7.f90 is a test for an error, but dg-shouldfail is not working > in libgomp. Dominique is looking into this. Weird: it's already being used in many places in libgomp.oacc*. >> Besides, I see >> >> +FAIL: libgomp.fortran/asynchronous_6.f90 -O1 execution test >> >> STOP 2 >> >> 32-bit i386 only. >> > > I have trouble replicating this bug even with -m32. Could you get some more > debugging info for the test on your machine? I'll try. It seems pretty random, though: I've just run another test where only the 32-bit i386 FAIL: libgomp.fortran/asynchronous_6.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test FAILs. Maybe different runs of the test with different options (under make -j<N> testing) tread on each other's toes? >> +FAIL: libgomp.fortran/asynchronous_9.f90 -O execution test >> >> 32 and 64-bit i386 and sparc, no error message. >> > > This file wasn't supposed to be a test case, that's why it is not in the > ChangeLog. It is a benchmark program, so it takes some time. Maybe a time > out? Could you maybe try running it outside the test suite? Sure: when rebuilt with -g3, I get Thread 2 received signal SIGSEGV, Segmentation fault. [Switching to Thread 1 (LWP 1)] MAIN__ () at /vol/gcc/src/hg/trunk/solaris/libgomp/testsuite/libgomp.fortran/asynchronous_9.f90:7 7 call random_number(a) (gdb) where #0 MAIN__ () at /vol/gcc/src/hg/trunk/solaris/libgomp/testsuite/libgomp.fortran/asynchronous_9.f90:7 (gdb) display/i $pc 1: x/i $pc => 0x8051679 <MAIN__+12>: movl $0x0,-0x7270f60(%ebp) (gdb) p/x $ebp $1 = 0xfeffda78 That address (FEFFDA78-7270F60 = F7D8CB18) isn't even mapped: 9698: /var/gcc/gcc-9.0.0-20180604/11.4-gcc/i386-pc-solaris2.11/libgomp/tests Address Kbytes RSS Anon Lock Mode Mapped File 08050000 40 40 - - r-x---- [ text ] asynchronous_9.exe 08069000 8 8 8 - rwx---- [ data ] asynchronous_9.exe 0806B000 8 8 8 - rwx---- [ heap ] FDB90000 352 288 - - r-x---- [ text ] libquadmath.so.0.0.0 FDBF7000 4 4 4 - rwx---- [ data ] libquadmath.so.0.0. Rainer -- ----------------------------------------------------------------------------- Rainer Orth, Center for Biotechnology, Bielefeld University