On Mon, 24 Feb 2025 14:51:27 +0100
Richard Biener <richard.guent...@gmail.com> wrote:
> On Wed, Feb 19, 2025 at 12:38?AM James K. Lowden
> <jklow...@schemamania.org> 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.
> 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?
2. Is cobol-patched more useful to you right now as-is, or should I
regenerate it tomorrow?
> 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.
> 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.
Regards,
--jkl
