Hi Jerry,
> Andre, one of the the other things I have not got to yet is reviewing the
> interface between gfortran and the caf_shmem. Is this interface generic
> enough to allow other libraries to be used. For example, we have the
> caf_shmem library and we have the OpenCoarrays library, down t
On 7/21/25 20:52, Andre Vehreschild wrote:
Hi Toon,
the coarray_native branch is not where Jerry has put the caf_shmem
patches. Coarray native is an older branch, that used a different
approach to shared memory coarrays. Caf_shmem is partially based on it.
The branch Jerry has build is
rem
Hi Toon,
the coarray_native branch is not where Jerry has put the caf_shmem patches.
Coarray native is an older branch, that used a different approach to shared
memory coarrays. Caf_shmem is partially based on it.
The branch Jerry has build is
remotes/origin/devel/gfortran-test
- AndreAndr
On 7/19/25 20:40, Jerry D wrote:
Yes, this is why we need additional testers.
For those who need some guidance to the test branch:
$ git clone git://gcc.gnu.org/git/gcc.git
$ cd gcc
$ git checkout remotes/origin/devel/gfortran-test
$ git switch -c gfortran-test
If you already have an existi
On 7/19/25 5:06 PM, Jerry D wrote:
On 7/19/25 2:26 PM, Thomas Koenig wrote:
I wrote:
I have grave concerns.
At the last (to me an Nicolas) known state, before he was ousted
from the project, there were known race conditions, which can
cause freezing and/or data corruption.
I believe these ha
On 7/19/25 23:26, Thomas Koenig wrote:
I wrote:
I have grave concerns.
At the last (to me an Nicolas) known state, before he was ousted
from the project, there were known race conditions, which can
cause freezing and/or data corruption.
I believe these have not been addressed, neither tested
On 7/19/25 2:26 PM, Thomas Koenig wrote:
I wrote:
I have grave concerns.
At the last (to me an Nicolas) known state, before he was ousted
from the project, there were known race conditions, which can
cause freezing and/or data corruption.
I believe these have not been addressed, neither teste
I wrote:
I have grave concerns.
At the last (to me an Nicolas) known state, before he was ousted
from the project, there were known race conditions, which can
cause freezing and/or data corruption.
I believe these have not been addressed, neither tested nor by
inspection.
Maybe a word of exp
Am 19.07.25 um 18:32 schrieb Jerry D:
I am ready to approve this. Can anyone second this.
I have grave concerns.
At the last (to me an Nicolas) known state, before he was ousted
from the project, there were known race conditions, which can
cause freezing and/or data corruption.
I believe thes
On 7/19/25 10:59 AM, Toon Moene wrote:
On 7/19/25 18:32, Jerry D wrote:
I expanded on Toon's random_weather.f90 test using:
!integer, parameter :: DNX = 72, DNY = 70, DNZ = 30, BDSIZE = 4, HORSTEP =
1, VERSTEP = 100, FCLEN = 3600, TIMSTEP = 240
integer, parameter :: DNX = 1000, DNY =
On 7/19/25 18:32, Jerry D wrote:
I expanded on Toon's random_weather.f90 test using:
!integer, parameter :: DNX = 72, DNY = 70, DNZ = 30, BDSIZE = 4, HORSTEP =
1, VERSTEP = 100, FCLEN = 3600, TIMSTEP = 240
integer, parameter :: DNX = 1000, DNY = 1500, DNZ = 100, BDSIZE = 4,
HORSTEP =
On 7/17/25 9:37 PM, Jerry D wrote:
I have created a new gfortran-test branch on gcc here.
origin/devel/gfortran-test
This has the patches applied as needed to do the testing I have done.
When Andre's patches are approved I will revert and rebase this so we can test
the next set of major chang
I have created a new gfortran-test branch on gcc here.
origin/devel/gfortran-test
This has the patches applied as needed to do the testing I have done.
When Andre's patches are approved I will revert and rebase this so we can test
the next set of major changes. I have done this to simplify the
On 7/16/25 7:13 AM, Andre Vehreschild wrote:
Hi Jerry,
I am back on track.
--- snip ---
After some back and forth with Andre I finally understand the discrepancies I
was having here. Andre has an OpenCoarrays branch being used to update
OpenCoarrays to sync with changes to gfortran-16. Thi
Hi Jerry,
I am back on track.
I tried to replay your fault with my latest patch for pr88076 and the latest
patch on the OpenCoarray's branch, namely this one:
https://github.com/sourceryinstitute/OpenCoarrays/commit/47a7a470a0a88f8a9e8c72dfaa8ab685f6b58ecd
I can not replay the error you got. For
On the tsunami example from Curcic book Modern Fortran I am getting the
following:
$ cafrun -np 4 ./tsunami
At line 201 of file mod_field.f90
Fortran runtime error: Attempting to allocate already allocated variable 'edge'
At line 201 of file mod_field.f90
Fortran runtime error: Attempting to all
Thanks.
I'll try that tomorrow.
Kind regards,
Toon.
On 7/7/25 23:00, Jerry D wrote:
Hello all,
I have done the following to test the collection of Andre's patches
which implement the subject -lcaf_shmem:
1) Successfully compiled and executed Toon's random_weather.f90 program.
The only qu
Hello all,
I have done the following to test the collection of Andre's patches which
implement the subject -lcaf_shmem:
1) Successfully compiled and executed Toon's random_weather.f90 program. The
only question I have on this one is when I select an np value such that the slab
size does not
18 matches
Mail list logo