Hi Jerry, Yes, I agree that it is absurd but also understandable. I have kept clear of both OMP and coarray bugs, especially regressions, because I don't feel competent to deal with them.
I suggest the following policy in respect of partially implemented regression fixes: 1] Fixes already in place on 26th April 2023 (the gcc-13.0 release) should be closed; 2] If possible backport regressions to gcc-13 and close, if no more than pattern matching prevents application of the patch and regtesting is OK; 3] Do not backport if other fixes or evolutionary changes prevent it; and 4] In cases 1] and 2], an informatory message should be sent to the fortran list. Flagging several closed PRs at the same time is acceptable. In the case of 3], an explanatory message to the fortran list of the intention to close, with a deadline. Of the regressions assigned to me: 110626: I do not see a satisfactory way to fix this bug without reworking ordinary assignment to be fully compliant with F2018 10.2.1; 84245: A patch was posted on 2024-11-30 but a query on the PR prevented further progress. I will return to it and, if I cannot see a way to prevent the fix from causing a compiler memory leak, will submit it to the list; 10155: A patch was posted on 2025-02-08 that "needs to be completely refactored". It still applies cleanly and runs OK; and 105168: A patch was posted on 2025-01-03. It applies cleanly and gives the same runtime results as at least one other brand. (2 others ICE!) Paul On Sat, 14 Mar 2026 at 02:20, Jerry D <[email protected]> wrote: > > On 3/13/26 7:13 PM, Jerry D wrote: > > Hello all, > > > > During Chris Alberts campaign going through all the gfortran know > > regressions he > > noted a large number that have been fixed and never backported. These > > simpley > > hang out there to bug and distract us and nothing every gets done. > > > > Most of these are either openmp or oacc bugs. Myself I see no point in back > > porting these. Others think we should backport. My goal is zero regressions. > > > > If the consensus is to backport these, then my first response is the initial > > patch committer should have done it by now. Some of these are many years > > old. > > > > I will backport these and test, but I do not do the usual other libgomp > > tests > > that are run by others, so I hesitate for fear of breaking something since > > some > > of the patches are ancient. > > > > The question is backport and close or just close them? If backport, how far > > back > > is worth going, obviously 13 is as far back as we can go? (Since no one has > > whined about these regressions for so long my impression is they are > > irrelevant) > > > > Regards, > > > > Jerry, master janitor extraordinaire. > > PS This is a classic example, this thing has sat out in never never land for > 10 > years. This is absurd. > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77371 >
