Hi Bob!
On 2025-07-27T16:00:29-0500, Robert Dubner <rdub...@symas.com> 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.
Hmm, I'm not seeing that?
> 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.
Right, those need to be excluded.
> 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.)
Well, that happens. :-) But: mass-refactoring to improve the overall
code organization etc. certainly has a very high merit on its own, so
that's OK to cause some "collateral damage".
But then: those commits aren't applicable for GCC 15 backporting anyway,
so just 'git cherry-pick --skip' those.
I just executed (a variant of) what I had in my other email:
$ rev_start=origin/releases/gcc-15 # Will be different next time.
$ git log --reverse --stat -p --regexp-ignore-case --grep=cobol
"$rev_start"..origin/trunk
I 'git cherry-pick --skip'ed the (few, just two?) commits that had alread
made it into releases/gcc-15 branch, and 'git cherry-pick --skip'ed the
last few diagnostics-related ones, and: everything else of those
GCC/Cobol commits 'git cherry-pick -x'ed without any conflicts.
I'm happy to put that branch into my usual testing, and/or publish it for
anyone to test, if you still see value in that. (..., and unless you'd
like to reproduce that yourself.) ;-)
Grüße
Thomas
> 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: 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)
>>
>> 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)
