On Tue, Feb 25, 2025 at 2:48 AM James K. Lowden
<[email protected]> wrote:
>
> On Mon, 24 Feb 2025 14:51:27 +0100
> Richard Biener <[email protected]> wrote:
>
> > On Wed, Feb 19, 2025 at 12:38?AM James K. Lowden
> > <[email protected]> wrote:
> > >
> > > The following 14 patches constitute 105,720 lines of code in 83
> > > files to build and document the COBOL front end.
> [...]
> > > I tested these patches using "git apply" to an unpublished branch
> > > "cobol-patched".
> >
> > I have now built the compiler from the (now published) cobol-patched
> > branch.
>
> I rebuilt cobol-patched today. It now includes changes to gcc/doc/, and
> a new gcc/Makefile.in (previously omitted because I thought it was
> generated). That deals with some but not all the issues below.
>
> > On x86_64-linux and noticed the following issues:
> >
> > The toplevel configure script on the branch wasn't re-generated (duh),
> > so it isn't
> > ready for use.
>
> Since we're not mailing patches, cobol-patched is now built by applying
> patches that include the configure scripts.
good.
> > gcc-cobol/gcc/cobol/parse.y:1361.10-16: error: require bison 3.5.1,
> > but have 3.0.4
> > %require "3.5.1" // 3.8.2 also works, but not 3.8.0
> > ^^^^^^^
> >
> > this requirement isn't documented, neither is a version requirement
> > for flex. The
> > place for this is in gcc/doc/install.texi
>
> I think you will find the updated .texi files comprehesively (!)
> reflect the presence of gcobol and its requirements.
>
> There is a hitch. The patches are against master branch as of 5
> February. Many changes occurred in the time since. Now that I know
> that, I *expect* a conflict extravaganza as we pull that together.
>
> Best IMO is for us to update our repository, i.e. to merge master into
> our master+cobol, then to cobol-stage, then to cobol-patched.
> Questions:
>
> 1. How often should we do that, would you say?
As it suits you, best when you think you fixed an important set of issues.
My idea is that cobol-patched should reflect the tree as if it were
post merge to GCC master (so we could basically merge from that
branch instead of re-applying patches).
> 2. Is cobol-patched more useful to you right now as-is, or should I
> regenerate it tomorrow?
It was useful as it is for discovering the issues I reported. I will re-try
once you declare them fixed.
> > During the build we write to
> >
> > gcc/cobol/charmaps-dupe.cc
> > gcc/cobol/valconv-dupe.cc
>
> Not yet fixed. Top of the list, now.
>
> > Installing the result via make install DESTDIR=/foo I see both a
> > 'gcobol' and a 'gcobc' program
> > being installed - is that intentional?
>
> Yes, as explained prior, gcobc is an emulation script.
>
> > I also see the gcobol.3
> > manpage reside directly in /foo/gcobol.3 rather
> > than in the expected /foo/usr/local/man/..
>
> gcc/Makefile.in didn't appear in the patches. I now have installed:
>
> $ find /usr/local/cobol-patched/ -name '*cobol*'
> /usr/local/cobol-patched/
> /usr/local/cobol-patched/libexec/gcc/x86_64-pc-linux-gnu/15.0.1/cobol1
> /usr/local/cobol-patched/bin/gcobol
> /usr/local/cobol-patched/share/man/man1/gcobol.1
> /usr/local/cobol-patched/share/man/man3/gcobol.3
> /usr/local/cobol-patched/share/gcobol
>
> > Installing of libgcobol fails for me:
>
> Hmm, a little worse for me. As you see above, the installed cobol files
> don't include the library. This was from "make install". Checking.
That's what happened to me before I re-generated the toplevel configure,
it didn't build libgcobol at all.
> > so the suppression seems incomplete?
>
> Or too complete. :-/
>
> > Doing
> >
> > > ./install/gcc-cobol/usr/local/bin/gcobol t.cob -m32
> >
> > only fails during linking as we do build a 32bit binary but do not
> > find (the not built) 32bit runtime. I suspect when writing a program
> > that would need 128bit integer or float we'd eventually ICE.
>
> I think the cobol-patched you were using was missing our patch of
> Friday. Our intention is to prevent any 32-bit binary from being
> generated, in addition to not attempting to build the library.
>
> But we're not there yet. On my system, configured as
>
> $ ../configure --prefix=/usr/local/gcc-cobol --disable-bootstrap
> --disable-generated-files-in-srcdir --disable-multilib
> --enable-checking --enable-languages=c,cobol
>
> I see failure to link [eliding the "skipping" messages]:
>
> $ gcobol -oo -ffixed-form -m32 gcc/cobol/nist/NC/NC101A.cbl
> /usr/bin/ld: cannot find -lgcobol: No such file or directory
> /usr/bin/ld: cannot find -lstdc++: No such file or directory
> /usr/bin/ld: cannot find -lgcc: No such file or directory
> /usr/bin/ld: cannot find -lgcc_s: No such file or directory
>
> If compiled with -c,
>
> $ gcobol -oo -c -m32 -ffixed-form ../parser/gcc/cobol/nist/NC/NC101A.cbl
> $ file o o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not
> stripped
>
> Not our intended result. :-( But, fixable.
>
> > The cobol frontend should attempt to intercept the selection of a
> > not supported multilib (but don't ask me how) and gracefully exit,
> > possibly calling
> >
> > sorry ("selected multilib not available for Cobol");
> >
> > or so. There's the LANG_HOOKS_POST_OPTIONS langhook which
> > might be a place to do this. The way to check is likely whether
> > a mode for __int128 exists and is supported. The C fronted does
> >
> > if (targetm.scalar_mode_supported_p (TImode))
> >
> > it also checks float128_type_node, but I didn't find who initializes
> > that.
>
> Thank you for the pointer. It's late here today. I will try that in
> the morning if Bob hasn't already solved it by then.
Thanks,
Richard.
> Regards,
>
> --jkl
>
