Hi Andre, The shmem library was the first place that I went to:
I found that _gfortran_caf_end_team calls _gfortran_caf_deregister, which takes the alloc_free_memory_with_id branch for these allocatable coarrays. Then something doesn't happen, which should! I gave up in the end but will go back to it, having learned a lot in my failed attempt and the posted patch. Regards Paul On Fri, 24 Jul 2026 at 17:01, Andre Vehreschild <[email protected]> wrote: > Hi Paul, > > interesting issue, because the caf-libraries have a list of coarrays > allocated > for each team and free them, when the team is left. > > - Andre > > On Fri, 24 Jul 2026 16:18:57 +0100 > Paul Richard Thomas <[email protected]> wrote: > > > Hello All, > > From John Reid's "Summary_of_Fortran_2018": > > > > 3.5 Coarrays allocated in teams > > > > ....snip.... > > > > In Fortran 2018, synchronization is now across the team, of course. > > Symmetric memory is maintained within teams by requiring that > > > > 1. any allocatable coarray that is allocated before entry to a change > team > > construct remains allocated during the execution of the construct and > > 2. any allocatable coarray that becomes allocated within a change team > > construct and is still allocated when the construct is left is > > automatically deallocated, even if it has the save attribute. > > > > ....more snips.... > > > > Requirement 2 is not yet implemented in gfortran. The attachment does the > > job. > > > > Regression tested on FC44/x86_64 - OK for mainline and eventual > backporting > > to 16-branch? > > > > Paul > > > -- > Andre Vehreschild * Email: vehre ad gmx dot de >
