On Mon, Mar 10, 2025 at 7:07 PM James K. Lowden
<jklow...@schemamania.org> wrote:
>
> On Mon, 10 Mar 2025 17:34:40 +0100
> Richard Biener <richard.guent...@gmail.com> wrote:
>
> > 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?
>
> We need the UDF directory, but it's enough to create it jjst once, and only
> for cobol.
>
> UDF stands for "user defined function". COBOL, which used to define
> only "intrinsic functions", supplied with the compiler (similar to a
> standard library), and otherwise had no functions. For the last 20
> years or so, COBOL has also allowed the user to define functions himself
> in COBOL, and invoke them the same way intrinsic functions have always
> been invoked.
>
> Because their use is syntactically identical, we supply UDFs to
> emulate functions that other COBOL compiler supply as non-standard
> intrinstic functions. So far, that set is small; we supply only one
> UDF to date:
>
> $ ls /tmp/build-try/share/gcobol/udf/
> stored-char-length.cbl
>
> I think you're suggesting it would be better *not* to create the udf
> directory in gcc/Makefile.in, since that would leave an empty directory
> unless the user built gcobol.
>
> This patch seems to work, and uses mkinstalldirs instead of "mkdir -p":
>
> [snip]
> diff --git a/gcc/cobol/Make-lang.in b/gcc/cobol/Make-lang.in
> index de967e3d78e..7447118ab3e 100644
> --- a/gcc/cobol/Make-lang.in
> +++ b/gcc/cobol/Make-lang.in
> @@ -281,7 +281,7 @@ 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
> + $(mkinstalldirs) $(DESTDIR)$(datadir)/gcobol/udf
> $(INSTALL_DATA) $(srcdir)/cobol/udf/*
> $(DESTDIR)$(datadir)/gcobol/udf/
>
> cobol.install-man: installdirs
> @@ -291,7 +291,6 @@ cobol.install-man: installdirs
> cobol.install-info:
>
> cobol.install-pdf: installdirs gcobol.pdf gcobol-io.pdf
> - mkdir -p $(DESTDIR)$(datadir)/gcobol/pdf
> $(INSTALL_DATA) gcobol.pdf gcobol-io.pdf $(DESTDIR)$(pdfdir)/
>
> cobol.install-plugin:
> [pins]
>
> That leaves the creation of all directories up to Makefile.in, except for the
> udf directory, which cobol creates for itself if configured.
>
> > Building gcobol with GCC 7 shows
> >
> > gcc/cobol/except.cc:285:70: sorry, unimplemented: non-trivial
> > designated initializers not supported
>
> I'm surprised that's the only occurence! For example, in
> gcc/cobol/symbols.cc,
>
> static symbol_elem_t
> elementize( cbl_field_t& field ) {
> symbol_elem_t elem = { .type = SymField, .elem = {.field = field} };
> return elem;
> }
>
> What is the right answer? Designated initializers are part of C99, but
> weren't added to C++ until C++20
> (https://en.cppreference.com/w/cpp/language/initialization). Strictly
> speaking, we should remove all of them, because our baseline is C++14.
Yes.
> > 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.
>
> Excellent, excellent news. Thank you for your patience and guidance.
>
> Regards,
>
> --jkl
