| Message ID | alpine.LSU.2.20.1505020041410.7255@tuna.site |
|---|---|
| State | New |
| Headers | show |
Hi Gerald, Gerald Pfeifer wrote: > On Sun, 31 Aug 2014, Tobias Burnus wrote: >> I have committed the attached patch. Comment and suggestions are welcome! > I applied the small follow-up below. > > What I am struggling to understand, though, is the following piece: > > Full experimental support of Fortran 2008's coarrays with > <code>-fcoarray=lib</code> except for locking and allocatable/pointer > components of derived-type coarrays. > > Does this mean it is only supported when -fcoarray=lib is provided? > If so, I'd say that more explicitly. No, not quite. Let' me expand a bit: Coarrays permit to run programs in parallel following a distributed memory model. All variables which are coarrays have an additional (array) index designating the (remote) processor index ("image index"). gfortran handles this parallelization by generating calls to a communication library (libcaf_single, libcaf_mpi, libcaf_armci, ...). (The option -fcoarray=single assumes that only a single process exists [boring!] and requires no communication library.) As just written, with -fcoarray=lib, one generates library calls for the communication with remote processes ("images"). However, the implementation is not yet complete. And the biggest omission is the support to access allocatable or pointer components of coarrays. Namely, either to pull data from a remote image/process in the form: lhs = coarray[remote_index]%allocatable_component or to push data to a remote image, e.g. coarray[remote_index]%pointer_component = 5 As that's the main missing feature, I thought it should be listed in the release notes. When accessing data for the local process, it uses the normal code and, hence, it automatically works with -fcoarray=single. Trying to access code from a remote process will give a compile-time error with a sorry-not-yet-implemented error. > And perhaps split off the second half into something like "(Only > locking and... are not provided yet)". Locking is meanwhile supported (except for a corner case). > What is "full experimental support", by the way? Just "experimental"? Well, except for some corner cases – and in particular the the listed one – all features are supported. Thus, there is full support of coarrays as defined in Fortran 2008. But it is only experimental as there are known and unknown bugs. I hope, it is now clearer what was meant by the original wording. Tobias
Index: changes.html =================================================================== RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-5/changes.html,v retrieving revision 1.116 diff -u -r1.116 changes.html --- changes.html 22 Apr 2015 12:43:34 -0000 1.116 +++ changes.html 1 May 2015 22:40:33 -0000 @@ -537,7 +537,7 @@ </pre></li> <li>The <code>-Wuse-without-only</code> option has been added to warn when a - <code>USE</code> statement has no <code>ONLY</code> qualifier and, thus, + <code>USE</code> statement has no <code>ONLY</code> qualifier and thus implicitly imports all public entities of the used module.</li> <li>Formatted READ and WRITE statements now work correctly in locale-aware programs. For more information and potential caveats, see
On Sun, 31 Aug 2014, Tobias Burnus wrote: > I have committed the attached patch. Comment and suggestions are welcome! I applied the small follow-up below. What I am struggling to understand, though, is the following piece: Full experimental support of Fortran 2008's coarrays with <code>-fcoarray=lib</code> except for locking and allocatable/pointer components of derived-type coarrays. Does this mean it is only supported when -fcoarray=lib is provided? If so, I'd say that more explicitly. And perhaps split off the second half into something like "(Only locking and... are not provided yet)". What is "full experimental support", by the way? Just "experimental"? Gerald