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
