On Mon, Mar 10, 2025 at 10:40 PM David Malcolm <dmalc...@redhat.com> wrote: > > On Mon, 2025-03-10 at 19:07 +0100, Richard Biener wrote: > > On Mon, Mar 10, 2025 at 5:34 PM Richard Biener > > <richard.guent...@gmail.com> wrote: > > > > > > On Sat, Mar 8, 2025 at 12:12 AM Robert Dubner <rdub...@symas.com> > > > wrote: > > > > > > > > Richard and Jakub, and everybody else who has offered advice and > > > > help > > > > > > > > I trust you realize that your message means Jim and I are > > > > reaching the top > > > > of a mountain we've been climbing for several years now. > > > > > > > > This is very exciting. > > > > > > > > Thank you. Thank you very much. > > > > > > During this I saw > > > > > > index 10a42cb1dd7..8e666618ef1 100644 > > > --- a/gcc/Makefile.in > > > +++ b/gcc/Makefile.in > > > ... > > > +# user-defined functions for GCOBOL > > > +udfdir = $(datadir)/gcobol/udf > > > .. > > > @@ -4031,7 +4035,9 @@ installdirs: > > > $(mkinstalldirs) $(DESTDIR)$(includedir) > > > $(mkinstalldirs) $(DESTDIR)$(infodir) > > > $(mkinstalldirs) $(DESTDIR)$(man1dir) > > > + $(mkinstalldirs) $(DESTDIR)$(man3dir) > > > $(mkinstalldirs) $(DESTDIR)$(man7dir) > > > + $(mkinstalldirs) $(DESTDIR)$(udfdir) > > > > > > while generating man3dir is probably OK when not configuring COBOL > > > the udfdir creation looks spurious and is repeated(?) in > > > cobol/Make-lang.in: > > > > > > cobol.install-common: installdirs > > > $(INSTALL_PROGRAM) gcobol$(exeext) > > > $(DESTDIR)$(bindir)/ > > > $(INSTALL_PROGRAM) cobol1$(exeext) > > > $(DESTDIR)$(libexecsubdir)/ > > > $(INSTALL) -m 755 $(srcdir)/cobol/gcobc > > > $(DESTDIR)$(bindir)/ > > > mkdir -p $(DESTDIR)$(datadir)/gcobol/udf > > > $(INSTALL_DATA) $(srcdir)/cobol/udf/* > > > $(DESTDIR)$(datadir)/gcobol/udf/ > > > > > > I don't know exactly what UDF is, but I'm going to prune the > > > gcc/Makefile.in > > > UDF changes. Does that analysis look OK? > > > > > > Building gcobol with GCC 7 shows > > > > > > gcc/cobol/except.cc:285:70: sorry, unimplemented: non-trivial > > > designated initializers not supported > > > > > > that needs to be sorted out (post-merge is OK). > > > > > > I'm preparing a branch with squashed merged from cobol-patched and > > > will push that later > > > today to a branch on gcc.gnu.org git and tomorrow from there to > > > trunk. > > > > So I've pushed refs/users/rguenth/heads/cobol which has picked all > > changes from the cobol-patched branch, re-ordered and squashed as > > shown by git log. The directories and ChangeLog prerequesites are > > already merged. I've kept two revs, one for libgcobol and one for > > gcc/cobol > > population and the toplevel configury/make is almost last to keep all > > revs > > building (without cobol). > > > > commit b7de2a002baf3cbdb42e0fdb14175637fb7c449a (HEAD -> cobol-merge, > > users/rguenth/cobol) > > For reference (for the curious), this can be seen in the web UI > here:https://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/users/rguenth/heads/cobol > > Sounds like it will go onto trunk tomorrow; thanks! > > I noticed that the copyright dates don't include 2025 in these files: > gcc/cobol/LICENSE > gcc/cobol/Make-lang.in > gcc/cobol/cobol1.cc > gcc/cobol/gcobolspec.cc > gcc/cobol/lang.opt
I've fixed those in my copy as well as the same issue in some libgcobol files. > FWIW gcc/cobol/lang.opt.urls has some D-specific things that look like > copy-and-paste cruft, but hopefully it won't cause problems. I guess we'll re-generate those eventually. I have bootstrapped the merge tree one with and once without cobol enabled on x86_64-unknown-linux-gnu and checked the installed contents. I have created a 'cobol' component in bugzilla. Robert, James - you want to create gcc.gnu.org/bugzilla accounts with the @gcc.gnu.org e-mail you are using for the git write access - that will get you bug edit privileges. I will open a bugreport tracking things to be done before the release. Pushed as r15-7942-g86c692c51c3569 Congrats! Richard. > > Dave >
