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. 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".
>
> 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.
Looking at 'cobol-stage' it contains more than the patches. Can you make
'cobol-patched' published (you can rebase that at will IMO) to make it easier
to look at the whole thing as proposed to merge at this point?
> 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.
Me too, I think we are at the point where merging and fixing issues that pop
up during the remains of stage4 is probably more efficient than repeated
re-spinning of the patches.
Can you clarify on the future development model for Cobol after it has
been merged? Is the cobolworx gitlab still going to be the primary
development location and changes should be made there and then merged
to the GCC side? If the gcc.gnu.org git repository isn't the primary
source this should be noted in the README (the situation might differ
for libgcobol and gcc/cobol I guess).
The most important part for GCC 15 will be documentation to get
user expectancy right. Having a minimal harness in GCCs testsuite
is critical - I'd expect a gcc/testsuite/gcobol.dg/dg.exp supporting
execution tests. I assume Cobol has a way to exit OK or fatally
and this should be distinguished as testsuite PASS or FAIL. I'm not
sure if /* { dg-... } */ directive support is easy or desirable (well,
desirable for sure). I'd be happy with a setup like the old
gcc.c-torture/{execute,compile}. Possibly tcl/shell wrapping
around the NIST tests (even if not included in the GCC tree,
running that by unpacking it in gcc/testsuite/gcobol/nist would be nice).
Thanks,
Richard.
> Thank you for your kind consideration of our work.
>
> --jkl
