RE: [EXTERNAL] Re: move_alloc with coarray argument

["Rouson, Damian" <rouson at sandia dot gov>]

Tobias,

Sorry for the delayed reply.  I alerted Cray and Intel to that their compilers were accepting invalid code involving passing a coarray to move_alloc.  In answer to your question, the Cray Fortran compiler returns the following for the code you sent:

 T
 3*0
Application 75039 is crashing. ATP analysis proceeding...

Stack walkback for Rank 0 starting:
  _start@start.S:113
  __libc_start_main@libc-start.c:226
  main@burnus.f90:6
Stack walkback for Rank 0 done
Process died with signal 8: 'Floating point exception'
Forcing core dump of rank 0
View application merged backtrace tree file with: statview atpMergedBT.dot
You may need to: module load stat

_pmiu_daemon(SIGCHLD): [NID 00029] [c0-0c0s1n3] [Wed Jun  6 05:29:57 2012] PE RANK 0 exit signal Floating point exception
Application 75039 exit codes: 136
Application 75039 resources: utime ~0s, stime ~0s

Interesting that lcobound returns a result but ucobound crashes. Either way, thanks again for your guidance.  I have corrected my code.  

If I'm able to get a result with the Intel compiler, I'll report that as well.

Damian
________________________________________
From: Tobias Burnus [burnus@net-b.de]
Sent: Tuesday, May 29, 2012 11:25 PM
To: Rouson, Damian
Cc: fortran@gcc.gnu.org
Subject: Re: [EXTERNAL] Re: move_alloc with coarray argument

Damian,

Rouson, Damian wrote:
> I'm not sure how to interpret your e-mail. Most of what you wrote supports treating the code I submitted as invalid, but you also wrote, "If one now interprets MOVE_ALLOC as having corank == 0 (as it does not
> mention coarrays), passing coarrays to MOVE_ALLOC is now allowed."  Does that imply that it is valid?

It's a typo: "now" should have been "not".

> If Intel and Cray already support the code as I wrote it, is that a bug (or an extension) or their part?

I believe so. What do you get if you execute the following program with
cray ftn and ifort?

integer, allocatable :: A(:), C(:)[:,:,:]
allocate (A(-3:3))
call move_alloc (A, C)
print *, allocated (C)
print *, lcobound(C)
print *, ucobound(C)
end


> I'm not skilled at reading patches, but it appears yours simply prints a message that the code is disallowed.  If so, can you suggest a workaround?  Should I copy the data from the regular array to the coarray and then deallocate the regular array?  That seems wasteful in terms of memory usage (even if only temporarily so) and it would seem to shift the burden of synchronization from the compiler to the programmer, making it unsafe but no faster (assuming the programmer remembers to synchronize).

Yes, that's what my patch does. Regarding the work around:


a) Allocate the coarray with the correct size from the beginning.

Reasons for not using move_alloc:

* There might be a need to do a reallocation - if the implementation
uses special memory for coarrays. For instance, in gfortran the memory
is allocated in the CAF library; whether it does a normal "malloc" or
something special is beyond the control and knowledge of the compiler
and determined only by the (statically or shared) linked CAF runtime
library.

* The shape (array bound) has to be the same on all images; with
MOVE_ALLOC there is the danger that this won't be the case, with
ALLOCATE the same is possible, but less likely.

* ALLOCATE which shows the that there is a coarray (explicitly showing
"[...]") makes it easier to see that there is an implied SYNC ALL.

As the shape (i.e. the array bounds) has to be the same on all images,
that action requires synchronization and can thus be done directly via
ALLOCATE; I fail to see a case when MOVE_ALLOC would be superior.


b) Use a (scalar) derived-type coarray with allocatable components; in
that case, the allocatable components can be used in move_alloc and can
have different shapes on different images. You still can do
"caf[n,m]%alloc_comp_array" to access the array remotely.


c) Suggest to J3 that they should support move_alloc with coarray
arguments. However, you need to address the first issue (value for the
cobounds) and also give a convincing reason why MOVE_ALLOC is better
than (a) or (b).

Tobias