> -----Original Message-----
> From: Richard Biener <rguent...@suse.de>
> Sent: Monday, July 28, 2025 04:17
> To: Robert Dubner <rdub...@symas.com>
> Cc: Andreas Schwab <sch...@suse.de>; Thomas Schwinge
> <tschwi...@baylibre.com>;
> David Malcolm <dmalc...@redhat.com>; 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 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?
The Big Diff started at the -15/-16 fork point, and ended at origin/master.
It included only files in libgcobol, gcc/cobol, and
gcc/testsuite/cobol.dg -- no others were examined.
"ChangeLog|DATESTAMP|BASE-VER|DEV-PHASE" were all filtered out as well.
I then applied that diff to releases/gcc-15. A
"configure --languages=all,cobol" bootstrap multilib build succeeded, and
"make check-cobol" worked.
I might have continued to press my case for the Big Diff, but becoming aware
of the diagnostic changes took some wind from my sails. Those changes
affected code both on the COBOL front end "island" and the rest of the GCC
system. The results would probably have been surprising outputs when
diagnostics were invoked. And we don't have much in the way of intentional
syntax errors in the existing testcases.
>
> > 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: 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)
> >
>
> --
> 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)
