[Patch, Fortran] PR25829: Asynchronous I/O (v2)

[Rainer Orth]

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