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. The messages are
> in a more or less logical order. We have:
>
> 1/14 4K dir: create gcc/cobol and libgcobol directories
> 2/14 8K pre: introduce ChangeLog files
> 3/14 80K bld: config and build machinery
> 4/14 376K hdr: header files
> 5/14 152K lex: lexer
> 6/14 476K par: parser
> 7/14 344K cbl: parser support
> 8/14 516K api: GENERIC interface
> 9/14 244K gen: GENERIC interface support
> 10/14 72K doc: man pages and GnuCOBOL emulation
> 11/14 84K lhd: libgcobol header files
> 12/14 320K lib: libgcobol support
> 13/14 372K lcc: libgcobol, main file
> 14/14 148K fun: libgcobol, intrinsic functions
>
> To slide under the 400 KB limit, the intrinsic functions now have
> their own patch. The configure files are removed, as is the Posix
> adapter framework.
>
> They are still against the master branch as of
>
> commit 3e08a4ecea27c54fda90e8f58641b1986ad957e1
> Date: Wed Feb 5 14:22:33 2025 -0700
>
> Our repository is
>
> https://gitlab.cobolworx.com/COBOLworx/gcc-cobol/
>
> using branch
>
> cobol-stage
>
> 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.
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.
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
During the build we write to
gcc/cobol/charmaps-dupe.cc
gcc/cobol/valconv-dupe.cc
but sources might reside on a R/O mounted volume and the above is undesirable
unless --enable-generated-files-in-srcdir.
Installing the result via make install DESTDIR=/foo I see both a
'gcobol' and a 'gcobc' program
being installed - is that intentional? I also see the gcobol.3
manpage reside directly in /foo/gcobol.3 rather
than in the expected /foo/usr/local/man/..
Installing of libgcobol fails for me:
make[4]: Entering directory
'/home/rguenther/obj2/x86_64-pc-linux-gnu/32/libgcobol'
Suppressing the 32-bit build because of lack of support for __int128 variables
/bin/sh ../../../../gcc-cobol/libgcobol/../mkinstalldirs
/home/rguenther/install/gcc-cobol/usr/local/lib
/bin/sh ./libtool --mode=install /usr/bin/install -c libgcobol.la
/home/rguenther/install/gcc-cobol/usr/local/lib;
libtool: install: `libgcobol.la' is not a valid libtool archive
libtool: install: Try `libtool --help --mode=install' for more information.
make[4]: *** [Makefile:246: install-libs] Error 1
make[4]: Leaving directory
'/home/rguenther/obj2/x86_64-pc-linux-gnu/32/libgcobol'
make[3]: *** [Makefile:301: multi-do] Error 1
so the suppression seems incomplete?
Compiling a Cobol Hello World results in
> ./install/gcc-cobol/usr/local/bin/gcobol t.cob
/usr/bin/ld: cannot find -lgcobol: No such file or directory
collect2: error: ld returned 1 exit status
possibly because the 64bit libcobol is installed in
/foo/usr/local/lib/ rather than .../lib64/ and
the former is not in the configured search directory.
Manually fixing this up results in a working binary!
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.
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.
Richard.
> We have endeavored to address all must-fix issues raised in Round 2.
>
> 1. Generated files use Autoconf 2.69
> 2. Commit message matches mail Subject: line
> 3. Various problems with Make-lang.in and cobol1.cc
> 4. s/assert(false)/gcc_unreachable()/g
> 5. Nixed range-based cases
> 6. Removed Posix adapter files & generated configure scripts
> 7. Explained memory-management engineering choice
> 8. s/option_id/option_zero/g, for clarity
> 9. GTY issues
> 10. Require only C++14 (not 17)
> 11. Moved #include <math.h>
> 12. Check regex buffer bounds outside gcc_assert
>
> Still to do (no particular order):
>
> 13. Try SARIF options
> 14. Do not compose messages (I18N).
> 15. Try valgrind for memory report
> 16. Review
> https://github.com/cooljeanius/legislation/blob/master/tech/21-R-mrg.htm.diff
> 17. Enumerated warnings in cobol/lang.opt.
> 18. texinfo update to describe gcobol
> 19. cross-compilation
>
> There are a few places where gcc_unreachable() is now followed by truly
> unreachable code. We will lop off those bits soon.
>
> This patchset still excludes tests. I will supply tests separately.
> Simplest I think is to use the NIST test suite, assuming the code and
> documentation pass legal muster.
>
> I have also prepared release notes for the www repository under
> separate cover.
>
> We remain hopeful the COBOL front end will be accepted into gcc-15.
>
> Thank you for your kind consideration of our work.
>
> --jkl
