I am throwing in the towel.
I am chalking up the hours I have spent on this as a positive on the
educational side of the ledger. I have learned things about
git-cherry-pick, git-rev-list, and git-log that I didn't know, and that's
good.
I have reached the point where I am convinced that what I would like to do
is not just hard, but impractical. I got to this point:
git switch -C patched15 gcc/releases/gcc-15
git cherry-pick -x \
$(git rev-list basepoints/gcc-16..gcc/master \
--invert-grep --grep="Daily bump" \
-- libgcobol gcc/cobol gcc/testsuite/cobol.dg)
That rev-list command produces a list of all the commits since The Beginning
Of GCC-16 that touch files in libgcobol/, gcc/cobol/ and
gcc/testsuite/cobol.dg, which is what I wanted. But the result is numerous
conflicts.
I had to exclude the "Daily bump" commits because the ones that affect
gcc/cobol/ChangeLog or libgcobol/ChangeLog tend to modify many other
ChangeLogs as well, leading to conflicts.
But even with that filter, numerous other conflicts arise. Thirty-two of
them, as a matter of fact. Exactly one of them is in a gcc/cobol cobol
file; the rest are in other source code trees.
Many of those conflicts occurred because of wide-ranging commits that change
not just gcc/cobol files, but files in other source trees. (I am looking at
you, David Malcolm; your changes to the diagnostics cut quite the swath
through the GCC source code.)
So, although I think I now know how to set up this kind of mass backporting
for something isolated, the changes since GCC-16 was branched off from -15
are too extensive for me to treat COBOL in isolation.
C'est la vie.
Thank you so much for the help you offered. Although I couldn't do what I
set out to do, your pointers led have led me not only to a better
understanding of GIT, but I also know why I can't do such a big update to
just COBOL.
Best regards to all,
Bob Dubner
> -----Original Message-----
> From: Robert Dubner <rdub...@symas.com>
> Sent: Sunday, July 27, 2025 11:25
> To: Richard Biener <rguent...@suse.de>
> Cc: g...@gcc.gnu.org; gcc-patches@gcc.gnu.org; James K. Lowden
> <jklow...@cobolworx.com>
> Subject: RE: GCC 15.1.1 Status Report (2025-07-11)
>
> Thanks to everybody. I actually did do the more specific searches over a
> range starting at the gcc-15 starting point; in my frustration I didn't
> copy
> the final actual command I used. I thought I needed to start at the
> original releases/gcc-15 point because that's where we branched away, and
> as
> far as I know, no COBOL patches have been applied to GCC-15 since.
>
> I'll do what I can later, later or tomorrow; today is booked up with Real
> Life. I don't have high hopes; there were modifications to to
> configure.ac
> and Make-lang.in, and those seem to generate conflicts that I don't have
> much idea how to resolve.
>
> If I don't make headway quickly, then I am likely to throw in the towel
> pretty fast. <shrug> It's not like GCC-15 being brought up to date is a
> necessity.
>
> > -----Original Message-----
> > From: Richard Biener <rguent...@suse.de>
> > Sent: Sunday, July 27, 2025 06:56
> > To: Robert Dubner <rdub...@symas.com>
> > Cc: g...@gcc.gnu.org; gcc-patches@gcc.gnu.org; James K. Lowden
> > <jklow...@cobolworx.com>
> > Subject: RE: GCC 15.1.1 Status Report (2025-07-11)
> >
> > On Sat, 26 Jul 2025, Robert Dubner wrote:
> >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Richard Biener <rguent...@suse.de>
> > > > Sent: Saturday, July 26, 2025 12:06
> > > > To: Robert Dubner <rdub...@symas.com>
> > > > Cc: g...@gcc.gnu.org; gcc-patches@gcc.gnu.org; James K. Lowden
> > > > <jklow...@cobolworx.com>
> > > > Subject: Re: GCC 15.1.1 Status Report (2025-07-11)
> > > >
> > > >
> > > >
> > > > > Am 26.07.2025 um 01:31 schrieb Robert Dubner <rdub...@symas.com>:
> > > > >
> > > > > Richard, this message of yours about changes for 15.2 RC has been
> > > > > percolating in my head since I first saw it.
> > > > >
> > > > > So, today I gave it a shot.
> > > > >
> > > > > A significant amount of COBOL development has occurred in the four
> > > > > months
> > > > > since GCC-15 was released.
> > > > >
> > > > > I just built a patch that brought changes in COBOL from
> > > > > releases/gcc-15
> > > > > up
> > > > > to the current level of master. The gcc-mklog file is a mere
> > > > > 1,408
> > > > > lines;
> > > > > the .diff is 4,778 lines comprising 1,791,437 bytes.
> > > > >
> > > > > A bootstrap build of
> > > > > "--enable-languages=all,cobol --disable-multilib"
> > > > > ran
> > > > > quietly to completion; "make check-cobol" subsequently behaved
> > > > > properly.
> > > > >
> > > > > I see no reason not to bring 15.2RC up to the level of 16. It's
> > > > > hard
> > > > > for
> > > > > me to believe that anybody is actually counting on the COBOL
> > > > > problems in
> > > > > 15 not being fixed.
> > > > >
> > > > > I am not inclined to annotate those 4,778 lines with anything but
> > > > > "Bring
> > > > > 15.2 RC up to 16 master" followed by 4,447 instances of
> > > > > "Likewise.".
> > > > >
> > > > > Having said that, please recommend how this be done.
> > > > >
> > > > > I can publish a multitude of patch e-mails for the world to
> > > > > peruse.
> > > > > I
> > > > > can
> > > > > put all those changes into a single commit on
> > > > > g...@gitlab.cobolworx.com:COBOLworx/gcc-cobol.git, so that they
> > > > > easily
> > > > > can
> > > > > be applied by somebody who isn't me. Or, I can, once the changes
> > > > > are
> > > > > approved, apply the commit myself.
> > > > >
> > > > > How best to do something like this? Should I bust the 1.7MB diff
> > > > > into
> > > > > twenty or so [PATCH] xx/20 messages of about 65K each, and send
> > > > > them
> > > > > to
> > > > > gcc-patches?
> > > >
> > > > I would have expected the backport to be a series of hit cherry-pick
> > > > from
> > > > trunk. So if you can publish a repo with those picks on cobolworx
> > > > that
> > > > should
> > > > be sufficient (use git cherry-pick -x so the original rev picked
> > > > will
> > > > show
> > > > up). Any additional changes or diffs required should be posted to
> > > > GCC-
> > > > patches.
> > >
> > >
> > > Follow-up: After poking around on the internet for inspiration, I
> > > used
> > >
> > > git log
> > > basepoints/gcc-15~1..HEAD --reverse --grep="^gcc/cobol" --
> grep="^libgcobol"
> > > --grep="cobol.dg"
> > >
> > > to create a list of commits to be cherry-picked. That resulted in a
> > > list of
> > > 120 commits. I was unable to cherry-pick them; there were multiple
> > > merge
> > > conflicts. I tried using "cherry-pick --strategy=ours". I then
> > > compared
> > > the gcc/cobol and libgcobol files with gcc-16.
> > >
> > > There are hundreds of residual difference; the goal is none.
> > >
> > > I haven't even talked with Jim or our firm about this; I took it on
> > > myself.
> > > I think back-porting where we are with trunk to GCC-15.2 is a good
> > > idea;
> > > I
> > > think they would agree. UI hope you agree.
> >
> > Yes, I specifically thought of the larger refactorings that would
> > otherwise make it much more difficult to do selective backports to
> > the GCC 15 release series.
> >
> > > My automated method of taking a diff of the COBOL front end files
> > > starting
> > > from basepoints/gcc-15 and ending with the current trunk, and turning
> > > that
> > > into a single commit demonstrably works for x86_64-linux.
> > >
> > > I simply don't know how to create a list of cherry-pick commits from
> > > trunk
> > > that does the same thing.
> > >
> > > I wasted, and I mean that, about four hours today trying.
> > >
> > > What do you suggest I do?
> >
> > Please see the helpful comments from Andreas. I think we _do_ want to
> > do the backport with cherry-picks, not with a large patch generated
> > by diffing two trees (if that were the only option I'd call it off).
> > Such diff might be useful to see if we missed any cherry-picks, of
> > course.
> >
> > Richard.
> >
> >
> > >
> > >
> > >
> > > >
> > > > Thanks,
> > > > Richard
> > > >
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Bob D.
> > > > >
> > > > >> -----Original Message-----
> > > > >> From: Gcc <gcc-bounces~rdubner=symas....@gcc.gnu.org> On Behalf
> > > > >> Of
> > > > > Richard
> > > > >> Biener via Gcc
> > > > >> Sent: Friday, July 11, 2025 06:38
> > > > >> To: g...@gcc.gnu.org; gcc-patches@gcc.gnu.org
> > > > >> Subject: GCC 15.1.1 Status Report (2025-07-11)
> > > > >>
> > > > >>
> > > > >> The releases/gcc-15 branch is open for regression and
> > > > >> documentation
> > > > > fixes.
> > > > >> This is now the time to prepare for the GCC 15.2 release - a
> > > > >> release
> > > > >> candidate is planned for Friday Aug 1st, three weeks from now,
> > > > >> with
> > > > >> the GCC 15.2 release following a week after that.
> > > > >>
> > > > >> Please go over reported regressions for your target and
> > > > >> maintainance
> > > > >> area and see which ones can be fixed and/or backported from
> > > > >> trunk.
> > > > >> For
> > > > >> GCC 15.2 we are more permissive with what kind of fixes we allow,
> > > > >> esp.
> > > > >> it is still possible to resolve missed-optimization regressions.
> > > > >>
> > > > >>
> > > > >> Quality Data
> > > > >> ============
> > > > >>
> > > > >> Priority # Change from last report
> > > > >> -------- --- -----------------------
> > > > >> P1 1 + 1
> > > > >> P2 596 + 16
> > > > >> P3 185 + 84
> > > > >> P4 236 - 3
> > > > >> P5 23
> > > > >> -------- --- -----------------------
> > > > >> Total P1-P3 782 + 101
> > > > >> Total 1041 + 98
> > > > >>
> > > > >>
> > > > >> Previous Report
> > > > >> ===============
> > > > >>
> > > > >> https://gcc.gnu.org/pipermail/gcc/2025-April/245972.html
> > >
> >
> > --
> > Richard Biener <rguent...@suse.de>
> > SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461
> > Nuernberg,
> > Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman;
> > HRB 36809 (AG Nuernberg)
