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)
