Re: [Patch, Fortran, Coarray, PR88076, v1] 7/6 Add a shared memory multi process coarray library.

[Andre Vehreschild]

Hi Jerry,

good you could build Toon's code. 

Your idea of using the OpenCoarray tests to test caf_shmem made me think about
how to do it the easiest. 

I came up with the following:

1. Pull a recent OpenCoarray source tree from Github or use a clean existing
one.
2. Apply attached patch.
3. Create a build directory for OpenCoarrays.
4. Copy or link libcaf_shmem.a from a recent gfortran build to the OpenCoarray
build directory.
5. Do a cmake  in the build directory.
6. Now cmake --build . && ctest . should test using caf_shmem.

Notes:
- Some tests have been deactivated, because they use MPI-features, that are not
  present in caf_shmem.
- There are still two test failing about some test on cafrun. Those are ok,
  because the file has been patched and I can't find where the test is coming
  from. Unimportant!
- You need an update patch set for caf_shmem, because the OpenCoarray tests
  revealed some/a lot of issues in caf_shmem. I am currently regtesting the
  patch and will publish as soon as it regtests cleanly.

Regards,
Andre

On Fri, 4 Jul 2025 10:51:43 -0700
Jerry D  wrote:

> On 7/4/25 5:12 AM, Andre Vehreschild wrote:
> > Hi all,
> > 
> > attached patches goes on top of other 6 caf_shmem coarray patches and fixes
> > missing includes esp. on non-Linux systems. I have tested this on a FreeBSD,
> > which is very time consuming due to it being fully virtualized on my system.
> > 
> > Regtests ok on x86_64-pc-linux-gnu and aarch64-unknown-freebsd14.3. Ok for
> > mainline?
> > 
> > Thanks to Steve for bringing these deficiencies to my attention.
> > 
> > Regards,
> > Andre  
> 
> So far,
> 
> $ export GFORTRAN_NUM_IMAGES=9
> $ rm *.mod
> $ gfc -fcoarray=lib random-weather.f90  -lcaf_shmem
> $ ./a.out
> Decomposition information on image   6 : there are   9 *   1 slabs; the slabs 
> are   8 *  70 grid cells in size.
> Decomposition information on image   1 : there are   9 *   1 slabs; the slabs 
> are   8 *  70 grid cells in size.
> Decomposition information on image   4 : there are   9 *   1 slabs; the slabs 
> are   8 *  70 grid cells in size.
> Decomposition information on image   5 : there are   9 *   1 slabs; the slabs 
> are   8 *  70 grid cells in size.
> Decomposition information on image   9 : there are   9 *   1 slabs; the slabs 
> are   8 *  70 grid cells in size.
> Decomposition information on image   3 : there are   9 *   1 slabs; the slabs 
> are   8 *  70 grid cells in size.
> Decomposition information on image   8 : there are   9 *   1 slabs; the slabs 
> are   8 *  70 grid cells in size.
> Decomposition information on image   2 : there are   9 *   1 slabs; the slabs 
> are   8 *  70 grid cells in size.
> Decomposition information on image   7 : there are   9 *   1 slabs; the slabs 
> are   8 *  70 grid cells in size.
> .
> .
> .
>   Time3600  Image   4  PS=   99925.0391  T=301.282928 
>U=   -51.2542686  V=24.3605309  W=  -0.296301365  Q= 
> 1.48258626E-03
>   Time3600  Image   9  PS=   99899.3047  T=299.897095 
>U=62.8683090  V=   -57.9342270  W=   0.445489585  Q= 
> 1.90666097E-03
>   Time3600  Image   1  PS=   99966.7656  T=300.011597 
>U=   -1.93229961  V=   -118.892410  W=   -6.45965934E-02  Q= 
> 2.03774264E-03
>   Time3600  Image   7  PS=   100015.938  T=300.066162 
>U=   -17.6038494  V=  -0.982973158  W=7.21789524E-02  Q= 
> 2.17592530E-03
>   Time3600  Image   2  PS=   13.477  T=300.078522 
>U=   -2.38964367  V=   -18.8026981  W=  -0.179861650  Q= 
> 1.99834118E-03
>   Time3600  Image   5  PS=   100077.422  T=300.781494 
>U=   -16.6273994  V=   -101.607895  W=   0.361649722  Q= 
> 1.7433E-03
>   Time3600  Image   3  PS=   12.391  T=299.708862 
>U=18.6304798  V=   0.391739845  W=2.24014949E-02  Q= 
> 1.96914421E-03
>   Time3600  Image   8  PS=   100074.359  T=299.516235 
>U=   -55.1445618  V=68.3090286  W=  -0.537869334  Q= 
> 2.32057413E-03
>   Time3600  Image   6  PS=   99976.4453  T=300.221924 
>U=   -1.62557888  V=1.44226456  W=   0.201509774  Q= 
> 1.97460176E-03
> $
> 
> 
> real  0m0.066s
> user  0m0.337s
> sys   0m0.107s
> 
> Definitely much faster than mpich.  I also over prescribed the number of
> images to 30 and ran as well.
> 
> I still need to build OpenCoarrays using this gfortran-16 and make sure it 
> succeeds those tests with mpich.  I will try to then test each case on the 
> OpenCoarrays suite of tests with -lcaf_shmem and see if those all work.
> 
> Any ideas on how to stress test this. I only have 32 gig of memory here and 
> would like to see how a longer running program does.
> 
> Regards,
> 
> Jerry


-- 
Andre Vehreschild * Email: vehre ad gmx dot de 
From fad13

Re: [Fortran, Patch, PR120711, v1] 1/(3) Fix out of bounds access in cleanup of array constructor

[Mikael Morin]

Le 09/07/2025 à 08:50, Andre Vehreschild a écrit :

HI Harald, hi Mikael,

why shall the testcase be invalid? The `list` is empty. Concatenating with it
is valid in Fortran like in most other programming languages. The mapping of an
empty list in gfortran is to have the array's data pointer set to NULL and the
ubound below the lbound. Current gfortran copes fine with this, so does Intel's
Fortran compiler and flang (all executables tested with valgrind).

The intent of the program is clear for a human, but for a compiler, the 
language makes them distinct: unallocated is not the same as empty.



In F2018 §7.8 Paragraph 8 it states: "An empty sequence forms a zero-sized
array", This is the closest it gets to an unallocated array, but it does not
exclude nor include it.


There is 9.2 and 9.3:
  The appearance of a data object designator in a context that requires
its value is termed a reference.
  A reference is permitted only if the variable is defined.

and 19.6.3 and 19.6.4:
  The following variables are initially defined:
   (...) (6 items where allocatable variables don't appear)
  Variables that are not initially defined are initially undefined.


Maybe someone with access to other fortran compilers can test this, too. But I
see all compilers available to me be fine with an unallocated array in the
array constructor. But I am doing to much wrong at the moment, so don't value
my words too much.

There are some language design aspects that I find strange or confusing 
myself when I encounter them from time to time, but we have to leave 
with them.

Re: [Fortran, Patch, PR120711, v1] 1/(3) Fix out of bounds access in cleanup of array constructor

[Steve Kargl]

On Wed, Jul 09, 2025 at 08:50:08AM +0200, Andre Vehreschild wrote:
> 
> why shall the testcase be invalid?

See the 2nd bullet in Fortran 2023, 9.7.1.3 Allocation
of allocatable variables.

An allocatable variable has a status of "unallocated"
if it is not allocated.
...
An allocatable variable with this status shall not be
referenced or defined.

in 'list = [list, 'abc']' the right-hand reference makes the
code invalid if list is unallocated.

-- 
steve