Re: [Patch, Fortran, Coarray, PR88076, v1] 7/6 Add a shared memory multi process coarray library.
On 7/4/25 19:51, 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. . . . Time 3600 Image 4 PS= 99925.0391 T= 301.282928 U= -51.2542686 V= 24.3605309 W= -0.296301365 Q= 1.48258626E-03 Time 3600 Image 9 PS= 99899.3047 T= 299.897095 U= 62.8683090 V= -57.9342270 W= 0.445489585 Q= 1.90666097E-03 Time 3600 Image 1 PS= 99966.7656 T= 300.011597 U= -1.93229961 V= -118.892410 W= -6.45965934E-02 Q= 2.03774264E-03 Time 3600 Image 7 PS= 100015.938 T= 300.066162 U= -17.6038494 V= -0.982973158 W= 7.21789524E-02 Q= 2.17592530E-03 Time 3600 Image 2 PS= 13.477 T= 300.078522 U= -2.38964367 V= -18.8026981 W= -0.179861650 Q= 1.99834118E-03 Time 3600 Image 5 PS= 100077.422 T= 300.781494 U= -16.6273994 V= -101.607895 W= 0.361649722 Q= 1.7433E-03 Time 3600 Image 3 PS= 12.391 T= 299.708862 U= 18.6304798 V= 0.391739845 W= 2.24014949E-02 Q= 1.96914421E-03 Time 3600 Image 8 PS= 100074.359 T= 299.516235 U= -55.1445618 V= 68.3090286 W= -0.537869334 Q= 2.32057413E-03 Time 3600 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. echo ' &config nxglobal=1000, nyglobal=1000, nzglobal=100 / ' | time mpirun -np 16 --mca btl self,vader ./a.out works on my 128 Gbyte system using the libcoarray+openmpi combination, but it surely doesn't need all that memory. During the weekend I'll try to come up with a "randomization" scheme that gives guaranteed results independent on slight differences in timing (the current use of "call random_number" surely won't do that) - so that runs using different libraries will at least give the same results if the implementations are correct. Kind regards, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Re: [PATCH] Fortran: fix minor issues with coarrays (extended)
Andre, either your patch to coarray.cc is wrong, or the comment in the code is not concise, or I am too dense to understand the intent of the change: diff --git a/gcc/fortran/coarray.cc b/gcc/fortran/coarray.cc index ef8fd4e42d0..01aac581a74 100644 --- a/gcc/fortran/coarray.cc +++ b/gcc/fortran/coarray.cc @@ -700,7 +700,7 @@ check_add_new_component (gfc_symbol *type, gfc_expr *e, gfc_symbol *add_data) && !e->symtree->n.sym->attr.elemental && !(e->value.function.isym && (e->value.function.isym->pure - || e->value.function.isym->elemental))) + && e->value.function.isym->elemental))) /* Treat non-pure/non-elemental functions. */ check_add_new_comp_handle_array (e, type, add_data); else Can you please elaborate? I understood the code comment in the way that any pure or elemental intrinsic should be handled in the else branch. Or do you have an example which is different? The change to trans-decl.cc (fix of decl) looks fine for me. Harald m 04.07.25 um 13:43 schrieb Andre Vehreschild: Hi all, attached patch narrows the use of intrinsic functions in the caf accessor down to pure elemental functions. This is needed because functions that get extracted into the caf accessor routine, have no access to the source image's memory. E.g. team_number() is marked as pure, but takes a pointer argument to an object in the source image's memory, which is not available on the remote image where the accessor is executed. This patch fixes that and also corrects the type in the decl of the ABI of team_number. It is of the opaque type team_type aka void* now and not integer as formerly declared. Regtest ok on x86_64-pc-linux-gnu / F41. Ok for mainline? Regards, Andre On Tue, 1 Jul 2025 12:54:49 -0700 Jerry D wrote: On 7/1/25 12:51 PM, Harald Anlauf wrote: Dear all, the attached patch fixes the following minor issues found by running f951 under valgrind for the just added new testcases coindexed_6.f90 and coindexed_7.f90: - minor front-end memleaks with non-freed strings and lost GMP variables (these are simple and obvious fixes) - an inconsistency between pure/elemental functions being either non-intrinsic or intrinsic. Checking for the latter was likely missed from the beginning. No new testcase. Regtested on x86_64-pc-linux-gnu. OK for mainline? Thanks, Harald Yes, OK, straight-forward. Thanks, Jerry
Re: [Fortran, Patch, PR120843, v3] Fix reject valid, because of inconformable coranks
Hi Jerry, that is very odd, because the test timeout in Opencoarrays is set to 300 seconds at the max. (There are even smaller ones). I can reproduce the Opencoarray tests hanging for cmake build-type Release. On a Debug build they fail. I just repeated testing against OpenCoarrays. The gcc-15 branch w/ and w/o the "fixer patch" passes for me for opencoarray's main branch at 3d0fa68dc95f05f9c17bd3e7dd0d34e6f530e429 with the system supplied mpich in version 4.2.2-1.fc41 (I am on Fedora 41). For gcc-16 I needed to fix OpenCoarrays and gcc a bit (s. https://gcc.gnu.org/pipermail/fortran/2025-July/062451.html). Furthermore is there still the teams support open. I therefore ask you to use this branch: https://github.com/sourceryinstitute/OpenCoarrays/tree/vehre/issue-779-form-team It adds all the necessary stuff for teams and gcc-16 interface awareness. With this I can compile Toon's random_weather code and run it. Regards, Andre On Wed, 2 Jul 2025 16:12:57 -0700 Jerry D wrote: > On 7/2/25 9:40 AM, Jerry D wrote: > > On 7/2/25 3:14 AM, Andre Vehreschild wrote: > >> Hi all, > >> > >> I successfully created a big mess with the previous patch. First of all by > >> applying an outdated one and secondly by adding the conformance checks for > >> coranks in a3f1cdd8ed46f9816b31ab162ae4dac547d34ebc. Checking the standard > >> even using AI (haha) to figure if coranks of an expression have > >> restrictions on them, failed. I found nothing. AI fantasized about > >> restrictions that did not exist. Therefore the current approach is to > >> remove the conformance check and just use the computed coranks in > >> expressions to prevent recomputaion whenever they needed. > >> > >> Jerry, Harald: Sorry for all the bother and all my mistakes. I am really > >> sorry to have wasted your time. > >> > >> The patch has been regtested fine on x86_64-pc-linux-gnu / F41. Ok for > >> mainline and later backport to gcc-15? > >> > >> Regards, > >> Andre > >> > > --- snip --- > > > > With this fixer patch, I can successfully compile Toon's test case. > > > > The patch also regression tests here OK. > > > > OK to push. > > > > Jerry > > As a followup, with the fixer patch applied, OpenCoarrays builds. However, > make test hangs at Test 4. > > 3/88 Test #3: register_vector ... > Passed0.42 sec >Start 4: register_alloc_vector > ^Cmake[3]: *** [CMakeFiles/check.dir/build.make:70: CMakeFiles/check] > Interrupt make[2]: *** [CMakeFiles/Makefile2:962: CMakeFiles/check.dir/all] > Interrupt make[1]: *** [CMakeFiles/Makefile2:969: CMakeFiles/check.dir/rule] > Interrupt make: *** [Makefile:205: check] Interrupt > > I waited about 20 minutes. This may be another bug. I built and tested > OpenCorrays about 2 days ago with gfortran 14 with no problems. > > I am able to compile and run Toon's test case with this OpenCoarrays. So we > still have some breakage on 15 and 16 remaining. I have not tried building > OpenCoarrays with the shmem patch applied yet. This will be my next step here. > > Regards, > > Jerry > -- Andre Vehreschild * Email: vehre ad gmx dot de
[Patch, Fortran, Coarray, PR88076, v1] 7/6 Add a shared memory multi process coarray library.
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
--
Andre Vehreschild * Email: vehre ad gmx dot de
From 6a50f10bfa802fc93eaf302bf5493506b5795e6a Mon Sep 17 00:00:00 2001
From: Andre Vehreschild
Date: Wed, 2 Jul 2025 11:47:18 +0200
Subject: [PATCH] Fortran: Fix includes in caf_shmem (esp. for BSDs) [PR88076]
PR fortran/88076
libgfortran/ChangeLog:
* caf/shmem.c: Remove declaration of environment.
* caf/shmem/allocator.h: Fix required includes.
* caf/shmem/hashmap.h: Same.
* caf/shmem/shared_memory.h: Same.
* caf/shmem/supervisor.c (ensure_shmem_initialization): Insert
declaration of environment and fix includes.
---
libgfortran/caf/shmem.c | 2 --
libgfortran/caf/shmem/allocator.h | 1 +
libgfortran/caf/shmem/hashmap.h | 3 ++-
libgfortran/caf/shmem/shared_memory.h | 1 +
libgfortran/caf/shmem/supervisor.c| 8
5 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/libgfortran/caf/shmem.c b/libgfortran/caf/shmem.c
index b52f9479948..3d83782db24 100644
--- a/libgfortran/caf/shmem.c
+++ b/libgfortran/caf/shmem.c
@@ -78,8 +78,6 @@ static enum {
} accessor_hash_table_state
= AHT_UNINITIALIZED;
-extern char **environ;
-
void
_gfortran_caf_init (int *argc, char ***argv)
{
diff --git a/libgfortran/caf/shmem/allocator.h b/libgfortran/caf/shmem/allocator.h
index e55d974301d..53b6abeeba1 100644
--- a/libgfortran/caf/shmem/allocator.h
+++ b/libgfortran/caf/shmem/allocator.h
@@ -31,6 +31,7 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If not, see
#include "shared_memory.h"
#include
+#include
/* The number of bits a void pointer has. */
#define VOIDP_BITS (__CHAR_BIT__ * sizeof (void *))
diff --git a/libgfortran/caf/shmem/hashmap.h b/libgfortran/caf/shmem/hashmap.h
index dbb5a1171c4..bc263d32dcd 100644
--- a/libgfortran/caf/shmem/hashmap.h
+++ b/libgfortran/caf/shmem/hashmap.h
@@ -27,8 +27,9 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If not, see
#include "allocator.h"
-#include
#include
+#include
+#include
/* Data structures and variables:
diff --git a/libgfortran/caf/shmem/shared_memory.h b/libgfortran/caf/shmem/shared_memory.h
index b2e6bbe4ae9..01ac2811e5d 100644
--- a/libgfortran/caf/shmem/shared_memory.h
+++ b/libgfortran/caf/shmem/shared_memory.h
@@ -27,6 +27,7 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If not, see
#include
#include
+#include
/* Global metadata for shared memory, always kept at offset 0. */
diff --git a/libgfortran/caf/shmem/supervisor.c b/libgfortran/caf/shmem/supervisor.c
index c24bb30aa95..53b6facb6e1 100644
--- a/libgfortran/caf/shmem/supervisor.c
+++ b/libgfortran/caf/shmem/supervisor.c
@@ -22,6 +22,8 @@ a copy of the GCC Runtime Library Exception along with this program;
see the files COPYING3 and COPYING.RUNTIME respectively. If not, see
Re: [Fortran, Patch, PR120843, v3] Fix reject valid, because of inconformable coranks
On 7/2/25 4:12 PM, Jerry D wrote: On 7/2/25 9:40 AM, Jerry D wrote: On 7/2/25 3:14 AM, Andre Vehreschild wrote: Hi all, I successfully created a big mess with the previous patch. First of all by applying an outdated one and secondly by adding the conformance checks for coranks in a3f1cdd8ed46f9816b31ab162ae4dac547d34ebc. Checking the standard even using AI (haha) to figure if coranks of an expression have restrictions on them, failed. I found nothing. AI fantasized about restrictions that did not exist. Therefore the current approach is to remove the conformance check and just use the computed coranks in expressions to prevent recomputaion whenever they needed. Jerry, Harald: Sorry for all the bother and all my mistakes. I am really sorry to have wasted your time. The patch has been regtested fine on x86_64-pc-linux-gnu / F41. Ok for mainline and later backport to gcc-15? Regards, Andre --- snip --- With this fixer patch, I can successfully compile Toon's test case. The patch also regression tests here OK. OK to push. Jerry As a followup, with the fixer patch applied, OpenCoarrays builds. However, make test hangs at Test 4. 3/88 Test #3: register_vector ... Passed 0.42 sec Start 4: register_alloc_vector ^Cmake[3]: *** [CMakeFiles/check.dir/build.make:70: CMakeFiles/check] Interrupt make[2]: *** [CMakeFiles/Makefile2:962: CMakeFiles/check.dir/all] Interrupt make[1]: *** [CMakeFiles/Makefile2:969: CMakeFiles/check.dir/rule] Interrupt make: *** [Makefile:205: check] Interrupt I waited about 20 minutes. This may be another bug. I built and tested OpenCorrays about 2 days ago with gfortran 14 with no problems. I am able to compile and run Toon's test case with this OpenCoarrays. So we still have some breakage on 15 and 16 remaining. I have not tried building OpenCoarrays with the shmem patch applied yet. This will be my next step here. Regards, Jerry I managed to build OpenCoarrays with a new clone from Andre's suggested branch. I started with a completely empty build directory. Although it builds, I still get the hang on register_alloc_vector.f90. I pulled that test case out to see what it is doing. It will compile and run with -lcaf_shmem and appears to run OK. I tried to test it under valgrind and it prints that it passed however, right after that it hangs. I could not kill the process and had to do a system shutdown and wait for the kernel to kill it. Valgrind was starting to report an unfreed block 26 allocated 25 freed. The system froze after that. This is on x86_64 Fedora 42 With Toon's test case, when one chooses a number of images for the test that does not satisfy: (I used np=17) if (mod(nxglobal * nyglobal, npxy) /= 0) then print*, 'Number of images and domain size do not allow an equal-sized partitioning.' stop 1 endif The stop does not exit the program. I wonder if either finalization or needing to handle stop with multiple images needs to be addressed. I don't know. Regardless, it is not playing well with something in the system here. Andre, as your time is running short, maybe push this to a gcc development branch to capture what you have so we can examine further. There is something lurking in this still. Let me know. Regards, Jerry
Re: [PATCH] Fortran: fix minor issues with coarrays (extended)
Hi all,
attached patch narrows the use of intrinsic functions in the caf accessor down
to pure elemental functions. This is needed because functions that get extracted
into the caf accessor routine, have no access to the source image's memory. E.g.
team_number() is marked as pure, but takes a pointer argument to an object in
the source image's memory, which is not available on the remote image where the
accessor is executed. This patch fixes that and also corrects the type in the
decl of the ABI of team_number. It is of the opaque type team_type aka void* now
and not integer as formerly declared.
Regtest ok on x86_64-pc-linux-gnu / F41. Ok for mainline?
Regards,
Andre
On Tue, 1 Jul 2025 12:54:49 -0700
Jerry D wrote:
> On 7/1/25 12:51 PM, Harald Anlauf wrote:
> > Dear all,
> >
> > the attached patch fixes the following minor issues found by running
> > f951 under valgrind for the just added new testcases coindexed_6.f90
> > and coindexed_7.f90:
> >
> > - minor front-end memleaks with non-freed strings and lost GMP variables
> > (these are simple and obvious fixes)
> >
> > - an inconsistency between pure/elemental functions being either
> > non-intrinsic or intrinsic. Checking for the latter was likely missed
> > from the beginning.
> >
> > No new testcase.
> >
> > Regtested on x86_64-pc-linux-gnu. OK for mainline?
> >
> > Thanks,
> > Harald
> >
>
> Yes, OK, straight-forward.
>
> Thanks,
>
> Jerry
--
Andre Vehreschild * Email: vehre ad gmx dot de
From 4b9181aab9fc1b3982724a442b19c69458459b5f Mon Sep 17 00:00:00 2001
From: Andre Vehreschild
Date: Fri, 4 Jul 2025 11:26:46 +0200
Subject: [PATCH] Fortran: Fix pure/elemental function treatment and
team_number parameter attribution.
gcc/fortran/ChangeLog:
* coarray.cc (check_add_new_component): Only allow pure
elemental intrinsic functions in a coarray accessor.
* trans-decl.cc (gfc_build_builtin_function_decls): The only
argument of team_number() is of type void* in the library ABI.
---
gcc/fortran/coarray.cc| 2 +-
gcc/fortran/trans-decl.cc | 7 +++
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/gcc/fortran/coarray.cc b/gcc/fortran/coarray.cc
index ef8fd4e42d0..01aac581a74 100644
--- a/gcc/fortran/coarray.cc
+++ b/gcc/fortran/coarray.cc
@@ -700,7 +700,7 @@ check_add_new_component (gfc_symbol *type, gfc_expr *e, gfc_symbol *add_data)
&& !e->symtree->n.sym->attr.elemental
&& !(e->value.function.isym
&& (e->value.function.isym->pure
- || e->value.function.isym->elemental)))
+ && e->value.function.isym->elemental)))
/* Treat non-pure/non-elemental functions. */
check_add_new_comp_handle_array (e, type, add_data);
else
diff --git a/gcc/fortran/trans-decl.cc b/gcc/fortran/trans-decl.cc
index 43bd7be54cb..ba4a842a025 100644
--- a/gcc/fortran/trans-decl.cc
+++ b/gcc/fortran/trans-decl.cc
@@ -4223,10 +4223,9 @@ gfc_build_builtin_function_decls (void)
get_identifier (PREFIX ("caf_sync_team")), ". r w w w ", void_type_node,
4, pvoid_type_node, pint_type, pchar_type_node, size_type_node);
- gfor_fndecl_caf_team_number
- = gfc_build_library_function_decl_with_spec (
- get_identifier (PREFIX("caf_team_number")), ". r ",
- integer_type_node, 1, integer_type_node);
+ gfor_fndecl_caf_team_number = gfc_build_library_function_decl_with_spec (
+ get_identifier (PREFIX ("caf_team_number")), ". r ", integer_type_node,
+ 1, pvoid_type_node);
gfor_fndecl_caf_image_status = gfc_build_library_function_decl_with_spec (
get_identifier (PREFIX ("caf_image_status")), ". r r ",
--
2.50.0
Re: [PATCH 16/17] Fortran: Silence a clang warning (suggesting a brace) in io.cc
Hello,
On Wed, Jun 25 2025, Steve Kargl wrote:
> Thanks for cleaning up gfortran code. I was curious about
> what the GNU Coding Standard said about this case, but it
> does not consider initialization of subobjects. I did find
>
>5.3 Clean Use of C Constructs
>...
>Don't make the program ugly just to placate static
>analysis tools such as lint, clang, and GCC with extra
>warnings options such as -Wconversion and -Wundef.
>These tools can help find bugs and unclear code, but
>they can also generate so many false alarms that it hurts
>readability to silence them with unnecessary casts,
>wrappers, and other complications.
>
> I do not see the extra '{...}' as hurting readability. I
> have no objection to the change. Does anyone else have a
> comment?
OK, I took that as an approval and committed the change as 0b7c27325c7.
Generally speaking, I agree that we definitely should not alter the
source code because of all clang warnings and we don't, we filter out
quite many of them in contrib/filter-clang-warnings.py.
But there is also benefit in limiting the number of cases we filter out
and in this case I thought it was easier to change the source code.
Thank you,
Martin
>
> --
> steve
>
>
> On Wed, Jun 25, 2025 at 04:18:16PM +0200, Martin Jambor wrote:
>> Hi,
>>
>> when GCC is built with clang, it suggests that we add a brace to the
>> initialization of format_asterisk:
>>
>> gcc/fortran/io.cc:32:16: warning: suggest braces around initialization of
>> subobject [-Wmissing-braces]
>>
>> So this patch does that to silence it.
>>
>> Bootstrapped and tested on x86_64-linx. OK for master?
>>
>> Alternatively, as with all of these clang warning issues, I'm
>> perfectly happy to add an entry to contrib/filter-clang-warnings.py to
>> ignore the warning instead.
>>
>> Thanks,
>>
>> Martin
>>
>>
>>
>> gcc/fortran/ChangeLog:
>>
>> 2025-06-24 Martin Jambor
>>
>> * io.cc (format_asterisk): Add a brace around static initialization
>> location part of the field locus.
>> ---
>> gcc/fortran/io.cc | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/gcc/fortran/io.cc b/gcc/fortran/io.cc
>> index 7466d8fe094..4d28c2c90ba 100644
>> --- a/gcc/fortran/io.cc
>> +++ b/gcc/fortran/io.cc
>> @@ -29,7 +29,7 @@ along with GCC; see the file COPYING3. If not see
>>
>> gfc_st_label
>> format_asterisk = {0, NULL, NULL, -1, ST_LABEL_FORMAT, ST_LABEL_FORMAT,
>> NULL,
>> - 0, {NULL, NULL}, NULL, 0};
>> + 0, {NULL, {NULL}}, NULL, 0};
>>
>> typedef struct
>> {
>> --
>> 2.49.0
>
> --
> Steve
Re: [Patch, Fortran, Coarray, PR88076, v1] 7/6 Add a shared memory multi process coarray library.
Am 04.07.25 um 14:12 schrieb Andre Vehreschild: Regtests ok on x86_64-pc-linux-gnu and aarch64-unknown-freebsd14.3. Ok for mainline? The whole patch set needs including the library needs rigorous and extensive testing against race conditions, as outlined in https://gcc.gnu.org/pipermail/fortran/2025-June/062378.html .
Re: [Patch, Fortran, Coarray, PR88076, v1] 7/6 Add a shared memory multi process coarray library.
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 $ real0m0.066s user0m0.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
