https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126777

--- Comment #11 from Steve Kargl <kargl at gcc dot gnu.org> ---
(In reply to Dan Bonachea from comment #10)
> (In reply to Steve Kargl from comment #9)
> > (In reply to Dan Bonachea from comment #8)
> > > FWIW I don't think we care at all about -fcoarray=single, which doesn't
> > > correspond to anything standardized.
> >
> > Yes, it does.  It corresponds to a coarray application with exactly 1 image.
> 
> Yes, I understand the intended semantics, and even the engineering rationale
> for providing it in the past.
> 
> My point was the Fortran standard leaves the details of specifying the
> number of images entirely processor-dependent. There is no normative
> requirement of the form "the processor must have a compilation mode
> corresponding a single image", that's entirely a compiler-specific
> fabrication. As such, GFortran could potentially decide to entirely drop the
> -fcoarray=single option without causing a standard conformance problem. And
> if such a decision would ease maintenance burden and simplify the backends
> providing real multi-image execution, that should perhaps be considered.

Unfortunately, it cannot go away due to backwards compatibility.
We have no idea if some user(s) have a hardcoded -fcoarray=single
in their Makefile, shell script, etc.

I personally think that 'none' should be a no-op, and 'single'
should be the default.  If a user has standard conforming Fortran,
a command line option should not be necessary to compile the code.

% gfcx -o z pi.f90 
pi.f90:10:38:

   10 |     real(dp), allocatable :: partial[:]
      |                                      1
Fatal Error: Coarrays disabled at (1), use '-fcoarray=' to enable
compilation terminated.

% gfcx -o z pi.f90 -fcoarray=single
% ./z
pi =    3.141592653590426
images = 1
intervals = 100000000
% gfcx -o z pi.f90 -fcoarray=shared
% ./z
Fortran runtime error: After restarting images 4001 times, no common state on
shared memory could be reached. Giving up...

(Whoops caf_shmem library seems to have an issue on FreeBSD.  Let's
try to run 'z' again.)

% ./z
pi =    3.141592653589883
images = 16
intervals = 100000000

I submitted a patch a long time ago to implement the change.
Don't remember if it got reject, if it got reviewed, or I just
lost interest.

Reply via email to