Re: GCC/gfortran: asking for permission to merge devel/gfortran-test into master, adding a shared memory implementation of coarrays.

On 2/9/26 2:46 AM, Richard Biener wrote:
> On Sun, 8 Feb 2026, Jerry D wrote:
> 
>> On 2/5/26 11:08 PM, Richard Biener wrote:
>>> On Thu, 5 Feb 2026, Toon Moene wrote:
>>>
>>>> Dear release managers,
>>>>
>>>> We are aware that this request comes quite late (now that the development
>>>> of
>>>> gcc-16 is in stage 4), but we have been testing a shared memory
>>>> implementation
>>>> of co-arrays on the devel/gfortran-test branch for over half a year.
>>>>
>>>> We hope that the following considerations will convince you that this
>>>> action
>>>> is quite harmless:
>>>>
>>>> 1. gfortran is not considered "release-critical".
>>>> 2. the shared memory implementation of coarrays is largely contained
>>>>      to a single library.
>>>> 3. it will only be used when specifically asked for by the users of
>>>>      gfortran *on the command line* and will not interfere with other
>>>>      implementations of coarrays when not requested.
>>>>
>>>> Thanks in advance for your thoughts.
>>>
>>> In principle OK - the main issue is possible build time regressions
>>> given gfortran is still a default language.  I can't tell how
>>> complicated the integration of the library is though, so final
>>> ACK/NACK depends on seeing actual patches that touch the
>>> build system.
>>>
>>> So I'd propose you send an integration patch-set to the list.
>>>
>>> Richard.
>>>
>>>> Kind regards,
>>>>
>>>>
>>>
>>
>> Here is a current patch set. I moved the portions related to
>> libgfortran/configure into a separate patch called modConfigure.diff to clean
>> up a minor merge conflict involving the '# line' + line number in a few
>> places.
>>
>> The hunks in modConfigure.diff came from the original pr88076_v4_7 and
>> pr88076_v4_8 patches.  Obviously the commit messages will be cleaned up before
>> a commit.
>>
>> These patches are provided for patch testers if so desired.  All known issues
>> in bugzilla have been fixed. OpenCoarrays builds and tests fine.
>>
>> The patches should be applied in order, 1 thru 12. Then apply the
>> modConfigure.diff.  Note in the original Changelogs one see's that generated
>> configuration files were regenerated.  This will be noted in the ChangeLog for
>> the modConfigure.diff.
>>
>> Either myself or Andre will do the commit when approved.
> 
> I'm seeing configure.ac in diffstat in some of the patches but no
> actual patch?  (just checked the first 5 I think)

I moved these to the modConfiger.diff patch. I will cleanup the patches for commit.

> 
> Did you test building accelerator compilers in particular? I suppose
> you've covered Darwin, did your testing cover mingw?

I am checking to see if someone can test on mingw and Darwin.

I do not understand what you mean by accelerator compilers. ?

> 
> That said, I was after seeing a opt-in explicit list of target
> triplets in configure.ac which would be obviously safe.  Logs
> indicate you have checks for mmap and stuff, that's eventually
> prone to build failures on one of our more arcane targets?

I will need help on specifics of setting targets.

> 
> The other thing to look at is ABI - is the new support part of
> libgfortran?

Yes, it is part of libgfortran. I will check on the ABI question.


Regards