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: gcc@gcc.gnu.org; gcc-patc...@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: gcc@gcc.gnu.org; gcc-patc...@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: gcc@gcc.gnu.org; gcc-patc...@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)
