https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126777
Steve Kargl <kargl at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kargl at gcc dot gnu.org
--- Comment #9 from Steve Kargl <kargl at gcc dot gnu.org> ---
(In reply to Dan Bonachea from comment #8)
> > I am finding a lot of missing pieces in the team arguments and proper
> > handling with -fcoarray=single.
>
> Fair enough.
>
> 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. -fcoarray=single allowed gfortran contributors to add coarray
features to gfortran without having to worry about implementation
details, which the Fortran standard does not specified.
Sometimes revisiting history is informative.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18918
> From my perspective the questionable
> use case of running a code with coarrays in a degenerate single-image
> configuration has been entirely subsumed now that Gfortran ships
> libcaf_shmem, so -fcoarray=lib "just works" and the single-image job layout
> is just a special case.
>
> Doesn't seem worth the effort to continue maintaining -fcoarray=single as a
> separate configuration with subtly different semantics, but that's just my
> 2c.
Well, yes, now that shared memory support has materialized, the
usefulness of -fcoarray=single may have diminished. However, 16
years ago, it was quite useful in getting any coarray feature added
to gfortran.
Not to mention, if your coarray application gives different results
when compiled with 'single', 'lib', or 'shared', it suggests that
one may have a race condition lurking.
