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) Did you test building accelerator compilers in particular? I suppose you've covered Darwin, did your testing cover mingw? 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? The other thing to look at is ABI - is the new support part of libgfortran? Thanks, Richard. > Regards, > > Jerry > > > -- Richard Biener <[email protected]> SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Jochen Jaser, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
