On Sun, 27 Jul 2025, Robert Dubner wrote: > 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.
Ah, yeah. > 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.) OK, I didn't expect much of that, but yeah, those can be a pain (and we don't want to pull those as dependences). > 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. But your diff approach would have the same issue - it would pull in Davids changes as well, likely result in something not buildable? > C'est la vie. True :/ > 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. See above. In particular I prefer cherry-picks because that makes it obvious what is missing and what got included. I'd have expected some global configury things we'd have to pull, possibly some target stuff. But it's now also way too late to do all this manual surgery. Thanks, Richard. > 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) > -- Richard Biener <rguent...@suse.de> SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
