[v3] Simple cobol.dg testsuite

  The following adds a simple cobol.dg test harness, based on gfortran.dg.
It's invoked by make check-cobol, has a single test that should pass.

Running /home/rguenther/src/gcc/gcc/testsuite/cobol.dg/dg.exp ...
FAIL: cobol.dg/pass.cob   -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions  (test for excess errors)

                === cobol Summary ===

 # of expected passes            10
 # of unexpected failures        1
 # of unresolved testcases       1

OK?

Thanks,
Richard.

gcc/cobol/
	* Make-lang.in (lang_checks): Add check-cobol.

gcc/testsuite/
	* lib/cobol-dg.exp: New, based on gfortran-dg.exp.
	* lib/cobol.exp: New, based on gfortran.exp.
	* cobol.dg/dg.exp: New.
	* cobol.dg/pass.cob: New test.
---
 gcc/cobol/Make-lang.in          |   2 +
 gcc/testsuite/cobol.dg/dg.exp   |  41 +++++
 gcc/testsuite/cobol.dg/pass.cob |   6 +
 gcc/testsuite/lib/cobol-dg.exp  | 168 +++++++++++++++++++
 gcc/testsuite/lib/cobol.exp     | 282 ++++++++++++++++++++++++++++++++
 5 files changed, 499 insertions(+)
 create mode 100644 gcc/testsuite/cobol.dg/dg.exp
 create mode 100644 gcc/testsuite/cobol.dg/pass.cob
 create mode 100644 gcc/testsuite/lib/cobol-dg.exp
 create mode 100644 gcc/testsuite/lib/cobol.exp
  

On Tue, Mar 11, 2025 at 01:24:12PM +0100, Richard Biener wrote:
> The following adds a simple cobol.dg test harness, based on gfortran.dg.
> It's invoked by make check-cobol, has a single test that should pass.
> 
> Running /home/rguenther/src/gcc/gcc/testsuite/cobol.dg/dg.exp ...
> FAIL: cobol.dg/pass.cob   -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions  (test for excess errors)
> 
>                 === cobol Summary ===
> 
>  # of expected passes            10
>  # of unexpected failures        1
>  # of unresolved testcases       1
> 
> OK?
> 
> Thanks,
> Richard.
> 
> gcc/cobol/
> 	* Make-lang.in (lang_checks): Add check-cobol.
> 
> gcc/testsuite/
> 	* lib/cobol-dg.exp: New, based on gfortran-dg.exp.
> 	* lib/cobol.exp: New, based on gfortran.exp.
> 	* cobol.dg/dg.exp: New.
> 	* cobol.dg/pass.cob: New test.

> +    # gcc's default is to print the caret and source code, but
> +    # most test cases implicitly use the flag -fno-diagnostics-show-caret
> +    # to disable caret (and source code) printing.
> +    #
> +    # However, a few test cases override this back to the default by
> +    # explicily supplying "-fdiagnostics-show-caret", so that we can have
> +    # test coverage for caret/source code printing.
> +    #
> +    # cobol error messages with caret-printing look like this:
> +    #     [name]:[locus]:
> +    #
> +    #        some code
> +    #              1
> +    #     Error: Some error at (1)
> +    # or
> +    #     [name]:[locus]:
> +    #
> +    #       some code
> +    #              1
> +    #     [name]:[locus2]:
> +    #
> +    #       some other code
> +    #         2
> +    #     Error: Some error at (1) and (2)
> +    # or
> +    #     [name]:[locus]:
> +    #
> +    #       some code and some more code
> +    #              1       2
> +    #     Error: Some error at (1) and (2)
> +    #
> +    # If this is such a test case, skip the rest of this function, so
> +    # that the test case can explicitly verify the output that it expects.
> +    if {[string first "-fdiagnostics-show-caret" $extra_tool_flags] >= 0} {
> +	return [list $comp_output $output_file]
> +    }
> +
> +    # Otherwise, caret-printing is disabled.
> +    # cobol errors with caret-printing disabled look like this:
> +    #     [name]:[locus]: Error: Some error
> +    # or
> +    #     [name]:[locus]: Error: (1)
> +    #     [name]:[locus2]: Error: Some error at (1) and (2)
> +    #
> +    # Where [locus] is either [line] or [line].[column] or
> +    # [line].[column]-[column] .
> +    #
> +    # We collapse these to look like:
> +    #  [name]:[line]:[column]: Error: Some error at (1) and (2)
> +    # or
> +    #  [name]:[line]:[column]: Error: Some error at (1) and (2)
> +    #  [name]:[line2]:[column]: Error: Some error at (1) and (2)
> +    #
> +    # Note that these regexps only make sense in the combinations used below.
> +    # Note also that is imperative that we first deal with the form with
> +    # two loci.
> +    set locus_regexp "(\[^\n\]+:\[0-9\]+)\[\.:\](\[0-9\]+)(-\[0-9\]+)?:\n\n\[^\n\]+\n\[^\n\]+\n"
> +    set diag_regexp "(\[^\n\]+)\n"
> +
> +    # We proceed in steps:
> +
> +    # 1. We add first a column number if none exists.
> +    # (Some cobol diagnostics have the locus after Warning|Error)
> +    set colnum_regexp "(^|\n)(Warning: |Error: )?(\[^:\n\]+:\[0-9\]+):(\[ \n\])"
> +    regsub -all $colnum_regexp $comp_output "\\1\\3:0:\\4\\2" comp_output
> +    verbose "comput_output0:\n$comp_output"
> +
> +    # 2. We deal with the form with two different locus lines,
> +    set two_loci "(^|\n)$locus_regexp$locus_regexp$diag_regexp"
> +    regsub -all $two_loci $comp_output "\\1\\2:\\3: \\8\n\\5\:\\6: \\8\n" comp_output
> +    verbose "comput_output1:\n$comp_output"
> +
> +    set locus_prefix "(\[^:\n\]+:\[0-9\]+:\[0-9\]+: )(Warning: |Error: )"
> +    set two_loci2 "(^|\n)$locus_prefix\\(1\\)\n$locus_prefix$diag_regexp"
> +    regsub -all $two_loci2 $comp_output "\\1\\2\\3\\6\n\\4\\5\\6\n" comp_output
> +    verbose "comput_output2:\n$comp_output"
> +
> +    # 3. then with the form with only one locus line.
> +    set single_locus "(^|\n)$locus_regexp$diag_regexp"
> +    regsub -all $single_locus $comp_output "\\1\\2:\\3: \\5\n" comp_output
> +    verbose "comput_output3:\n$comp_output"
> +
> +    # 4. Add a line number if none exists
> +    regsub -all "(^|\n)(Warning: |Error: )" $comp_output "\\1:0:0: \\2" comp_output
> +    verbose "comput_output4:\n$comp_output"
> +    return [list $comp_output $output_file]

Looking at pretty much all of the above, it seems very Fortran specific with
its weird diagnostic output (capital Warning:/Error:, the (1) and (2) in
the diagnostics with later printing of those lines and the like.
Unless cobol1 does it the same, this should be replaced with what is done
for other FEs (likely almost nothing).

Otherwise LGTM.

	Jakub
  

On Tue, 11 Mar 2025, Jakub Jelinek wrote:

> On Tue, Mar 11, 2025 at 01:24:12PM +0100, Richard Biener wrote:
> > The following adds a simple cobol.dg test harness, based on gfortran.dg.
> > It's invoked by make check-cobol, has a single test that should pass.
> > 
> > Running /home/rguenther/src/gcc/gcc/testsuite/cobol.dg/dg.exp ...
> > FAIL: cobol.dg/pass.cob   -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions  (test for excess errors)
> > 
> >                 === cobol Summary ===
> > 
> >  # of expected passes            10
> >  # of unexpected failures        1
> >  # of unresolved testcases       1
> > 
> > OK?
> > 
> > Thanks,
> > Richard.
> > 
> > gcc/cobol/
> > 	* Make-lang.in (lang_checks): Add check-cobol.
> > 
> > gcc/testsuite/
> > 	* lib/cobol-dg.exp: New, based on gfortran-dg.exp.
> > 	* lib/cobol.exp: New, based on gfortran.exp.
> > 	* cobol.dg/dg.exp: New.
> > 	* cobol.dg/pass.cob: New test.
> 
> > +    # gcc's default is to print the caret and source code, but
> > +    # most test cases implicitly use the flag -fno-diagnostics-show-caret
> > +    # to disable caret (and source code) printing.
> > +    #
> > +    # However, a few test cases override this back to the default by
> > +    # explicily supplying "-fdiagnostics-show-caret", so that we can have
> > +    # test coverage for caret/source code printing.
> > +    #
> > +    # cobol error messages with caret-printing look like this:
> > +    #     [name]:[locus]:
> > +    #
> > +    #        some code
> > +    #              1
> > +    #     Error: Some error at (1)
> > +    # or
> > +    #     [name]:[locus]:
> > +    #
> > +    #       some code
> > +    #              1
> > +    #     [name]:[locus2]:
> > +    #
> > +    #       some other code
> > +    #         2
> > +    #     Error: Some error at (1) and (2)
> > +    # or
> > +    #     [name]:[locus]:
> > +    #
> > +    #       some code and some more code
> > +    #              1       2
> > +    #     Error: Some error at (1) and (2)
> > +    #
> > +    # If this is such a test case, skip the rest of this function, so
> > +    # that the test case can explicitly verify the output that it expects.
> > +    if {[string first "-fdiagnostics-show-caret" $extra_tool_flags] >= 0} {
> > +	return [list $comp_output $output_file]
> > +    }
> > +
> > +    # Otherwise, caret-printing is disabled.
> > +    # cobol errors with caret-printing disabled look like this:
> > +    #     [name]:[locus]: Error: Some error
> > +    # or
> > +    #     [name]:[locus]: Error: (1)
> > +    #     [name]:[locus2]: Error: Some error at (1) and (2)
> > +    #
> > +    # Where [locus] is either [line] or [line].[column] or
> > +    # [line].[column]-[column] .
> > +    #
> > +    # We collapse these to look like:
> > +    #  [name]:[line]:[column]: Error: Some error at (1) and (2)
> > +    # or
> > +    #  [name]:[line]:[column]: Error: Some error at (1) and (2)
> > +    #  [name]:[line2]:[column]: Error: Some error at (1) and (2)
> > +    #
> > +    # Note that these regexps only make sense in the combinations used below.
> > +    # Note also that is imperative that we first deal with the form with
> > +    # two loci.
> > +    set locus_regexp "(\[^\n\]+:\[0-9\]+)\[\.:\](\[0-9\]+)(-\[0-9\]+)?:\n\n\[^\n\]+\n\[^\n\]+\n"
> > +    set diag_regexp "(\[^\n\]+)\n"
> > +
> > +    # We proceed in steps:
> > +
> > +    # 1. We add first a column number if none exists.
> > +    # (Some cobol diagnostics have the locus after Warning|Error)
> > +    set colnum_regexp "(^|\n)(Warning: |Error: )?(\[^:\n\]+:\[0-9\]+):(\[ \n\])"
> > +    regsub -all $colnum_regexp $comp_output "\\1\\3:0:\\4\\2" comp_output
> > +    verbose "comput_output0:\n$comp_output"
> > +
> > +    # 2. We deal with the form with two different locus lines,
> > +    set two_loci "(^|\n)$locus_regexp$locus_regexp$diag_regexp"
> > +    regsub -all $two_loci $comp_output "\\1\\2:\\3: \\8\n\\5\:\\6: \\8\n" comp_output
> > +    verbose "comput_output1:\n$comp_output"
> > +
> > +    set locus_prefix "(\[^:\n\]+:\[0-9\]+:\[0-9\]+: )(Warning: |Error: )"
> > +    set two_loci2 "(^|\n)$locus_prefix\\(1\\)\n$locus_prefix$diag_regexp"
> > +    regsub -all $two_loci2 $comp_output "\\1\\2\\3\\6\n\\4\\5\\6\n" comp_output
> > +    verbose "comput_output2:\n$comp_output"
> > +
> > +    # 3. then with the form with only one locus line.
> > +    set single_locus "(^|\n)$locus_regexp$diag_regexp"
> > +    regsub -all $single_locus $comp_output "\\1\\2:\\3: \\5\n" comp_output
> > +    verbose "comput_output3:\n$comp_output"
> > +
> > +    # 4. Add a line number if none exists
> > +    regsub -all "(^|\n)(Warning: |Error: )" $comp_output "\\1:0:0: \\2" comp_output
> > +    verbose "comput_output4:\n$comp_output"
> > +    return [list $comp_output $output_file]
> 
> Looking at pretty much all of the above, it seems very Fortran specific with
> its weird diagnostic output (capital Warning:/Error:, the (1) and (2) in
> the diagnostics with later printing of those lines and the like.
> Unless cobol1 does it the same, this should be replaced with what is done
> for other FEs (likely almost nothing).

OK, I've done that and amended the set of testcases with one
exercising dg-error.  I had to prune the sprious

cobol1: error: failed compiling t.cob

message we emit.  I don't see any warnings emitted from the frontend
and wasn't able to create a Cobol program where the middle-end 
would emit one.

I'll wait for an ACK from the Cobol folks before pushing.

Thanks,
Richard.


From 99afbfdc7c45727354bdc37ce4c6451613a9aeb7 Mon Sep 17 00:00:00 2001
From: Richard Biener <rguenther@suse.de>
Date: Tue, 11 Mar 2025 09:39:06 +0100
Subject: [PATCH] Simple cobol.dg testsuite
To: gcc-patches@gcc.gnu.org

The following adds a simple cobol.dg test harness, based on gfortran.dg.
It's invoked by make check-cobol, has two tests, one execution test and
one test exercising dg-error.

Running /home/rguenther/src/gcc/gcc/testsuite/cobol.dg/dg.exp ...
FAIL: cobol.dg/pass.cob   -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions  (test for excess errors)

                === cobol Summary ===

 # of expected passes            12
 # of unexpected failures        1
 # of unresolved testcases       1

gcc/cobol/
	* Make-lang.in (lang_checks): Add check-cobol.

gcc/testsuite/
	* lib/cobol-dg.exp: New, based on gfortran-dg.exp.
	* lib/cobol.exp: New, based on gfortran.exp.
	* cobol.dg/dg.exp: New.
	* cobol.dg/pass.cob: New test.
	* cobol.dg/error-1.cob: Likewise.
---
 gcc/cobol/Make-lang.in             |   2 +
 gcc/testsuite/cobol.dg/dg.exp      |  41 +++++
 gcc/testsuite/cobol.dg/error-1.cob |   9 +
 gcc/testsuite/cobol.dg/pass.cob    |   6 +
 gcc/testsuite/lib/cobol-dg.exp     |  85 +++++++++
 gcc/testsuite/lib/cobol.exp        | 282 +++++++++++++++++++++++++++++
 6 files changed, 425 insertions(+)
 create mode 100644 gcc/testsuite/cobol.dg/dg.exp
 create mode 100644 gcc/testsuite/cobol.dg/error-1.cob
 create mode 100644 gcc/testsuite/cobol.dg/pass.cob
 create mode 100644 gcc/testsuite/lib/cobol-dg.exp
 create mode 100644 gcc/testsuite/lib/cobol.exp

diff --git a/gcc/cobol/Make-lang.in b/gcc/cobol/Make-lang.in
index a4e005ac2bd..cbb31d63c30 100644
--- a/gcc/cobol/Make-lang.in
+++ b/gcc/cobol/Make-lang.in
@@ -367,3 +367,5 @@ cobol.stagefeedback: stagefeedback-start
 	-mv cobol/*$(objext) stagefeedback/cobol
 
 selftest-cobol:
+
+lang_checks += check-cobol
diff --git a/gcc/testsuite/cobol.dg/dg.exp b/gcc/testsuite/cobol.dg/dg.exp
new file mode 100644
index 00000000000..c81634ac817
--- /dev/null
+++ b/gcc/testsuite/cobol.dg/dg.exp
@@ -0,0 +1,41 @@
+#   Copyright (C) 2004-2025 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+# 
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+# 
+# You should have received a copy of the GNU General Public License
+# along with GCC; see the file COPYING3.  If not see
+# <http://www.gnu.org/licenses/>.
+
+# GCC testsuite that uses the `dg.exp' driver.
+
+# Load support procs.
+load_lib cobol-dg.exp
+
+# If a testcase doesn't have special options, use these.
+global DEFAULT_COBFLAGS
+if ![info exists DEFAULT_COBFLAGS] then {
+    set DEFAULT_COBFLAGS " "
+}
+
+# Initialize `dg'.
+dg-init
+
+global cobol_test_path
+set cobol_test_path $srcdir/$subdir
+
+set all_flags $DEFAULT_COBFLAGS
+
+# Main loop.
+cobol-dg-runtest [lsort \
+       [glob -nocomplain $srcdir/$subdir/*.cob ] ] "" $all_flags
+
+# All done.
+dg-finish
diff --git a/gcc/testsuite/cobol.dg/error-1.cob b/gcc/testsuite/cobol.dg/error-1.cob
new file mode 100644
index 00000000000..9e51a90b841
--- /dev/null
+++ b/gcc/testsuite/cobol.dg/error-1.cob
@@ -0,0 +1,9 @@
+*> { dg-do compile }
+IDENTIFICATION DIVISION.
+PROGRAM-ID. error-1.
+ENVIRONMENT DIVISION.
+DATA DIVISION.
+    WORKING-STORAGE SECTION.
+    02 VAR PIC S9(3) VALUE 1. *> { dg-error "not part of" }
+PROCEDURE DIVISION.
+    STOP RUN.
diff --git a/gcc/testsuite/cobol.dg/pass.cob b/gcc/testsuite/cobol.dg/pass.cob
new file mode 100644
index 00000000000..47cfd2bb09a
--- /dev/null
+++ b/gcc/testsuite/cobol.dg/pass.cob
@@ -0,0 +1,6 @@
+*> { dg-do run }
+IDENTIFICATION DIVISION.
+PROGRAM-ID. pass.
+ENVIRONMENT DIVISION.
+PROCEDURE DIVISION.
+    STOP RUN.
diff --git a/gcc/testsuite/lib/cobol-dg.exp b/gcc/testsuite/lib/cobol-dg.exp
new file mode 100644
index 00000000000..51df13df19f
--- /dev/null
+++ b/gcc/testsuite/lib/cobol-dg.exp
@@ -0,0 +1,85 @@
+#   Copyright (C) 2004-2025 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+# 
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+# 
+# You should have received a copy of the GNU General Public License
+# along with GCC; see the file COPYING3.  If not see
+# <http://www.gnu.org/licenses/>.
+
+load_lib gcc-dg.exp
+load_lib torture-options.exp
+
+# Define cobol callbacks for dg.exp.
+
+proc cobol-dg-test { prog do_what extra_tool_flags } {
+    set result \
+	[gcc-dg-test-1 cobol_target_compile $prog $do_what $extra_tool_flags]
+    
+    set comp_output [lindex $result 0]
+    set output_file [lindex $result 1]
+
+    return [list $comp_output $output_file]
+}
+
+proc cobol-dg-prune { system text } {
+    # cobol prints an extra stray error at the end when compilation fails
+    regsub -all "(^|\n)cobol1: error: failed compiling \[^\n\]*" $text "" text
+    return [gcc-dg-prune $system $text]
+}
+
+# Utility routines.
+
+# Modified dg-runtest that can cycle through a list of optimization options
+# as c-torture does.
+proc cobol-dg-runtest { testcases flags default-extra-flags } {
+    global runtests
+    global torture_with_loops
+
+    # Some callers initialize torture testing themselves; don't override those.
+    set existing_torture_init [torture-init-done]
+    if { $existing_torture_init == 0 } {
+	torture-init
+    }
+    # Some callers set torture options themselves; don't override those.
+    set existing_torture_options [torture-options-exist]
+    if { $existing_torture_options == 0 } {
+	global DG_TORTURE_OPTIONS
+	set-torture-options $DG_TORTURE_OPTIONS
+    }
+    dump-torture-options
+
+    foreach test $testcases {
+	# If we're only testing specific files and this isn't one of
+	# them, skip it.
+	if ![runtest_file_p $runtests $test] {
+	    continue
+        }
+
+	# look if this is dg-do run test, in which case
+	# we cycle through the option list, otherwise we don't
+	if [expr [search_for $test "dg-do run"]] {
+	    set option_list $torture_with_loops
+	} else {
+	    set option_list [list { -O } ]
+	}
+
+	set nshort [file tail [file dirname $test]]/[file tail $test]
+
+	foreach flags_t $option_list {
+	    verbose "Testing $nshort, $flags $flags_t" 1
+	    dg-test $test "$flags $flags_t" ${default-extra-flags}
+	}
+    }
+
+    if { $existing_torture_init == 0 } {
+	torture-finish
+    }
+}
diff --git a/gcc/testsuite/lib/cobol.exp b/gcc/testsuite/lib/cobol.exp
new file mode 100644
index 00000000000..65687bc64ae
--- /dev/null
+++ b/gcc/testsuite/lib/cobol.exp
@@ -0,0 +1,282 @@
+# Copyright (C) 2003-2025 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with GCC; see the file COPYING3.  If not see
+# <http://www.gnu.org/licenses/>.
+
+#
+# cobol support library routines
+#
+load_lib prune.exp
+load_lib gcc-defs.exp
+load_lib timeout.exp
+load_lib target-libpath.exp
+load_lib target-supports.exp
+
+#
+# COBOL_UNDER_TEST is the compiler under test.
+#
+
+
+set gpp_compile_options ""
+
+
+#
+# cobol_version -- extract and print the version number of the compiler
+#
+
+proc cobol_version { } {
+    global COBOL_UNDER_TEST
+    
+    cobol_init
+
+    # ignore any arguments after the command
+    set compiler [lindex $COBOL_UNDER_TEST 0]
+    
+    # verify that the compiler exists
+    if { [is_remote host] || [which $compiler] != 0 } then {
+	set tmp [remote_exec host "$compiler -v"]
+	set status [lindex $tmp 0]
+	set output [lindex $tmp 1]
+	regexp " version \[^\n\r\]*" $output version
+	if { $status == 0 && [info exists version] } then {
+	    if [is_remote host] {
+		clone_output "$compiler $version\n"
+	    } else {
+		clone_output "[which $compiler] $version\n"
+	    }
+	} else {
+	    clone_output "Couldn't determine version of [which $compiler]\n"
+	}
+    } else {
+	# compiler does not exist (this should have already been detected)
+	warning "$compiler does not exist"
+    }
+}
+
+#
+# cobol_link_flags -- provide new version of cobol_link_flags
+# (originally from libgloss.exp) which knows about the gcc tree structure
+#
+
+proc cobol_link_flags { paths } {
+    global srcdir
+    global ld_library_path
+    global COBOL_UNDER_TEST
+    global shlib_ext
+    global ENABLE_DARWIN_AT_RPATH
+
+    set gccpath ${paths}
+    set libio_dir ""
+    set flags ""
+    set ld_library_path "."
+    set shlib_ext [get_shlib_extension]
+    verbose "shared lib extension: $shlib_ext"
+
+    # We need to add options to locate libgfortran and the dependent libs
+    # libquadmath (supporting REAL*16) and libatomic (supporting operations
+    # used by coarrays).  Usually '-L' options are added to point to the
+    # relevant directories for the uninstalled libraries.
+
+    # In cases where libraries are available as both shared and convenience
+    # some additional checks are made.
+
+    # For some targets -static-xxxx options are handled by specs substitution
+    # and need a '-B' option rather than '-L'.  For Darwin, when embedded
+    # runpaths are in use (the default for all versions after macOS 10.11),
+    # '-B' is also needed to provide the runpath.
+    # When '-B' is used, this results in a '-L' for each path that exists (so
+    # that appending a '-L' as well is a needless duplicate).  There are also
+    # cases where tools warn for duplicates, leading to spurious fails.
+    # Therefore the objective of the code below is to add just one '-L' or
+    # '-B' for each of the libraries.
+
+    set target_wants_B_option 0
+    if { [istarget *-*-darwin9* ] || [istarget *-*-darwin\[12\]* ] } {
+      set target_wants_B_option 1
+    }
+
+    if { $gccpath != "" } {
+      if [file exists "${gccpath}/libgcobol/libgcobol.a"] {
+          append flags "-L${gccpath}/libgcobol"
+      }
+      if { [file exists "${gccpath}/libgcobol/.libs/libgcobol.a"] ||
+	 [file exists "${gccpath}/libgobol/.libs/libgcobol.${shlib_ext}"] } {
+	if { $target_wants_B_option } {
+          append flags "-B${gccpath}/libgcobol/.libs "
+	} else {
+          append flags "-L${gccpath}/libgcobol/.libs "
+	}
+	append ld_library_path ":${gccpath}/libgcobol/.libs"
+      }
+
+      if [file exists "${gccpath}/libiberty/libiberty.a"] {
+          append flags "-L${gccpath}/libiberty "
+      }
+      append ld_library_path \
+	[gcc-set-multilib-library-path $COBOL_UNDER_TEST ]
+    }
+
+    set_ld_library_path_env_vars
+
+    return "$flags"
+}
+
+#
+# cobol_init -- called at the start of each subdir of tests
+#
+
+proc cobol_init { args } {
+    global subdir
+    global gpp_initialized
+    global base_dir
+    global tmpdir
+    global libdir
+    global gluefile wrap_flags
+    global objdir srcdir
+    global ALWAYS_COBOLFLAGS
+    global TOOL_EXECUTABLE TOOL_OPTIONS
+    global COBOL_UNDER_TEST
+    global TESTING_IN_BUILD_TREE
+    global gcc_warning_prefix
+    global gcc_error_prefix
+    global TEST_ALWAYS_FLAGS
+    global cobol_init_set_COBOL_UNDER_TEST
+
+    # We set LC_ALL and LANG to C so that we get the same error messages as expected.
+    setenv LC_ALL C
+    setenv LANG C
+
+    set gcc_warning_prefix "\[Ww\]arning:"
+    set gcc_error_prefix "(Fatal )?\[Ee\]rror:"
+
+    # Many hosts now default to a non-ASCII C locale, however, so
+    # they can set a charset encoding here if they need.
+    if { [ishost "*-*-cygwin*"] } {
+      setenv LC_ALL C.ASCII
+      setenv LANG C.ASCII
+    }
+
+    # COBOL_UNDER_TEST as set below contains $specpath, which depends on
+    # the used multilib config. Thus, its value may need to be reset;
+    # that's tracked via gfortran_init_set_COBOL_UNDER_TEST.
+    if { ![info exists COBOL_UNDER_TEST]
+	 || [info exists cobol_init_set_COBOL_UNDER_TEST] } then {
+	if [info exists TOOL_EXECUTABLE] {
+	    set COBOL_UNDER_TEST $TOOL_EXECUTABLE
+	} else {
+	    if { [is_remote host] || ! [info exists TESTING_IN_BUILD_TREE] } {
+		set COBOL_UNDER_TEST [transform gcobol]
+	    } else {
+		if [info exists TOOL_OPTIONS] {
+	            set specpath [get_multilibs ${TOOL_OPTIONS}]
+		} else {
+		    set specpath [get_multilibs]
+		}
+		set cobol_init_set_COBOL_UNDER_TEST 1
+		set COBOL_UNDER_TEST [findfile $base_dir/../../gcobol "$base_dir/../../gcobol -B$base_dir/../../ -B$specpath/libgcobol/.libs" [findfile $base_dir/gcobol "$base_dir/gcobol -B$base_dir/" [transform gcobol]]]
+	    }
+	}
+    }
+
+    if ![is_remote host] {
+	if { [which $COBOL_UNDER_TEST] == 0 } then {
+	    perror "COBOL_UNDER_TEST ($COBOL_UNDER_TEST) does not exist"
+	    exit 1
+	}
+    }
+    if ![info exists tmpdir] {
+	set tmpdir "/tmp"
+    }
+
+    if [info exists gluefile] {
+	unset gluefile
+    }
+
+    cobol_maybe_build_wrapper "${tmpdir}/cobol-testglue.o"
+
+    set ALWAYS_COBOLFLAGS ""
+
+    # TEST_ALWAYS_FLAGS are flags that should be passed to every
+    # compilation.  They are passed first to allow individual
+    # tests to override them.
+    if [info exists TEST_ALWAYS_FLAGS] {
+	lappend ALWAYS_COBOLFLAGS "additional_flags=$TEST_ALWAYS_FLAGS"
+    }
+
+    if ![is_remote host] {
+	if [info exists TOOL_OPTIONS] {
+	    lappend ALWAYS_COBOLFLAGS "ldflags=[cobol_link_flags [get_multilibs ${TOOL_OPTIONS}] ]"
+	} else {
+	    lappend ALWAYS_COBOLFLAGS "ldflags=[cobol_link_flags [get_multilibs] ]"
+	}
+    }
+
+    if [info exists TOOL_OPTIONS] {
+	lappend ALWAYS_COBOLFLAGS "additional_flags=$TOOL_OPTIONS"
+    }
+
+    verbose -log "ALWAYS_COBOLFLAGS set to $ALWAYS_COBOLFLAGS"
+
+    verbose "cobol is initialized" 3
+}
+
+#
+# cobol_target_compile -- compile a source file
+#
+
+proc cobol_target_compile { source dest type options } {
+    global tmpdir
+    global gluefile wrap_flags
+    global ALWAYS_COBOLFLAGS
+    global COBOL_UNDER_TEST
+    global TEST_ALWAYS_FLAGS
+    global flags_to_postpone
+    global board_info
+
+    if { [target_info needs_status_wrapper] != "" && [info exists gluefile] } {
+	lappend options "libs=${gluefile}"
+	lappend options "ldflags=${wrap_flags}"
+    }
+
+    # TEST_ALWAYS_FLAGS are flags that should be passed to every
+    # compilation.  They are passed first to allow individual
+    # tests to override them.
+    if [info exists TEST_ALWAYS_FLAGS] {
+	set options [concat "{additional_flags=$TEST_ALWAYS_FLAGS}" $options]
+    }
+
+    # bind_pic_locally adds -fpie/-fPIE flags to flags_to_postpone and it is
+    # appended here to multilib_flags as it can be overridden by the latter
+    # if it was added earlier. After the target_compile, multilib_flags is
+    # restored to its orignal content.
+    set tboard [target_info name]
+    if {[board_info $tboard exists multilib_flags]} {
+        set orig_multilib_flags "[board_info [target_info name] multilib_flags]"
+        append board_info($tboard,multilib_flags) " $flags_to_postpone"
+    }
+
+    lappend options "compiler=$COBOL_UNDER_TEST"
+    lappend options "timeout=[timeout_value]"
+
+    set options [concat "$ALWAYS_COBOLFLAGS" $options]
+    set options [dg-additional-files-options $options $source $dest $type]
+    set return_val [target_compile $source $dest $type $options]
+
+    if {[board_info $tboard exists multilib_flags]} {
+        set board_info($tboard,multilib_flags) $orig_multilib_flags
+        set flags_to_postpone ""
+    }
+
+    return $return_val
+}
  

On Tue, Mar 11, 2025 at 02:40:19PM +0100, Richard Biener wrote:
> OK, I've done that and amended the set of testcases with one
> exercising dg-error.  I had to prune the sprious
> 
> cobol1: error: failed compiling t.cob
> 
> message we emit.  I don't see any warnings emitted from the frontend
> and wasn't able to create a Cobol program where the middle-end 
> would emit one.

Thanks.  One more thing.  The libgcobol dependence on libstdc++
makes me wonder if the *.exp file doesn't have to include
-B etc. options not just for libgcobol itself but also for libstdc++.
Otherwise I wonder what libstdc++ is being considered during the linking
(preferably not relying on any system libstdc++).

	Jakub
  

On Tue, 11 Mar 2025, Jakub Jelinek wrote:

> On Tue, Mar 11, 2025 at 02:40:19PM +0100, Richard Biener wrote:
> > OK, I've done that and amended the set of testcases with one
> > exercising dg-error.  I had to prune the sprious
> > 
> > cobol1: error: failed compiling t.cob
> > 
> > message we emit.  I don't see any warnings emitted from the frontend
> > and wasn't able to create a Cobol program where the middle-end 
> > would emit one.
> 
> Thanks.  One more thing.  The libgcobol dependence on libstdc++
> makes me wonder if the *.exp file doesn't have to include
> -B etc. options not just for libgcobol itself but also for libstdc++.
> Otherwise I wonder what libstdc++ is being considered during the linking
> (preferably not relying on any system libstdc++).

Good point - I'll see to add those.

Richard.
  

On Tue, 11 Mar 2025, Richard Biener wrote:

> On Tue, 11 Mar 2025, Jakub Jelinek wrote:
> 
> > On Tue, Mar 11, 2025 at 02:40:19PM +0100, Richard Biener wrote:
> > > OK, I've done that and amended the set of testcases with one
> > > exercising dg-error.  I had to prune the sprious
> > > 
> > > cobol1: error: failed compiling t.cob
> > > 
> > > message we emit.  I don't see any warnings emitted from the frontend
> > > and wasn't able to create a Cobol program where the middle-end 
> > > would emit one.
> > 
> > Thanks.  One more thing.  The libgcobol dependence on libstdc++
> > makes me wonder if the *.exp file doesn't have to include
> > -B etc. options not just for libgcobol itself but also for libstdc++.
> > Otherwise I wonder what libstdc++ is being considered during the linking
> > (preferably not relying on any system libstdc++).
> 
> Good point - I'll see to add those.

The following incremental patch does this.  The result has everything
needed but also some weird entries:

Setting LD_LIBRARY_PATH to 
.:/tmp/obj/x86_64-pc-linux-gnu/./libgcobol/.libs:/tmp/obj/x86_64-pc-linux-gnu/./libstdc++-v3/src/.libs:/tmp/obj/gcc/testsuite/cobol/../..:/tmp/obj/gcc/testsuite/cobol/../../32:.:/tmp/obj/x86_64-pc-linux-gnu/./libgcobol/.libs:/tmp/obj/x86_64-pc-linux-gnu/./libstdc++-v3/src/.libs:/tmp/obj/gcc/testsuite/cobol/../..:/tmp/obj/gcc/testsuite/cobol/../../32

Richard.


diff --git a/gcc/testsuite/lib/cobol.exp b/gcc/testsuite/lib/cobol.exp
index 65687bc64ae..73dfeab5ba8 100644
--- a/gcc/testsuite/lib/cobol.exp
+++ b/gcc/testsuite/lib/cobol.exp
@@ -119,6 +119,9 @@ proc cobol_link_flags { paths } {
        }
        append ld_library_path ":${gccpath}/libgcobol/.libs"
       }
+      if { [file exists 
"${gccpath}/libstdc++-v3/src/.libs/libstdc++.${shlib_ext}"] } {
+       append ld_library_path ":${gccpath}/libstdc++-v3/src/.libs"
+      }
 
       if [file exists "${gccpath}/libiberty/libiberty.a"] {
           append flags "-L${gccpath}/libiberty "
  

> On 11 Mar 2025, at 14:30, Richard Biener <rguenther@suse.de> wrote:
> 
> On Tue, 11 Mar 2025, Richard Biener wrote:
> 
>> On Tue, 11 Mar 2025, Jakub Jelinek wrote:
>> 
>>> On Tue, Mar 11, 2025 at 02:40:19PM +0100, Richard Biener wrote:
>>>> OK, I've done that and amended the set of testcases with one
>>>> exercising dg-error.  I had to prune the sprious
>>>> 
>>>> cobol1: error: failed compiling t.cob
>>>> 
>>>> message we emit.  I don't see any warnings emitted from the frontend
>>>> and wasn't able to create a Cobol program where the middle-end 
>>>> would emit one.
>>> 
>>> Thanks.  One more thing.  The libgcobol dependence on libstdc++
>>> makes me wonder if the *.exp file doesn't have to include
>>> -B etc. options not just for libgcobol itself but also for libstdc++.
>>> Otherwise I wonder what libstdc++ is being considered during the linking
>>> (preferably not relying on any system libstdc++).
>> 
>> Good point - I'll see to add those.
> 
> The following incremental patch does this.  The result has everything
> needed but also some weird entries:
> 
> Setting LD_LIBRARY_PATH to 
> .:/tmp/obj/x86_64-pc-linux-gnu/./libgcobol/.libs:/tmp/obj/x86_64-pc-linux-gnu/./libstdc++-v3/src/.libs:/tmp/obj/gcc/testsuite/cobol/../..:/tmp/obj/gcc/testsuite/cobol/../../32:.:/tmp/obj/x86_64-pc-linux-gnu/./libgcobol/.libs:/tmp/obj/x86_64-pc-linux-gnu/./libstdc++-v3/src/.libs:/tmp/obj/gcc/testsuite/cobol/../..:/tmp/obj/gcc/testsuite/cobol/../../32
> 
> Richard.
> 
> 
> diff --git a/gcc/testsuite/lib/cobol.exp b/gcc/testsuite/lib/cobol.exp
> index 65687bc64ae..73dfeab5ba8 100644
> --- a/gcc/testsuite/lib/cobol.exp
> +++ b/gcc/testsuite/lib/cobol.exp
> @@ -119,6 +119,9 @@ proc cobol_link_flags { paths } {
>        }
>        append ld_library_path ":${gccpath}/libgcobol/.libs"
>       }
> +      if { [file exists 
> "${gccpath}/libstdc++-v3/src/.libs/libstdc++.${shlib_ext}"] } {

I think Darwin at least, will need a -B for the libstdc++-v3/src/.libs path adding to
the flags; this is used to set the embedded runpaths and the OS is getting picky about
not falling back to alternate shared libs.
(not any way urgent since we cannot build the FE yet)
Iain

> +       append ld_library_path ":${gccpath}/libstdc++-v3/src/.libs"
> +      }
> 
>       if [file exists "${gccpath}/libiberty/libiberty.a"] {
>           append flags "-L${gccpath}/libiberty "
  

On Tue, Mar 11, 2025 at 02:45:33PM +0000, Iain Sandoe wrote:
> > The following incremental patch does this.  The result has everything
> > needed but also some weird entries:
> > 
> > Setting LD_LIBRARY_PATH to 
> > .:/tmp/obj/x86_64-pc-linux-gnu/./libgcobol/.libs:/tmp/obj/x86_64-pc-linux-gnu/./libstdc++-v3/src/.libs:/tmp/obj/gcc/testsuite/cobol/../..:/tmp/obj/gcc/testsuite/cobol/../../32:.:/tmp/obj/x86_64-pc-linux-gnu/./libgcobol/.libs:/tmp/obj/x86_64-pc-linux-gnu/./libstdc++-v3/src/.libs:/tmp/obj/gcc/testsuite/cobol/../..:/tmp/obj/gcc/testsuite/cobol/../../32
> > 
> > Richard.
> > 
> > 
> > diff --git a/gcc/testsuite/lib/cobol.exp b/gcc/testsuite/lib/cobol.exp
> > index 65687bc64ae..73dfeab5ba8 100644
> > --- a/gcc/testsuite/lib/cobol.exp
> > +++ b/gcc/testsuite/lib/cobol.exp
> > @@ -119,6 +119,9 @@ proc cobol_link_flags { paths } {
> >        }
> >        append ld_library_path ":${gccpath}/libgcobol/.libs"
> >       }
> > +      if { [file exists 
> > "${gccpath}/libstdc++-v3/src/.libs/libstdc++.${shlib_ext}"] } {
> 
> I think Darwin at least, will need a -B for the libstdc++-v3/src/.libs path adding to
> the flags; this is used to set the embedded runpaths and the OS is getting picky about
> not falling back to alternate shared libs.
> (not any way urgent since we cannot build the FE yet)

Yeah, I'd just add -B with libstdc++-src-v3/src/.libs on all targets too,
not just the ld_library_path part.

> > +       append ld_library_path ":${gccpath}/libstdc++-v3/src/.libs"
> > +      }
> > 
> >       if [file exists "${gccpath}/libiberty/libiberty.a"] {
> >           append flags "-L${gccpath}/libiberty "

	Jakub
  

On Tue, 11 Mar 2025, Jakub Jelinek wrote:

> On Tue, Mar 11, 2025 at 02:45:33PM +0000, Iain Sandoe wrote:
> > > The following incremental patch does this.  The result has everything
> > > needed but also some weird entries:
> > > 
> > > Setting LD_LIBRARY_PATH to 
> > > .:/tmp/obj/x86_64-pc-linux-gnu/./libgcobol/.libs:/tmp/obj/x86_64-pc-linux-gnu/./libstdc++-v3/src/.libs:/tmp/obj/gcc/testsuite/cobol/../..:/tmp/obj/gcc/testsuite/cobol/../../32:.:/tmp/obj/x86_64-pc-linux-gnu/./libgcobol/.libs:/tmp/obj/x86_64-pc-linux-gnu/./libstdc++-v3/src/.libs:/tmp/obj/gcc/testsuite/cobol/../..:/tmp/obj/gcc/testsuite/cobol/../../32
> > > 
> > > Richard.
> > > 
> > > 
> > > diff --git a/gcc/testsuite/lib/cobol.exp b/gcc/testsuite/lib/cobol.exp
> > > index 65687bc64ae..73dfeab5ba8 100644
> > > --- a/gcc/testsuite/lib/cobol.exp
> > > +++ b/gcc/testsuite/lib/cobol.exp
> > > @@ -119,6 +119,9 @@ proc cobol_link_flags { paths } {
> > >        }
> > >        append ld_library_path ":${gccpath}/libgcobol/.libs"
> > >       }
> > > +      if { [file exists 
> > > "${gccpath}/libstdc++-v3/src/.libs/libstdc++.${shlib_ext}"] } {
> > 
> > I think Darwin at least, will need a -B for the libstdc++-v3/src/.libs path adding to
> > the flags; this is used to set the embedded runpaths and the OS is getting picky about
> > not falling back to alternate shared libs.
> > (not any way urgent since we cannot build the FE yet)
> 
> Yeah, I'd just add -B with libstdc++-src-v3/src/.libs on all targets too,
> not just the ld_library_path part.

Fair enough, then additionally the following

diff --git a/gcc/testsuite/lib/cobol.exp b/gcc/testsuite/lib/cobol.exp
index 73dfeab5ba8..cd88bcb66d1 100644
--- a/gcc/testsuite/lib/cobol.exp
+++ b/gcc/testsuite/lib/cobol.exp
@@ -119,7 +119,13 @@ proc cobol_link_flags { paths } {
        }
        append ld_library_path ":${gccpath}/libgcobol/.libs"
       }
-      if { [file exists 
"${gccpath}/libstdc++-v3/src/.libs/libstdc++.${shlib_ext}"] } {
+      if { [file exists "${gccpath}/libstdc++-v3/src/.libs/libstdc++.a"] 
||
+          [file exists 
"${gccpath}/libstdc++-v3/src/.libs/libstdc++.${shlib_ext}"] } {
+       if { $target_wants_B_option } {
+          append flags "-B${gccpath}/libstdc++-v3/src/.libs "
+       } else {
+          append flags "-L${gccpath}/libstdc++-v3/src/.libs "
+       }
        append ld_library_path ":${gccpath}/libstdc++-v3/src/.libs"
       }
  

On Tue, Mar 11, 2025 at 04:18:32PM +0100, Richard Biener wrote:
> On Tue, 11 Mar 2025, Jakub Jelinek wrote:
> 
> > On Tue, Mar 11, 2025 at 02:45:33PM +0000, Iain Sandoe wrote:
> > > > The following incremental patch does this.  The result has everything
> > > > needed but also some weird entries:
> > > > 
> > > > Setting LD_LIBRARY_PATH to 
> > > > .:/tmp/obj/x86_64-pc-linux-gnu/./libgcobol/.libs:/tmp/obj/x86_64-pc-linux-gnu/./libstdc++-v3/src/.libs:/tmp/obj/gcc/testsuite/cobol/../..:/tmp/obj/gcc/testsuite/cobol/../../32:.:/tmp/obj/x86_64-pc-linux-gnu/./libgcobol/.libs:/tmp/obj/x86_64-pc-linux-gnu/./libstdc++-v3/src/.libs:/tmp/obj/gcc/testsuite/cobol/../..:/tmp/obj/gcc/testsuite/cobol/../../32
> > > > 
> > > > Richard.
> > > > 
> > > > 
> > > > diff --git a/gcc/testsuite/lib/cobol.exp b/gcc/testsuite/lib/cobol.exp
> > > > index 65687bc64ae..73dfeab5ba8 100644
> > > > --- a/gcc/testsuite/lib/cobol.exp
> > > > +++ b/gcc/testsuite/lib/cobol.exp
> > > > @@ -119,6 +119,9 @@ proc cobol_link_flags { paths } {
> > > >        }
> > > >        append ld_library_path ":${gccpath}/libgcobol/.libs"
> > > >       }
> > > > +      if { [file exists 
> > > > "${gccpath}/libstdc++-v3/src/.libs/libstdc++.${shlib_ext}"] } {
> > > 
> > > I think Darwin at least, will need a -B for the libstdc++-v3/src/.libs path adding to
> > > the flags; this is used to set the embedded runpaths and the OS is getting picky about
> > > not falling back to alternate shared libs.
> > > (not any way urgent since we cannot build the FE yet)
> > 
> > Yeah, I'd just add -B with libstdc++-src-v3/src/.libs on all targets too,
> > not just the ld_library_path part.
> 
> Fair enough, then additionally the following
> 
> diff --git a/gcc/testsuite/lib/cobol.exp b/gcc/testsuite/lib/cobol.exp
> index 73dfeab5ba8..cd88bcb66d1 100644
> --- a/gcc/testsuite/lib/cobol.exp
> +++ b/gcc/testsuite/lib/cobol.exp
> @@ -119,7 +119,13 @@ proc cobol_link_flags { paths } {
>         }
>         append ld_library_path ":${gccpath}/libgcobol/.libs"
>        }
> -      if { [file exists 
> "${gccpath}/libstdc++-v3/src/.libs/libstdc++.${shlib_ext}"] } {
> +      if { [file exists "${gccpath}/libstdc++-v3/src/.libs/libstdc++.a"] 
> ||
> +          [file exists 
> "${gccpath}/libstdc++-v3/src/.libs/libstdc++.${shlib_ext}"] } {
> +       if { $target_wants_B_option } {
> +          append flags "-B${gccpath}/libstdc++-v3/src/.libs "
> +       } else {
> +          append flags "-L${gccpath}/libstdc++-v3/src/.libs "
> +       }
>         append ld_library_path ":${gccpath}/libstdc++-v3/src/.libs"
>        }
>  

Looks good to me.

	Jakub
  

Earlier in this discussion of a testsuite, the question came up about
generating an error return in COBOL source code.

In COBOL, "GOBACK ERROR 1." is the equivalent of a C "return 1;".  When
executed in  the initial "top-level" program-id, it results in the value 1
being passed back to the _start stub.

"STOP RUN ERROR 1." is the equivalent of (and is in fact implemented with)
"exit(1)".

Bob D.

> -----Original Message-----
> From: Jakub Jelinek <jakub@redhat.com>
> Sent: Tuesday, March 11, 2025 11:27
> To: Richard Biener <rguenther@suse.de>
> Cc: Iain Sandoe <idsandoe@googlemail.com>; GCC Patches <gcc-
> patches@gcc.gnu.org>; jklowden@schemamania.org
> Subject: Re: [PATCH][v3] Simple cobol.dg testsuite
> 
> On Tue, Mar 11, 2025 at 04:18:32PM +0100, Richard Biener wrote:
> > On Tue, 11 Mar 2025, Jakub Jelinek wrote:
> >
> > > On Tue, Mar 11, 2025 at 02:45:33PM +0000, Iain Sandoe wrote:
> > > > > The following incremental patch does this.  The result has
> > > > > everything needed but also some weird entries:
> > > > >
> > > > > Setting LD_LIBRARY_PATH to
> > > > > .:/tmp/obj/x86_64-pc-linux-gnu/./libgcobol/.libs:/tmp/obj/x86_64
> > > > > -pc-linux-gnu/./libstdc++-v3/src/.libs:/tmp/obj/gcc/testsuite/co
> > > > > bol/../..:/tmp/obj/gcc/testsuite/cobol/../../32:.:/tmp/obj/x86_6
> > > > > 4-pc-linux-gnu/./libgcobol/.libs:/tmp/obj/x86_64-pc-linux-gnu/./
> > > > > libstdc++-v3/src/.libs:/tmp/obj/gcc/testsuite/cobol/../..:/tmp/o
> > > > > bj/gcc/testsuite/cobol/../../32
> > > > >
> > > > > Richard.
> > > > >
> > > > >
> > > > > diff --git a/gcc/testsuite/lib/cobol.exp
> > > > > b/gcc/testsuite/lib/cobol.exp index 65687bc64ae..73dfeab5ba8
> > > > > 100644
> > > > > --- a/gcc/testsuite/lib/cobol.exp
> > > > > +++ b/gcc/testsuite/lib/cobol.exp
> > > > > @@ -119,6 +119,9 @@ proc cobol_link_flags { paths } {
> > > > >        }
> > > > >        append ld_library_path ":${gccpath}/libgcobol/.libs"
> > > > >       }
> > > > > +      if { [file exists
> > > > > "${gccpath}/libstdc++-v3/src/.libs/libstdc++.${shlib_ext}"] } {
> > > >
> > > > I think Darwin at least, will need a -B for the
> > > > libstdc++-v3/src/.libs path adding to the flags; this is used to
> > > > set the embedded runpaths and the OS is getting picky about not
> falling back to alternate shared libs.
> > > > (not any way urgent since we cannot build the FE yet)
> > >
> > > Yeah, I'd just add -B with libstdc++-src-v3/src/.libs on all targets
> > > too, not just the ld_library_path part.
> >
> > Fair enough, then additionally the following
> >
> > diff --git a/gcc/testsuite/lib/cobol.exp b/gcc/testsuite/lib/cobol.exp
> > index 73dfeab5ba8..cd88bcb66d1 100644
> > --- a/gcc/testsuite/lib/cobol.exp
> > +++ b/gcc/testsuite/lib/cobol.exp
> > @@ -119,7 +119,13 @@ proc cobol_link_flags { paths } {
> >         }
> >         append ld_library_path ":${gccpath}/libgcobol/.libs"
> >        }
> > -      if { [file exists
> > "${gccpath}/libstdc++-v3/src/.libs/libstdc++.${shlib_ext}"] } {
> > +      if { [file exists
> > + "${gccpath}/libstdc++-v3/src/.libs/libstdc++.a"]
> > ||
> > +          [file exists
> > "${gccpath}/libstdc++-v3/src/.libs/libstdc++.${shlib_ext}"] } {
> > +       if { $target_wants_B_option } {
> > +          append flags "-B${gccpath}/libstdc++-v3/src/.libs "
> > +       } else {
> > +          append flags "-L${gccpath}/libstdc++-v3/src/.libs "
> > +       }
> >         append ld_library_path ":${gccpath}/libstdc++-v3/src/.libs"
> >        }
> >
> 
> Looks good to me.
> 
> 	Jakub
  

On Tue, 11 Mar 2025, Robert Dubner wrote:

> Earlier in this discussion of a testsuite, the question came up about
> generating an error return in COBOL source code.
> 
> In COBOL, "GOBACK ERROR 1." is the equivalent of a C "return 1;".  When
> executed in  the initial "top-level" program-id, it results in the value 1
> being passed back to the _start stub.
> 
> "STOP RUN ERROR 1." is the equivalent of (and is in fact implemented with)
> "exit(1)".

Thanks, I'll add a fail.cob test checking this is catched by dejagnu.

Richard.

> Bob D.
> 
> > -----Original Message-----
> > From: Jakub Jelinek <jakub@redhat.com>
> > Sent: Tuesday, March 11, 2025 11:27
> > To: Richard Biener <rguenther@suse.de>
> > Cc: Iain Sandoe <idsandoe@googlemail.com>; GCC Patches <gcc-
> > patches@gcc.gnu.org>; jklowden@schemamania.org
> > Subject: Re: [PATCH][v3] Simple cobol.dg testsuite
> > 
> > On Tue, Mar 11, 2025 at 04:18:32PM +0100, Richard Biener wrote:
> > > On Tue, 11 Mar 2025, Jakub Jelinek wrote:
> > >
> > > > On Tue, Mar 11, 2025 at 02:45:33PM +0000, Iain Sandoe wrote:
> > > > > > The following incremental patch does this.  The result has
> > > > > > everything needed but also some weird entries:
> > > > > >
> > > > > > Setting LD_LIBRARY_PATH to
> > > > > > .:/tmp/obj/x86_64-pc-linux-gnu/./libgcobol/.libs:/tmp/obj/x86_64
> > > > > > -pc-linux-gnu/./libstdc++-v3/src/.libs:/tmp/obj/gcc/testsuite/co
> > > > > > bol/../..:/tmp/obj/gcc/testsuite/cobol/../../32:.:/tmp/obj/x86_6
> > > > > > 4-pc-linux-gnu/./libgcobol/.libs:/tmp/obj/x86_64-pc-linux-gnu/./
> > > > > > libstdc++-v3/src/.libs:/tmp/obj/gcc/testsuite/cobol/../..:/tmp/o
> > > > > > bj/gcc/testsuite/cobol/../../32
> > > > > >
> > > > > > Richard.
> > > > > >
> > > > > >
> > > > > > diff --git a/gcc/testsuite/lib/cobol.exp
> > > > > > b/gcc/testsuite/lib/cobol.exp index 65687bc64ae..73dfeab5ba8
> > > > > > 100644
> > > > > > --- a/gcc/testsuite/lib/cobol.exp
> > > > > > +++ b/gcc/testsuite/lib/cobol.exp
> > > > > > @@ -119,6 +119,9 @@ proc cobol_link_flags { paths } {
> > > > > >        }
> > > > > >        append ld_library_path ":${gccpath}/libgcobol/.libs"
> > > > > >       }
> > > > > > +      if { [file exists
> > > > > > "${gccpath}/libstdc++-v3/src/.libs/libstdc++.${shlib_ext}"] } {
> > > > >
> > > > > I think Darwin at least, will need a -B for the
> > > > > libstdc++-v3/src/.libs path adding to the flags; this is used to
> > > > > set the embedded runpaths and the OS is getting picky about not
> > falling back to alternate shared libs.
> > > > > (not any way urgent since we cannot build the FE yet)
> > > >
> > > > Yeah, I'd just add -B with libstdc++-src-v3/src/.libs on all targets
> > > > too, not just the ld_library_path part.
> > >
> > > Fair enough, then additionally the following
> > >
> > > diff --git a/gcc/testsuite/lib/cobol.exp b/gcc/testsuite/lib/cobol.exp
> > > index 73dfeab5ba8..cd88bcb66d1 100644
> > > --- a/gcc/testsuite/lib/cobol.exp
> > > +++ b/gcc/testsuite/lib/cobol.exp
> > > @@ -119,7 +119,13 @@ proc cobol_link_flags { paths } {
> > >         }
> > >         append ld_library_path ":${gccpath}/libgcobol/.libs"
> > >        }
> > > -      if { [file exists
> > > "${gccpath}/libstdc++-v3/src/.libs/libstdc++.${shlib_ext}"] } {
> > > +      if { [file exists
> > > + "${gccpath}/libstdc++-v3/src/.libs/libstdc++.a"]
> > > ||
> > > +          [file exists
> > > "${gccpath}/libstdc++-v3/src/.libs/libstdc++.${shlib_ext}"] } {
> > > +       if { $target_wants_B_option } {
> > > +          append flags "-B${gccpath}/libstdc++-v3/src/.libs "
> > > +       } else {
> > > +          append flags "-L${gccpath}/libstdc++-v3/src/.libs "
> > > +       }
> > >         append ld_library_path ":${gccpath}/libstdc++-v3/src/.libs"
> > >        }
> > >
> > 
> > Looks good to me.
> > 
> > 	Jakub
> 
>
  

On Tue, Mar 11, 2025 at 10:06:27PM -0500, Robert Dubner wrote:
> Earlier in this discussion of a testsuite, the question came up about
> generating an error return in COBOL source code.
> 
> In COBOL, "GOBACK ERROR 1." is the equivalent of a C "return 1;".  When
> executed in  the initial "top-level" program-id, it results in the value 1
> being passed back to the _start stub.
> 
> "STOP RUN ERROR 1." is the equivalent of (and is in fact implemented with)
> "exit(1)".

Note, in most of the testsuite we try to signal failure from a runtime
testcase through calling abort (or e.g. fortran STOP N statement).
On Linux at least when not cross-compiling, exit(1) (or this
STOP RUN ERROR 1) will work as well, I believe the reason is for some
bare metal targets which just don't propagate return value from main or
exit back to the dejagnu testing framework.
Does COBOL have something that is implemented as call to abort()?

	Jakub
  

On Wed, 12 Mar 2025, Jakub Jelinek wrote:

> On Tue, Mar 11, 2025 at 10:06:27PM -0500, Robert Dubner wrote:
> > Earlier in this discussion of a testsuite, the question came up about
> > generating an error return in COBOL source code.
> > 
> > In COBOL, "GOBACK ERROR 1." is the equivalent of a C "return 1;".  When
> > executed in  the initial "top-level" program-id, it results in the value 1
> > being passed back to the _start stub.
> > 
> > "STOP RUN ERROR 1." is the equivalent of (and is in fact implemented with)
> > "exit(1)".
> 
> Note, in most of the testsuite we try to signal failure from a runtime
> testcase through calling abort (or e.g. fortran STOP N statement).
> On Linux at least when not cross-compiling, exit(1) (or this
> STOP RUN ERROR 1) will work as well, I believe the reason is for some
> bare metal targets which just don't propagate return value from main or
> exit back to the dejagnu testing framework.
> Does COBOL have something that is implemented as call to abort()?

For now, given the supported host/target limits I've verified that
STOP RUN ERROR 1. works.  I have now pushed the following.

Richard.

From 1eefd65af8bcc0f8582967782eb4ee97f6775813 Mon Sep 17 00:00:00 2001
From: Richard Biener <rguenther@suse.de>
Date: Tue, 11 Mar 2025 09:39:06 +0100
Subject: [PATCH] Simple cobol.dg testsuite
To: gcc-patches@gcc.gnu.org

The following adds a simple cobol.dg test harness, based on gfortran.dg.
It's invoked by make check-cobol, has three tests, two execution test and
one test exercising dg-error.  The existing FAIL is due to an assembling
error, tracked by PR119214.

Running /home/rguenther/src/gcc/gcc/testsuite/cobol.dg/dg.exp ...
FAIL: cobol.dg/pass.cob   -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions  (test for excess errors)
FAIL: cobol.dg/fail.cob   -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions  (test for excess errors)

                === cobol Summary ===

 # of expected passes            12
 # of unexpected failures        1
 # of unresolved testcases       1

gcc/cobol/
	* Make-lang.in (lang_checks): Add check-cobol.

gcc/testsuite/
	* lib/cobol-dg.exp: New, based on gfortran-dg.exp.
	* lib/cobol.exp: New, based on gfortran.exp.
	* cobol.dg/dg.exp: New.
	* cobol.dg/pass.cob: New test.
	* cobol.dg/fail.cob: Likewise.
	* cobol.dg/error-1.cob: Likewise.
---
 gcc/cobol/Make-lang.in             |   2 +
 gcc/testsuite/cobol.dg/dg.exp      |  41 ++++
 gcc/testsuite/cobol.dg/error-1.cob |   9 +
 gcc/testsuite/cobol.dg/fail.cob    |   6 +
 gcc/testsuite/cobol.dg/pass.cob    |   6 +
 gcc/testsuite/lib/cobol-dg.exp     |  85 +++++++++
 gcc/testsuite/lib/cobol.exp        | 291 +++++++++++++++++++++++++++++
 7 files changed, 440 insertions(+)
 create mode 100644 gcc/testsuite/cobol.dg/dg.exp
 create mode 100644 gcc/testsuite/cobol.dg/error-1.cob
 create mode 100644 gcc/testsuite/cobol.dg/fail.cob
 create mode 100644 gcc/testsuite/cobol.dg/pass.cob
 create mode 100644 gcc/testsuite/lib/cobol-dg.exp
 create mode 100644 gcc/testsuite/lib/cobol.exp

diff --git a/gcc/cobol/Make-lang.in b/gcc/cobol/Make-lang.in
index a4e005ac2bd..cbb31d63c30 100644
--- a/gcc/cobol/Make-lang.in
+++ b/gcc/cobol/Make-lang.in
@@ -367,3 +367,5 @@ cobol.stagefeedback: stagefeedback-start
 	-mv cobol/*$(objext) stagefeedback/cobol
 
 selftest-cobol:
+
+lang_checks += check-cobol
diff --git a/gcc/testsuite/cobol.dg/dg.exp b/gcc/testsuite/cobol.dg/dg.exp
new file mode 100644
index 00000000000..c81634ac817
--- /dev/null
+++ b/gcc/testsuite/cobol.dg/dg.exp
@@ -0,0 +1,41 @@
+#   Copyright (C) 2004-2025 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+# 
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+# 
+# You should have received a copy of the GNU General Public License
+# along with GCC; see the file COPYING3.  If not see
+# <http://www.gnu.org/licenses/>.
+
+# GCC testsuite that uses the `dg.exp' driver.
+
+# Load support procs.
+load_lib cobol-dg.exp
+
+# If a testcase doesn't have special options, use these.
+global DEFAULT_COBFLAGS
+if ![info exists DEFAULT_COBFLAGS] then {
+    set DEFAULT_COBFLAGS " "
+}
+
+# Initialize `dg'.
+dg-init
+
+global cobol_test_path
+set cobol_test_path $srcdir/$subdir
+
+set all_flags $DEFAULT_COBFLAGS
+
+# Main loop.
+cobol-dg-runtest [lsort \
+       [glob -nocomplain $srcdir/$subdir/*.cob ] ] "" $all_flags
+
+# All done.
+dg-finish
diff --git a/gcc/testsuite/cobol.dg/error-1.cob b/gcc/testsuite/cobol.dg/error-1.cob
new file mode 100644
index 00000000000..9e51a90b841
--- /dev/null
+++ b/gcc/testsuite/cobol.dg/error-1.cob
@@ -0,0 +1,9 @@
+*> { dg-do compile }
+IDENTIFICATION DIVISION.
+PROGRAM-ID. error-1.
+ENVIRONMENT DIVISION.
+DATA DIVISION.
+    WORKING-STORAGE SECTION.
+    02 VAR PIC S9(3) VALUE 1. *> { dg-error "not part of" }
+PROCEDURE DIVISION.
+    STOP RUN.
diff --git a/gcc/testsuite/cobol.dg/fail.cob b/gcc/testsuite/cobol.dg/fail.cob
new file mode 100644
index 00000000000..e0dd3eade21
--- /dev/null
+++ b/gcc/testsuite/cobol.dg/fail.cob
@@ -0,0 +1,6 @@
+*> { dg-do run { xfail *-*-* } }
+IDENTIFICATION DIVISION.
+PROGRAM-ID. fail.
+ENVIRONMENT DIVISION.
+PROCEDURE DIVISION.
+    STOP RUN ERROR 1.
diff --git a/gcc/testsuite/cobol.dg/pass.cob b/gcc/testsuite/cobol.dg/pass.cob
new file mode 100644
index 00000000000..47cfd2bb09a
--- /dev/null
+++ b/gcc/testsuite/cobol.dg/pass.cob
@@ -0,0 +1,6 @@
+*> { dg-do run }
+IDENTIFICATION DIVISION.
+PROGRAM-ID. pass.
+ENVIRONMENT DIVISION.
+PROCEDURE DIVISION.
+    STOP RUN.
diff --git a/gcc/testsuite/lib/cobol-dg.exp b/gcc/testsuite/lib/cobol-dg.exp
new file mode 100644
index 00000000000..51df13df19f
--- /dev/null
+++ b/gcc/testsuite/lib/cobol-dg.exp
@@ -0,0 +1,85 @@
+#   Copyright (C) 2004-2025 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+# 
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+# 
+# You should have received a copy of the GNU General Public License
+# along with GCC; see the file COPYING3.  If not see
+# <http://www.gnu.org/licenses/>.
+
+load_lib gcc-dg.exp
+load_lib torture-options.exp
+
+# Define cobol callbacks for dg.exp.
+
+proc cobol-dg-test { prog do_what extra_tool_flags } {
+    set result \
+	[gcc-dg-test-1 cobol_target_compile $prog $do_what $extra_tool_flags]
+    
+    set comp_output [lindex $result 0]
+    set output_file [lindex $result 1]
+
+    return [list $comp_output $output_file]
+}
+
+proc cobol-dg-prune { system text } {
+    # cobol prints an extra stray error at the end when compilation fails
+    regsub -all "(^|\n)cobol1: error: failed compiling \[^\n\]*" $text "" text
+    return [gcc-dg-prune $system $text]
+}
+
+# Utility routines.
+
+# Modified dg-runtest that can cycle through a list of optimization options
+# as c-torture does.
+proc cobol-dg-runtest { testcases flags default-extra-flags } {
+    global runtests
+    global torture_with_loops
+
+    # Some callers initialize torture testing themselves; don't override those.
+    set existing_torture_init [torture-init-done]
+    if { $existing_torture_init == 0 } {
+	torture-init
+    }
+    # Some callers set torture options themselves; don't override those.
+    set existing_torture_options [torture-options-exist]
+    if { $existing_torture_options == 0 } {
+	global DG_TORTURE_OPTIONS
+	set-torture-options $DG_TORTURE_OPTIONS
+    }
+    dump-torture-options
+
+    foreach test $testcases {
+	# If we're only testing specific files and this isn't one of
+	# them, skip it.
+	if ![runtest_file_p $runtests $test] {
+	    continue
+        }
+
+	# look if this is dg-do run test, in which case
+	# we cycle through the option list, otherwise we don't
+	if [expr [search_for $test "dg-do run"]] {
+	    set option_list $torture_with_loops
+	} else {
+	    set option_list [list { -O } ]
+	}
+
+	set nshort [file tail [file dirname $test]]/[file tail $test]
+
+	foreach flags_t $option_list {
+	    verbose "Testing $nshort, $flags $flags_t" 1
+	    dg-test $test "$flags $flags_t" ${default-extra-flags}
+	}
+    }
+
+    if { $existing_torture_init == 0 } {
+	torture-finish
+    }
+}
diff --git a/gcc/testsuite/lib/cobol.exp b/gcc/testsuite/lib/cobol.exp
new file mode 100644
index 00000000000..cd88bcb66d1
--- /dev/null
+++ b/gcc/testsuite/lib/cobol.exp
@@ -0,0 +1,291 @@
+# Copyright (C) 2003-2025 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with GCC; see the file COPYING3.  If not see
+# <http://www.gnu.org/licenses/>.
+
+#
+# cobol support library routines
+#
+load_lib prune.exp
+load_lib gcc-defs.exp
+load_lib timeout.exp
+load_lib target-libpath.exp
+load_lib target-supports.exp
+
+#
+# COBOL_UNDER_TEST is the compiler under test.
+#
+
+
+set gpp_compile_options ""
+
+
+#
+# cobol_version -- extract and print the version number of the compiler
+#
+
+proc cobol_version { } {
+    global COBOL_UNDER_TEST
+    
+    cobol_init
+
+    # ignore any arguments after the command
+    set compiler [lindex $COBOL_UNDER_TEST 0]
+    
+    # verify that the compiler exists
+    if { [is_remote host] || [which $compiler] != 0 } then {
+	set tmp [remote_exec host "$compiler -v"]
+	set status [lindex $tmp 0]
+	set output [lindex $tmp 1]
+	regexp " version \[^\n\r\]*" $output version
+	if { $status == 0 && [info exists version] } then {
+	    if [is_remote host] {
+		clone_output "$compiler $version\n"
+	    } else {
+		clone_output "[which $compiler] $version\n"
+	    }
+	} else {
+	    clone_output "Couldn't determine version of [which $compiler]\n"
+	}
+    } else {
+	# compiler does not exist (this should have already been detected)
+	warning "$compiler does not exist"
+    }
+}
+
+#
+# cobol_link_flags -- provide new version of cobol_link_flags
+# (originally from libgloss.exp) which knows about the gcc tree structure
+#
+
+proc cobol_link_flags { paths } {
+    global srcdir
+    global ld_library_path
+    global COBOL_UNDER_TEST
+    global shlib_ext
+    global ENABLE_DARWIN_AT_RPATH
+
+    set gccpath ${paths}
+    set libio_dir ""
+    set flags ""
+    set ld_library_path "."
+    set shlib_ext [get_shlib_extension]
+    verbose "shared lib extension: $shlib_ext"
+
+    # We need to add options to locate libgfortran and the dependent libs
+    # libquadmath (supporting REAL*16) and libatomic (supporting operations
+    # used by coarrays).  Usually '-L' options are added to point to the
+    # relevant directories for the uninstalled libraries.
+
+    # In cases where libraries are available as both shared and convenience
+    # some additional checks are made.
+
+    # For some targets -static-xxxx options are handled by specs substitution
+    # and need a '-B' option rather than '-L'.  For Darwin, when embedded
+    # runpaths are in use (the default for all versions after macOS 10.11),
+    # '-B' is also needed to provide the runpath.
+    # When '-B' is used, this results in a '-L' for each path that exists (so
+    # that appending a '-L' as well is a needless duplicate).  There are also
+    # cases where tools warn for duplicates, leading to spurious fails.
+    # Therefore the objective of the code below is to add just one '-L' or
+    # '-B' for each of the libraries.
+
+    set target_wants_B_option 0
+    if { [istarget *-*-darwin9* ] || [istarget *-*-darwin\[12\]* ] } {
+      set target_wants_B_option 1
+    }
+
+    if { $gccpath != "" } {
+      if [file exists "${gccpath}/libgcobol/libgcobol.a"] {
+          append flags "-L${gccpath}/libgcobol"
+      }
+      if { [file exists "${gccpath}/libgcobol/.libs/libgcobol.a"] ||
+	 [file exists "${gccpath}/libgobol/.libs/libgcobol.${shlib_ext}"] } {
+	if { $target_wants_B_option } {
+          append flags "-B${gccpath}/libgcobol/.libs "
+	} else {
+          append flags "-L${gccpath}/libgcobol/.libs "
+	}
+	append ld_library_path ":${gccpath}/libgcobol/.libs"
+      }
+      if { [file exists "${gccpath}/libstdc++-v3/src/.libs/libstdc++.a"] ||
+          [file exists "${gccpath}/libstdc++-v3/src/.libs/libstdc++.${shlib_ext}"] } {
+	if { $target_wants_B_option } {
+          append flags "-B${gccpath}/libstdc++-v3/src/.libs "
+	} else {
+          append flags "-L${gccpath}/libstdc++-v3/src/.libs "
+	}
+	append ld_library_path ":${gccpath}/libstdc++-v3/src/.libs"
+      }
+
+      if [file exists "${gccpath}/libiberty/libiberty.a"] {
+          append flags "-L${gccpath}/libiberty "
+      }
+      append ld_library_path \
+	[gcc-set-multilib-library-path $COBOL_UNDER_TEST ]
+    }
+
+    set_ld_library_path_env_vars
+
+    return "$flags"
+}
+
+#
+# cobol_init -- called at the start of each subdir of tests
+#
+
+proc cobol_init { args } {
+    global subdir
+    global gpp_initialized
+    global base_dir
+    global tmpdir
+    global libdir
+    global gluefile wrap_flags
+    global objdir srcdir
+    global ALWAYS_COBOLFLAGS
+    global TOOL_EXECUTABLE TOOL_OPTIONS
+    global COBOL_UNDER_TEST
+    global TESTING_IN_BUILD_TREE
+    global gcc_warning_prefix
+    global gcc_error_prefix
+    global TEST_ALWAYS_FLAGS
+    global cobol_init_set_COBOL_UNDER_TEST
+
+    # We set LC_ALL and LANG to C so that we get the same error messages as expected.
+    setenv LC_ALL C
+    setenv LANG C
+
+    set gcc_warning_prefix "\[Ww\]arning:"
+    set gcc_error_prefix "(Fatal )?\[Ee\]rror:"
+
+    # Many hosts now default to a non-ASCII C locale, however, so
+    # they can set a charset encoding here if they need.
+    if { [ishost "*-*-cygwin*"] } {
+      setenv LC_ALL C.ASCII
+      setenv LANG C.ASCII
+    }
+
+    # COBOL_UNDER_TEST as set below contains $specpath, which depends on
+    # the used multilib config. Thus, its value may need to be reset;
+    # that's tracked via gfortran_init_set_COBOL_UNDER_TEST.
+    if { ![info exists COBOL_UNDER_TEST]
+	 || [info exists cobol_init_set_COBOL_UNDER_TEST] } then {
+	if [info exists TOOL_EXECUTABLE] {
+	    set COBOL_UNDER_TEST $TOOL_EXECUTABLE
+	} else {
+	    if { [is_remote host] || ! [info exists TESTING_IN_BUILD_TREE] } {
+		set COBOL_UNDER_TEST [transform gcobol]
+	    } else {
+		if [info exists TOOL_OPTIONS] {
+	            set specpath [get_multilibs ${TOOL_OPTIONS}]
+		} else {
+		    set specpath [get_multilibs]
+		}
+		set cobol_init_set_COBOL_UNDER_TEST 1
+		set COBOL_UNDER_TEST [findfile $base_dir/../../gcobol "$base_dir/../../gcobol -B$base_dir/../../ -B$specpath/libgcobol/.libs" [findfile $base_dir/gcobol "$base_dir/gcobol -B$base_dir/" [transform gcobol]]]
+	    }
+	}
+    }
+
+    if ![is_remote host] {
+	if { [which $COBOL_UNDER_TEST] == 0 } then {
+	    perror "COBOL_UNDER_TEST ($COBOL_UNDER_TEST) does not exist"
+	    exit 1
+	}
+    }
+    if ![info exists tmpdir] {
+	set tmpdir "/tmp"
+    }
+
+    if [info exists gluefile] {
+	unset gluefile
+    }
+
+    cobol_maybe_build_wrapper "${tmpdir}/cobol-testglue.o"
+
+    set ALWAYS_COBOLFLAGS ""
+
+    # TEST_ALWAYS_FLAGS are flags that should be passed to every
+    # compilation.  They are passed first to allow individual
+    # tests to override them.
+    if [info exists TEST_ALWAYS_FLAGS] {
+	lappend ALWAYS_COBOLFLAGS "additional_flags=$TEST_ALWAYS_FLAGS"
+    }
+
+    if ![is_remote host] {
+	if [info exists TOOL_OPTIONS] {
+	    lappend ALWAYS_COBOLFLAGS "ldflags=[cobol_link_flags [get_multilibs ${TOOL_OPTIONS}] ]"
+	} else {
+	    lappend ALWAYS_COBOLFLAGS "ldflags=[cobol_link_flags [get_multilibs] ]"
+	}
+    }
+
+    if [info exists TOOL_OPTIONS] {
+	lappend ALWAYS_COBOLFLAGS "additional_flags=$TOOL_OPTIONS"
+    }
+
+    verbose -log "ALWAYS_COBOLFLAGS set to $ALWAYS_COBOLFLAGS"
+
+    verbose "cobol is initialized" 3
+}
+
+#
+# cobol_target_compile -- compile a source file
+#
+
+proc cobol_target_compile { source dest type options } {
+    global tmpdir
+    global gluefile wrap_flags
+    global ALWAYS_COBOLFLAGS
+    global COBOL_UNDER_TEST
+    global TEST_ALWAYS_FLAGS
+    global flags_to_postpone
+    global board_info
+
+    if { [target_info needs_status_wrapper] != "" && [info exists gluefile] } {
+	lappend options "libs=${gluefile}"
+	lappend options "ldflags=${wrap_flags}"
+    }
+
+    # TEST_ALWAYS_FLAGS are flags that should be passed to every
+    # compilation.  They are passed first to allow individual
+    # tests to override them.
+    if [info exists TEST_ALWAYS_FLAGS] {
+	set options [concat "{additional_flags=$TEST_ALWAYS_FLAGS}" $options]
+    }
+
+    # bind_pic_locally adds -fpie/-fPIE flags to flags_to_postpone and it is
+    # appended here to multilib_flags as it can be overridden by the latter
+    # if it was added earlier. After the target_compile, multilib_flags is
+    # restored to its orignal content.
+    set tboard [target_info name]
+    if {[board_info $tboard exists multilib_flags]} {
+        set orig_multilib_flags "[board_info [target_info name] multilib_flags]"
+        append board_info($tboard,multilib_flags) " $flags_to_postpone"
+    }
+
+    lappend options "compiler=$COBOL_UNDER_TEST"
+    lappend options "timeout=[timeout_value]"
+
+    set options [concat "$ALWAYS_COBOLFLAGS" $options]
+    set options [dg-additional-files-options $options $source $dest $type]
+    set return_val [target_compile $source $dest $type $options]
+
+    if {[board_info $tboard exists multilib_flags]} {
+        set board_info($tboard,multilib_flags) $orig_multilib_flags
+        set flags_to_postpone ""
+    }
+
+    return $return_val
+}
  

> -----Original Message-----
> From: Jakub Jelinek <jakub@redhat.com>
> Sent: Wednesday, March 12, 2025 03:23
> To: Robert Dubner <rdubner@symas.com>
> Cc: Richard Biener <rguenther@suse.de>; Iain Sandoe
> <idsandoe@googlemail.com>; GCC Patches <gcc-patches@gcc.gnu.org>;
> jklowden@schemamania.org
> Subject: Re: [PATCH][v3] Simple cobol.dg testsuite
> 
> On Tue, Mar 11, 2025 at 10:06:27PM -0500, Robert Dubner wrote:
> > Earlier in this discussion of a testsuite, the question came up about
> > generating an error return in COBOL source code.
> >
> > In COBOL, "GOBACK ERROR 1." is the equivalent of a C "return 1;".
> > When executed in  the initial "top-level" program-id, it results in
> > the value 1 being passed back to the _start stub.
> >
> > "STOP RUN ERROR 1." is the equivalent of (and is in fact implemented
> > with) "exit(1)".
> 
> Note, in most of the testsuite we try to signal failure from a runtime
> testcase through calling abort (or e.g. fortran STOP N statement).
> On Linux at least when not cross-compiling, exit(1) (or this STOP RUN
> ERROR 1) will work as well, I believe the reason is for some bare metal
> targets which just don't propagate return value from main or exit back
to
> the dejagnu testing framework.
> Does COBOL have something that is implemented as call to abort()?

Jim and I had the design goal of making gcobol object files completely
compatible with other gcc object files, so they can be linked together
without surprises.  There are issues of naming things; COBOL allows for
names with embedded hyphens, and is case-insensitive, and so a complete
answer can be involved.  But that's not important for addressing your
question.

The result is that putting in the COBOL statement 

      CALL "abort".

does just what you'd expect.

So, for that matter, does

      CALL "exit" USING BY VALUE 123.

although that's the same as 

      STOP RUN ERROR 123.

Bob D.
  

Thanks for your work on adding a testsuite. Can you please explain why 
you do this when a complete testsuite exists in autoconf (autotest) 
format (which roots back to decade of work in GnuCOBOL, with all 
copyrights for that already with the FSF)?

Is the existence of this in upstream [1] just unknown (because it was 
not part of the initial patches [for reasons I not understood])?

Is the format such a big issue (note: previous discussions elaborated "a 
test suite is very important and other frontends also use a framework 
other than dejagnu)?

If dejagnu is the way to go:

* Shouldn't there be deprecation of autotest in autoconf (of course only 
if that preference is also outside of gcc)?

* Shouldn't there be a (at least semi automated) script / migration tool 
(at least for this specific time in place to convert the "UAT" once into 
dejagnu format)?



Thanks for giving me some context on this,
Simon


[1]: 
https://gitlab.cobolworx.com/COBOLworx/gcc-cobol/-/tree/master+cobol/gcc/cobol/UAT
  

Simon Sobisch <simonsobisch@gnu.org> writes:

> Thanks for your work on adding a testsuite. Can you please explain why
> you do this when a complete testsuite exists in autoconf (autotest)
> format (which roots back to decade of work in GnuCOBOL, with all
> copyrights for that already with the FSF)?
>

I don't think any of us were aware of it ("we" being "the general GCC
developer community", not the COBOL folks, for the purposes of this
email) until yesterday when richi mused about it on IRC maybe existing
and we went looking out of curiosity.

I agree that having that testsuite integrated would be fantastic.

> Is the existence of this in upstream [1] just unknown (because it was
> not part of the initial patches [for reasons I not understood])?
>

I would've personally liked to see the NIST testsuite integration at
least in the initial patches, but it is what it is. I don't think the
GnuCOBOL testsuite was brought up at all (and I think most of us weren't
aware of it) in the patch upstreaming discussions.

Now that we *are* aware of it, it seems desirable to have for sure.

> Is the format such a big issue (note: previous discussions elaborated
> "a test suite is very important and other frontends also use a
> framework other than dejagnu)?
>
> If dejagnu is the way to go:
>
> * Shouldn't there be deprecation of autotest in autoconf (of course
>   only if that preference is also outside of gcc)?

It's a GCC / GNU toolchain-only preference because it allows easily
doing cross + simulator testing, and all of our tools are used to its
format.

It's definitely not perfect. Years ago (way before I followed GCC),
there was talk of replacing dejagnu, just efforts failed.

>
> * Shouldn't there be a (at least semi automated) script / migration
>   tool (at least for this specific time in place to convert the "UAT"
>   once into dejagnu format)?

Yes. Having testsuite integration is seen as critical at this
point. richi just wanted to present this as a non-COBOL person to give
us something to play with.

>
>
>
> Thanks for giving me some context on this,
> Simon
>
>
> [1]:
> https://gitlab.cobolworx.com/COBOLworx/gcc-cobol/-/tree/master+cobol/gcc/cobol/UAT

thanks,
sam
  

On Thu, 13 Mar 2025, Sam James wrote:

> Simon Sobisch <simonsobisch@gnu.org> writes:
> 
> > Thanks for your work on adding a testsuite. Can you please explain why
> > you do this when a complete testsuite exists in autoconf (autotest)
> > format (which roots back to decade of work in GnuCOBOL, with all
> > copyrights for that already with the FSF)?
> >
> 
> I don't think any of us were aware of it ("we" being "the general GCC
> developer community", not the COBOL folks, for the purposes of this
> email) until yesterday when richi mused about it on IRC maybe existing
> and we went looking out of curiosity.
> 
> I agree that having that testsuite integrated would be fantastic.
> 
> > Is the existence of this in upstream [1] just unknown (because it was
> > not part of the initial patches [for reasons I not understood])?
> >
> 
> I would've personally liked to see the NIST testsuite integration at
> least in the initial patches, but it is what it is. I don't think the
> GnuCOBOL testsuite was brought up at all (and I think most of us weren't
> aware of it) in the patch upstreaming discussions.
> 
> Now that we *are* aware of it, it seems desirable to have for sure.
> 
> > Is the format such a big issue (note: previous discussions elaborated
> > "a test suite is very important and other frontends also use a
> > framework other than dejagnu)?
> >
> > If dejagnu is the way to go:
> >
> > * Shouldn't there be deprecation of autotest in autoconf (of course
> >   only if that preference is also outside of gcc)?
> 
> It's a GCC / GNU toolchain-only preference because it allows easily
> doing cross + simulator testing, and all of our tools are used to its
> format.

That's indeed the main reason.

> It's definitely not perfect. Years ago (way before I followed GCC),
> there was talk of replacing dejagnu, just efforts failed.
> 
> >
> > * Shouldn't there be a (at least semi automated) script / migration
> >   tool (at least for this specific time in place to convert the "UAT"
> >   once into dejagnu format)?
> 
> Yes. Having testsuite integration is seen as critical at this
> point. richi just wanted to present this as a non-COBOL person to give
> us something to play with.

Yes, and to give people familiar with how GCC tests are done a place
to put regression tests going forward.

I do think that integrating the testsuites the COBOLworx folks have
is important and of course integrating tests from GNU Cobol is desirable
as well.  Whether we can or want to integrate tests based on autotest
is another question - I'd probably avoid that, even as short-term 
solution, as such tend to stay forever.

What would be nice is to have a common separate test harness you can
test an installed compiler against - I'm not sure whether the GNU
Cobol test harness or the COBOLworx one qualifies here.  The NIST
one probably does, but it seems to require "plumbing" that's not
part of NIST and that, in implementation, might differ from GNU Cobol
to COBOLworx.

Richard.

> >
> >
> >
> > Thanks for giving me some context on this,
> > Simon
> >
> >
> > [1]:
> > https://gitlab.cobolworx.com/COBOLworx/gcc-cobol/-/tree/master+cobol/gcc/cobol/UAT
> 
> thanks,
> sam
>
  

> Earlier in this discussion of a testsuite, the question came up about
 > generating an error return in COBOL source code.
 >
 > In COBOL, "GOBACK ERROR 1." is the equivalent of a C "return 1;".
 > When executed in  the initial "top-level" program-id, it results in
 > the value 1 being passed back to the _start stub.
 >
 > "STOP RUN ERROR 1." is the equivalent of (and is in fact implemented
 > with) "exit(1)".
 >
 > Bob D.

Let's speak COBOL here and please re-consider if this is the best option 
available in GCC [note: I'm also interested for the implementation in 
GnuCOBOL, but that's a tangent for this list].

The syntax of the STOP statement and the rules are the following 
("noise" words written in parenthesis, optional items in brackets, pipe 
gives alternatives within braces):

----------------------------------------------------------------------

STOP  RUN
[ (WITH)  { ERROR | NORMAL }  (STATUS)  [ { identifier | literal } ]  ]


rules: literal should be non-zero length, if numeric it should be an 
integer (no sign, no decimal place);
any constraints on the value of the literal or the contents of the 
identifier are  defined by the implementor


If the ERROR phrase is specified, the operating system will indicate an 
error termination of the run unit if such a capability exists within the 
operating system.

If the NORMAL phrase is specified, the operating system will indicate a 
normal termination of the run unit if such a capability exists within 
the operating system.


During execution of the STOP statement with a literal or an identifier 
specified, the literal or the contents of the identifier are passed to 
the operating system.

----------------------------------------------------------------------

exit() allows us to "pass to the operating system" directly; but it 
doesn't directly say "success" or "fail".


Obviously the statements
    STOP RUN WITH NORMAL STATUS 41
and
    STOP RUN ERROR 41

Should have a different result for the operating system.
As those numbers must be unsigned, it could be reasonable to translate 
that to  exit (41)  and  exit (-41).

While a "STOP RUN ERROR 0" would be possible as well, there could be an 
implementor-defined constraint (which can be enforced for literals) that 
zero is not valid.

This would mean that STOP RUN == STOP RUN WITH NORMAL STATUS == STOP RUN 
WITH NORMAL STATUS 0 == exit (0) and
STOP RUN WITH ERROR STATUS == STOP RUN WITH ERROR STATUS 1 == exit (-1)


Then we have additional the question on how to translate

    STOP RUN WITH ERROR "Don't do that, Jon!"

in which case something like

    fflush (stderr);
    fprintf(stderr, "%s\n", "Don't do that, Jon!");
    exit (-1);

or even something along

void cobol_stop_run __attribute__((noreturn))
(int status, char *message) {

    const int exit_status = error ? status * -1 : status;
    const FILE* stream = error ? stderr : stdout;
    const char* prefix = error ?
                               : _("runtime exited with normal status");

    if (error) {
       fflush (stderr );
       fprintf (stderr , _("runtime exited with error status %d: %s\n",
                status, message);
       exit (-status);
    } else {
       fflush (stdout);
       fprintf (stderr , _("runtime exited with normal status %d: %s\n",
                status, message);
       exit (status);
    }
}

Side note: I'd highly suggest to keep abort() for runtime-covered error 
handling (index out of bounds, program not found, ...)

Simon
  

Am 13.03.2025 um 12:49 schrieb Richard Biener:
> On Thu, 13 Mar 2025, Sam James wrote:
> 
>> Simon Sobisch <simonsobisch@gnu.org> writes:
>>
>>> Thanks for your work on adding a testsuite. Can you please explain why
>>> you do this when a complete testsuite exists in autoconf (autotest)
>>> format (which roots back to decade of work in GnuCOBOL, with all
>>> copyrights for that already with the FSF)?
>>>
>>
>> I don't think any of us were aware of it ("we" being "the general GCC
>> developer community", not the COBOL folks, for the purposes of this
>> email) until yesterday when richi mused about it on IRC maybe existing
>> and we went looking out of curiosity.
>>
>> I agree that having that testsuite integrated would be fantastic.
>>
>>> Is the existence of this in upstream [1] just unknown (because it was
>>> not part of the initial patches [for reasons I not understood])?
>>>
>>
>> I would've personally liked to see the NIST testsuite integration at
>> least in the initial patches, but it is what it is. I don't think the
>> GnuCOBOL testsuite was brought up at all (and I think most of us weren't
>> aware of it) in the patch upstreaming discussions.
>>
>> Now that we *are* aware of it, it seems desirable to have for sure.
>>
>>> Is the format such a big issue (note: previous discussions elaborated
>>> "a test suite is very important and other frontends also use a
>>> framework other than dejagnu)?
>>>
>>> If dejagnu is the way to go:
>>>
>>> * Shouldn't there be deprecation of autotest in autoconf (of course
>>>    only if that preference is also outside of gcc)?
>>
>> It's a GCC / GNU toolchain-only preference because it allows easily
>> doing cross + simulator testing, and all of our tools are used to its
>> format.
> 
> That's indeed the main reason.

Thanks for the explanation. That's totally fine.

> 
>> It's definitely not perfect. Years ago (way before I followed GCC),
>> there was talk of replacing dejagnu, just efforts failed.
>>
>>>
>>> * Shouldn't there be a (at least semi automated) script / migration
>>>    tool (at least for this specific time in place to convert the "UAT"
>>>    once into dejagnu format)?
>>
>> Yes. Having testsuite integration is seen as critical at this
>> point. richi just wanted to present this as a non-COBOL person to give
>> us something to play with.
> 
> Yes, and to give people familiar with how GCC tests are done a place
> to put regression tests going forward.
> 
> I do think that integrating the testsuites the COBOLworx folks have
> is important and of course integrating tests from GNU Cobol is desirable
> as well.  Whether we can or want to integrate tests based on autotest
> is another question - I'd probably avoid that, even as short-term
> solution, as such tend to stay forever.

I agree. Note: COBOLworx started by using the GnuCOBOL testsuite; even 
with the current UAT's state it would be a lot of manual work to 
re-synchronize them, so going one step further to dejagnu seems to not 
make it much harder either.
It will definitely be useful if the "original test file names" (like 
run_subscripts.at, or at least run_subscripts) are kept somewhere - a 
comment like "auto-translated from run_subscripts.at" is enough - and 
maybe they can stay in one file each (I don't know enough about dejagnu 
to comment on that).

The main point is that it seems most reasonable to convert those files 
into dejagnu format once (so obviously a "script working good enough, 
not installed" comes into mind), instead of writing it from scratch.

> What would be nice is to have a common separate test harness you can
> test an installed compiler against - I'm not sure whether the GNU
> Cobol test harness or the COBOLworx one qualifies here.  The NIST
> one probably does, but it seems to require "plumbing" that's not
> part of NIST and that, in implementation, might differ from GNU Cobol
> to COBOLworx.

That's a good opportunity to be picky: it is GnuCOBOL (one word, COBOL 
in upper-case) :-)

And yes: a common separate test harness is most reasonable and that's 
exactly what the idea of NIST was.
If you ever wonder: GnuCOBOL uses make (with one sub-directory per 
"Module") along with perl [2].
This allows to not only do testing (or just extraction of the files) 
along with counting and tracking time, but also to automate some of the 
required "needs manual inspection".

And given gcobc, I'd argue that gcobol should not fail the following 
(and ideally show its superior compile and run time):

$> tar -xvf gnucobol-3.*.tar.*
$> cd gnucobol-3.*/
$> ./configure  # for automake and autoconf doing the setup
$> cd tests/cobol85
$> make test COBC=gcobc-15

... just tried that:
gcobol: error: unrecognized command-line option ‘-std=cobol85’

--> seems like the gcobc should drop that and set the right flags for 
gcobol here (I know, should be on bugzilla, or just fixed)


$> make test COBC=gcobc-15 COBC_FLAGS=--debug
Compiling EXEC85 program
warning: --debug implies -fstack-check: ignored
EXEC85.cob:1:73: error: syntax error, unexpected NAME, expecting 
FUNCTION or PROGRAM-ID
     1 | 000100 IDENTIFICATION DIVISION. 
         EXEC84.2
       | 
         ^
cobol1: error: failed compiling EXEC85.cob

--> seems the recognition in cobol1 for the reference-format can be 
improved (that's no *problem* in general)


$> make test COBC=gcobc-15 COBC_FLAGS="-fec=all -fformat=fixed -g"
Compiling EXEC85 program
Building module directory NC ...
/home/build/gcobol-test/gnucobol-3.2/pre-inst-env: 69: exec: ../EXEC85: 
not found


--> that is definitely another problem of the gcobc driver script - if 
no output file is given this must be deduced from the first input file 
to match cobc behavior


$> mv a.out EXEC85
$> make test COBC=gcobc-15 COBC_FLAGS="-fec=all -fformat=fixed -g"
Building module directory NC ...


... that runs until crash.

/bin/bash: Line 6:  6503 Killed                ( cd NC && COB_UNIX_LF=Y 
"/home/build/gcobol-test/gnucobol-3.2/pre-inst-env" ../EXEC85 )


because of some looping (single core completely used, memory fast 
increasing, here's the output from "top" shortly before the 
system-internal kill

   simon     20   0   19,1g  15,1g    960 R  15,0  97,0   1:52.12 EXEC85


Side note: even when the system kills the process, it should have some 
time to write a reasonable stacktrace or something to know where the 
error happened.


I'm quite sure the looping part is related to file handling (rooting in 
configuration that is different for gcobol and GnuCOBOL [which it may 
shouldn't]) but that's for Bob to inspect/fix (I've used the COBOLworx 
debian package generated yesterday, BTW).

... ok, re-executed and attached with GDB - it loops around the READ at 
EXEC.cob:2202, presumably for the non-open file.


With the guessed configuration issue:

* the program should not hog memory during looping (Bob, please inspect
   this one *first*)
* the program should abort somewhere, likely at the OPEN long before it
   gets to the READ where it loops, but that should be fixed after this
   specific "loop creates a memory problem" is fixed  (end then maybe in
   reverse order, first let the READ [directly after the OPEN] of the
   not-opened file abort, then the OPEN itself)  [note: there is neither
   a USE section nor an io-status for the file defined and even the
   -fec-io runtime checks were requested to be enabled, so ISO says that
   this READ (and the OPEN before) should result in a fatal runtime
   abort]

Thanks,
Simon


> 
> Richard.
> 
>>>
>>> [1]:
>>> https://gitlab.cobolworx.com/COBOLworx/gcc-cobol/-/tree/master+cobol/gcc/cobol/UAT

[2]: 
https://sourceforge.net/p/gnucobol/code/HEAD/tree/branches/gnucobol-3.x/tests/cobol85/
  

On Thu, 13 Mar 2025, Simon Sobisch wrote:

> 
> Am 13.03.2025 um 12:49 schrieb Richard Biener:
> > On Thu, 13 Mar 2025, Sam James wrote:
> > 
> >> Simon Sobisch <simonsobisch@gnu.org> writes:
> >>
> >>> Thanks for your work on adding a testsuite. Can you please explain why
> >>> you do this when a complete testsuite exists in autoconf (autotest)
> >>> format (which roots back to decade of work in GnuCOBOL, with all
> >>> copyrights for that already with the FSF)?
> >>>
> >>
> >> I don't think any of us were aware of it ("we" being "the general GCC
> >> developer community", not the COBOL folks, for the purposes of this
> >> email) until yesterday when richi mused about it on IRC maybe existing
> >> and we went looking out of curiosity.
> >>
> >> I agree that having that testsuite integrated would be fantastic.
> >>
> >>> Is the existence of this in upstream [1] just unknown (because it was
> >>> not part of the initial patches [for reasons I not understood])?
> >>>
> >>
> >> I would've personally liked to see the NIST testsuite integration at
> >> least in the initial patches, but it is what it is. I don't think the
> >> GnuCOBOL testsuite was brought up at all (and I think most of us weren't
> >> aware of it) in the patch upstreaming discussions.
> >>
> >> Now that we *are* aware of it, it seems desirable to have for sure.
> >>
> >>> Is the format such a big issue (note: previous discussions elaborated
> >>> "a test suite is very important and other frontends also use a
> >>> framework other than dejagnu)?
> >>>
> >>> If dejagnu is the way to go:
> >>>
> >>> * Shouldn't there be deprecation of autotest in autoconf (of course
> >>>    only if that preference is also outside of gcc)?
> >>
> >> It's a GCC / GNU toolchain-only preference because it allows easily
> >> doing cross + simulator testing, and all of our tools are used to its
> >> format.
> > 
> > That's indeed the main reason.
> 
> Thanks for the explanation. That's totally fine.
> 
> > 
> >> It's definitely not perfect. Years ago (way before I followed GCC),
> >> there was talk of replacing dejagnu, just efforts failed.
> >>
> >>>
> >>> * Shouldn't there be a (at least semi automated) script / migration
> >>>    tool (at least for this specific time in place to convert the "UAT"
> >>>    once into dejagnu format)?
> >>
> >> Yes. Having testsuite integration is seen as critical at this
> >> point. richi just wanted to present this as a non-COBOL person to give
> >> us something to play with.
> > 
> > Yes, and to give people familiar with how GCC tests are done a place
> > to put regression tests going forward.
> > 
> > I do think that integrating the testsuites the COBOLworx folks have
> > is important and of course integrating tests from GNU Cobol is desirable
> > as well.  Whether we can or want to integrate tests based on autotest
> > is another question - I'd probably avoid that, even as short-term
> > solution, as such tend to stay forever.
> 
> I agree. Note: COBOLworx started by using the GnuCOBOL testsuite; even with
> the current UAT's state it would be a lot of manual work to re-synchronize
> them, so going one step further to dejagnu seems to not make it much harder
> either.
> It will definitely be useful if the "original test file names" (like
> run_subscripts.at, or at least run_subscripts) are kept somewhere - a comment
> like "auto-translated from run_subscripts.at" is enough - and maybe they can
> stay in one file each (I don't know enough about dejagnu to comment on that).
> 
> The main point is that it seems most reasonable to convert those files into
> dejagnu format once (so obviously a "script working good enough, not
> installed" comes into mind), instead of writing it from scratch.

Definitely.

> > What would be nice is to have a common separate test harness you can
> > test an installed compiler against - I'm not sure whether the GNU
> > Cobol test harness or the COBOLworx one qualifies here.  The NIST
> > one probably does, but it seems to require "plumbing" that's not
> > part of NIST and that, in implementation, might differ from GNU Cobol
> > to COBOLworx.
> 
> That's a good opportunity to be picky: it is GnuCOBOL (one word, COBOL in
> upper-case) :-)
> 
> And yes: a common separate test harness is most reasonable and that's exactly
> what the idea of NIST was.
> If you ever wonder: GnuCOBOL uses make (with one sub-directory per "Module")
> along with perl [2].
> This allows to not only do testing (or just extraction of the files) along
> with counting and tracking time, but also to automate some of the required
> "needs manual inspection".
> 
> And given gcobc, I'd argue that gcobol should not fail the following (and
> ideally show its superior compile and run time):
> 
> $> tar -xvf gnucobol-3.*.tar.*
> $> cd gnucobol-3.*/
> $> ./configure  # for automake and autoconf doing the setup
> $> cd tests/cobol85
> $> make test COBC=gcobc-15
> 
> ... just tried that:
> gcobol: error: unrecognized command-line option ‘-std=cobol85’
> 
> --> seems like the gcobc should drop that and set the right flags for 
> gcobol here (I know, should be on bugzilla, or just fixed)
> 
> 
> $> make test COBC=gcobc-15 COBC_FLAGS=--debug
> Compiling EXEC85 program
> warning: --debug implies -fstack-check: ignored
> EXEC85.cob:1:73: error: syntax error, unexpected NAME, expecting FUNCTION or
> PROGRAM-ID
>     1 | 000100 IDENTIFICATION DIVISION. 
>         EXEC84.2
>       | 
>         ^
> cobol1: error: failed compiling EXEC85.cob
> 
> --> seems the recognition in cobol1 for the reference-format can be 
> improved (that's no *problem* in general)
> 
> 
> $> make test COBC=gcobc-15 COBC_FLAGS="-fec=all -fformat=fixed -g"
> Compiling EXEC85 program
> Building module directory NC ...
> /home/build/gcobol-test/gnucobol-3.2/pre-inst-env: 69: exec: ../EXEC85: not
> found
> 
> 
> --> that is definitely another problem of the gcobc driver script - if 
> no output file is given this must be deduced from the first input file to
> match cobc behavior

Thanks for doing this!  It's exactly what we want at this point - people
trying and finding bugs.  It would be super useful if you'd record
bugzilla issues for each of the above on https://gcc.gnu.org/bugzilla

Compatibility of gcobc is likely quite important.

> 
> $> mv a.out EXEC85
> $> make test COBC=gcobc-15 COBC_FLAGS="-fec=all -fformat=fixed -g"
> Building module directory NC ...
> 
> 
> ... that runs until crash.
> 
> /bin/bash: Line 6:  6503 Killed                ( cd NC && COB_UNIX_LF=Y
> "/home/build/gcobol-test/gnucobol-3.2/pre-inst-env" ../EXEC85 )
> 
> 
> because of some looping (single core completely used, memory fast increasing,
> here's the output from "top" shortly before the system-internal kill
> 
>   simon     20   0   19,1g  15,1g    960 R  15,0  97,0   1:52.12 EXEC85
> 
> 
> Side note: even when the system kills the process, it should have some time to
> write a reasonable stacktrace or something to know where the error happened.

Unfortunatelly a KILL from the system is fatal, no way to record anything.

> 
> I'm quite sure the looping part is related to file handling (rooting in
> configuration that is different for gcobol and GnuCOBOL [which it may
> shouldn't]) but that's for Bob to inspect/fix (I've used the COBOLworx debian
> package generated yesterday, BTW).
> 
> ... ok, re-executed and attached with GDB - it loops around the READ at
> EXEC.cob:2202, presumably for the non-open file.
> 
> 
> With the guessed configuration issue:
> 
> * the program should not hog memory during looping (Bob, please inspect
>   this one *first*)
> * the program should abort somewhere, likely at the OPEN long before it
>   gets to the READ where it loops, but that should be fixed after this
>   specific "loop creates a memory problem" is fixed  (end then maybe in
>   reverse order, first let the READ [directly after the OPEN] of the
>   not-opened file abort, then the OPEN itself)  [note: there is neither
>   a USE section nor an io-status for the file defined and even the
>   -fec-io runtime checks were requested to be enabled, so ISO says that
>   this READ (and the OPEN before) should result in a fatal runtime
>   abort]
> 
> Thanks,
> Simon
> 
> 
> > 
> > Richard.
> > 
> >>>
> >>> [1]:
> >>> https://gitlab.cobolworx.com/COBOLworx/gcc-cobol/-/tree/master+cobol/gcc/cobol/UAT
> 
> [2]:
> https://sourceforge.net/p/gnucobol/code/HEAD/tree/branches/gnucobol-3.x/tests/cobol85/
>
  

On Tue, 11 Mar 2025 14:40:19 +0100 (CET)
Richard Biener <rguenther@suse.de> wrote:

> > Looking at pretty much all of the above, it seems very Fortran
> > specific with its weird diagnostic output (capital Warning:/Error:,
> > the (1) and (2) in the diagnostics with later printing of those
> > lines and the like. Unless cobol1 does it the same, this should be
> > replaced with what is done for other FEs (likely almost nothing).
> 
> OK, I've done that and amended the set of testcases with one
> exercising dg-error.  I had to prune the sprious
> 
> cobol1: error: failed compiling t.cob
> 
> message we emit.  I don't see any warnings emitted from the frontend
> and wasn't able to create a Cobol program where the middle-end 
> would emit one.
> 
> I'll wait for an ACK from the Cobol folks before pushing.

ok by me, and thanks.

--jkl
  

On Thu, 2025-03-13 at 12:11 +0100, Simon Sobisch wrote:
> Thanks for your work on adding a testsuite. Can you please explain
> why 
> you do this when a complete testsuite exists in autoconf (autotest) 
> format (which roots back to decade of work in GnuCOBOL, with all 
> copyrights for that already with the FSF)?
> 
> Is the existence of this in upstream [1] just unknown (because it was
> not part of the initial patches [for reasons I not understood])?
> 
> Is the format such a big issue (note: previous discussions elaborated
> "a 
> test suite is very important and other frontends also use a framework
> other than dejagnu)?
> 
> If dejagnu is the way to go:
> 
> * Shouldn't there be deprecation of autotest in autoconf (of course
> only 
> if that preference is also outside of gcc)?
> 
> * Shouldn't there be a (at least semi automated) script / migration
> tool 
> (at least for this specific time in place to convert the "UAT" once
> into 
> dejagnu format)?
> 
> 
> 
> Thanks for giving me some context on this,
> Simon
> 
> 
> [1]: 
> https://gitlab.cobolworx.com/COBOLworx/gcc-cobol/-/tree/master+cobol/gcc/cobol/UAT
> 

Hi Simon

Does the UAT testsuite have coverage for what happens on invalid code?
 
For example, in
https://gcc.gnu.org/pipermail/gcc-patches/2025-March/677481.html
my patch adds test coverage for the output on one kind of typo (or, at
least, I tried to, my knowledge of COBOL is essentially 0); I put this
in Richard's DejaGnu suite since I have lots of similar tests for other
frontends.

Having a good user experience on incorrect code is important, so we
need some kind of test coverage for this.  The new DejaGnu-based tests
seem to work well for that (as per the patch).  I don't know if this is
something that could/should be shared with GnuCOBOL, given that there
might well be differences in error-handling behavior between GCC COBOL
and GnuCOBOL.

Thoughts?
Dave
  

Am 13.03.2025 um 21:35 schrieb David Malcolm:
> On Thu, 2025-03-13 at 12:11 +0100, Simon Sobisch wrote:
>> Thanks for your work on adding a testsuite. Can you please explain
>> why
>> you do this when a complete testsuite exists in autoconf (autotest)
>> format (which roots back to decade of work in GnuCOBOL, with all
>> copyrights for that already with the FSF)?
>>
>> Is the existence of this in upstream [1] just unknown (because it was
>> not part of the initial patches [for reasons I not understood])?
>>
>> Is the format such a big issue (note: previous discussions elaborated
>> "a
>> test suite is very important and other frontends also use a framework
>> other than dejagnu)?
>>
>> If dejagnu is the way to go:
>>
>> * Shouldn't there be deprecation of autotest in autoconf (of course
>> only
>> if that preference is also outside of gcc)?
>>
>> * Shouldn't there be a (at least semi automated) script / migration
>> tool
>> (at least for this specific time in place to convert the "UAT" once
>> into
>> dejagnu format)?
>>
>>
>>
>> Thanks for giving me some context on this,
>> Simon
>>
>>
>> [1]:
>> https://gitlab.cobolworx.com/COBOLworx/gcc-cobol/-/tree/master+cobol/gcc/cobol/UAT
>>
> 
> Hi Simon
> 
> Does the UAT testsuite have coverage for what happens on invalid code?
>   
> For example, in
> https://gcc.gnu.org/pipermail/gcc-patches/2025-March/677481.html
> my patch adds test coverage for the output on one kind of typo (or, at
> least, I tried to, my knowledge of COBOL is essentially 0); I put this
> in Richard's DejaGnu suite since I have lots of similar tests for other
> frontends.

Yes. That is what the "syn" tests are about, for example
https://gitlab.cobolworx.com/COBOLworx/gcc-cobol/-/blob/master+cobol/gcc/cobol/UAT/testsuite.src/syn_value.at


# Unexpected return code 0 failure - We don't implement
# type checking TODO
AT_DATA([prog.cob], [
        IDENTIFICATION   DIVISION.
        PROGRAM-ID.      prog.
        DATA             DIVISION.
        WORKING-STORAGE  SECTION.
       * Gnu throws ERROR on next line TODO
        01 X-SPACE       PIC 999 VALUE SPACE.
       * Gnu Throws WARNING on next two lines TODO
        01 X-ABC         PIC 999 VALUE "abc".
        01 X-12-3        PIC 999 VALUE 12.3.
        01 X-123         PIC 999 VALUE 123.
       * Gnu Throws WARNING on next line
        01 X-1234        PIC 999 VALUE 1234.
        PROCEDURE        DIVISION.
            STOP RUN.
])
AT_CHECK([$COMPILE_ONLY prog.cob], [1], ,
[prog.cob:7:25: error: numeric type X-SPACE VALUE 'SPACES' requires 
numeric VALUE
     7 |        01 X-SPACE       PIC 999 VALUE SPACE.
       |                         ^
prog.cob:9:25: error: numeric type X-ABC VALUE 'abc' requires numeric VALUE
     9 |        01 X-ABC         PIC 999 VALUE "abc".
       |                         ^
prog.cob:10:25: error: integer type X-12-3 VALUE '12.3' requires integer 
VALUE
    10 |        01 X-12-3        PIC 999 VALUE 12.3.
       |                         ^
prog.cob:13:25: error: numeric X-1234 VALUE '1234' holds only 3 digits
    13 |        01 X-1234        PIC 999 VALUE 1234.
       |                         ^
cobol1: error: failed compiling prog.cob
])


Notes:

* in GnuCOBOL we have specific tests that check the "extended" format
   with context; in all other cases we pass (as part of the $COMPILE
   above)  -fdiagnostics-plain-output - because we only want the user
   message, not the formatting tested overall - and producing and
   comparing less output also saves some (minor) computation

* I'd definitely suggest that UAT is adjusted similar before the
   conversion for the same reasons

* as hinted in the UAT notes above, GnuCOBOL test results are different,
   here the original result from the file this test in UAT was based on:

prog.cob:6: error: invalid VALUE clause
prog.cob:7: warning: numeric value is expected
prog.cob:8: warning: value size exceeds data size
prog.cob:10: warning: value size exceeds data size

[note: according to ISO those should all be errors, but other COBOL 
implementations don't care and truncate "per MOVE rules", so cobc's 
default is a warning here]

Just for your amusement, that's GC 3.2's output (with -Wall)

prog.cob:6: error: invalid VALUE clause
     4 |        DATA             DIVISION.
     5 |        WORKING-STORAGE  SECTION.
     6 >        01 X-SPACE       PIC 999 VALUE SPACE.
     7 |        01 X-ABC         PIC 999 VALUE "abc".
     8 |        01 X-12-3        PIC 999 VALUE 12.3.
prog.cob:7: warning: numeric value is expected [-Wothers]
     5 |        WORKING-STORAGE  SECTION.
     6 |        01 X-SPACE       PIC 999 VALUE SPACE.
     7 >        01 X-ABC         PIC 999 VALUE "abc".
     8 |        01 X-12-3        PIC 999 VALUE 12.3.
     9 |        01 X-123         PIC 999 VALUE 123.
prog.cob:8: warning: value size exceeds data size [-Wothers]
     6 |        01 X-SPACE       PIC 999 VALUE SPACE.
     7 |        01 X-ABC         PIC 999 VALUE "abc".
     8 >        01 X-12-3        PIC 999 VALUE 12.3.
     9 |        01 X-123         PIC 999 VALUE 123.
    10 |        01 X-1234        PIC 999 VALUE 1234.
prog.cob:10: warning: value size exceeds data size [-Wothers]
     8 |        01 X-12-3        PIC 999 VALUE 12.3.
     9 |        01 X-123         PIC 999 VALUE 123.
    10 >        01 X-1234        PIC 999 VALUE 1234.
    11 |        PROCEDURE        DIVISION.
    12 |            STOP RUN.

> Having a good user experience on incorrect code is important, so we
> need some kind of test coverage for this.  The new DejaGnu-based tests
> seem to work well for that (as per the patch).  I don't know if this is
> something that could/should be shared with GnuCOBOL, given that there
> might well be differences in error-handling behavior between GCC COBOL
> and GnuCOBOL.

I totally agree for the user need of good experience on incorrect code 
(and libgdiagnostic will likely help - possibly also GnuCOBOL users - to 
have some nice features that GCC does without reimplementing everything).

Testing for that is important for many reasons (one is: you want to 
ensure the compiler does not crash) - and that test should include the 
user-visible part, which should "work" also without context (the gcobol 
ones above do, the cobc ones doesn't).

But as gcobol's and GnuCOBOL's parser and frontend is quite different, I 
don't see a way to have an easy common testbed.
One option that would be marvelous would be a test checking both cobc's 
and gcobol's messages (and with the use of gcobc it could also use the 
same invocation) - but as noted that would have to include two 
"conditional" expected outputs. So far no one jumped and said "here, I 
wanna do that work"...

> Thoughts?
> Dave

Simon
  

On Wed, 12 Mar 2025, Jakub Jelinek wrote:

> On Tue, Mar 11, 2025 at 10:06:27PM -0500, Robert Dubner wrote:

> On Linux at least when not cross-compiling, exit(1) (or this
> STOP RUN ERROR 1) will work as well, I believe the reason is for some
> bare metal targets which just don't propagate return value from main or
> exit back to the dejagnu testing framework.

A refresh on those bits (read: I revisited 
/usr/share/dejagnu/testglue.c).

The dejagnu testglue.c propagates exit(1) just fine, it'll cause 
writing "*** EXIT CODE 1\n" to fileno 1 before actually exiting.
(I'll propagate the N in exit(N), not just 1.)

> Does COBOL have something that is implemented as call to abort()?

That'll cause writing "*** EXIT CODE 4242\n" to fileno 1.

All handled by dejagnu and the GNU linker "--wrap" option.

brgds, H-P
/Maintainer of one such target
  

On Mar 13, 2025, at 8:04 AM, Simon Sobisch <simonsobisch@gnu.org> wrote:
> 
> exit() allows us to "pass to the operating system" directly; but it doesn't directly say "success" or "fail".
> 
> 
> Obviously the statements
>   STOP RUN WITH NORMAL STATUS 41
> and
>   STOP RUN ERROR 41
> 
> Should have a different result for the operating system.

Or, obviously not.  

For OSes I'm familiar with, there is no *definition* of success/failure.  There's just convention: 0 is success and nonzero failure.  Even that is honored in the breach, see diff(1).  

IMO unless the OS defines success/failure outside the value of the exit status value (above, 41), the COBOL compiler cannot supply meaning to STOP RUN NORMAL or ERROR.  It has no meaning in COBOL because it has no meaning outside COBOL.  

By that reasoning, the two statements above both return 41 because there is no way to say more.  It is for the caller to decide what to do.  

I do not think -41 is an option; the compiler should not make arbitrary changes to the user's data.  

It is temping to raise(SIG_TERM) for error, but again the 41 is lost.  

> STOP RUN WITH ERROR "Don't do that, Jon!"

When no numeric value is supplied, IMO: 

    • STOP RUN WITH NORMAL STATUS becomes exit(EXIT_SUCCESS)
    • STOP RUN WITH ERROR becomes exit(EXIT_FAILURE)

That satisfies the Principle of Least Astonishment.  BTW those values are defined by C, not POSIX.  

--jkl
  

Am 20.03.2025 um 21:50 schrieb James K. Lowden:
> On Mar 13, 2025, at 8:04 AM, Simon Sobisch <simonsobisch@gnu.org> wrote:
>>
>> exit() allows us to "pass to the operating system" directly; but it doesn't directly say "success" or "fail".
>>
>>
>> Obviously the statements
>>    STOP RUN WITH NORMAL STATUS 41
>> and
>>    STOP RUN ERROR 41
>>
>> Should have a different result for the operating system.
> 
> Or, obviously not.
> 
> For OSes I'm familiar with, there is no *definition* of success/failure.  There's just convention: 0 is success and nonzero failure.  Even that is honored in the breach, see diff(1).
> 
> IMO unless the OS defines success/failure outside the value of the exit status value (above, 41), the COBOL compiler cannot supply meaning to STOP RUN NORMAL or ERROR.  It has no meaning in COBOL because it has no meaning outside COBOL.
> 
> By that reasoning, the two statements above both return 41 because there is no way to say more.  It is for the caller to decide what to do.
> 
> I do not think -41 is an option; the compiler should not make arbitrary changes to the user's data.
> 
> It is temping to raise(SIG_TERM) for error, but again the 41 is lost.
> 
>> STOP RUN WITH ERROR "Don't do that, Jon!"
> 
> When no numeric value is supplied, IMO:
> 
>      • STOP RUN WITH NORMAL STATUS becomes exit(EXIT_SUCCESS)
>      • STOP RUN WITH ERROR becomes exit(EXIT_FAILURE)
> 
> That satisfies the Principle of Least Astonishment.  BTW those values are defined by C, not POSIX.
> 
> --jkl


I agree that this could be a reasonable approach:
* STOP RUN WITH NORMAL STATUS becomes exit(EXIT_SUCCESS)
* STOP RUN WITH ERROR becomes exit(EXIT_FAILURE)
* Any text given goes to an internal DISPLAY (_possibly_ WITH ERROR
   doing a DISPLAY UPON SYSERR)

If I'd not now that "some heavy business applications" actually pass the 
error using specific values (one for deadlock, another for general db 
issues, one for logic issues, ...) I'd say "screw the numbers - just 
DISPLAY them".

But a combined option would be possible as well:

* output a text of "STOP ... WITH ERROR" is then noted by still doing
   exit(number_given_if_none_then_EXIT_FAILURE), but always after an
   internal DISPLAY "STOP WITH ERROR[ nr][: message]" UPON SYSERR"
* output a text of "STOP ... WITH NORMAL STATUS" is then noted by
   still doing  exit(number_given_if_none_then_EXIT_SUCCESS),
   and (possibly only in case of a text or number given) an internal
   DISPLAY "STOP WITH NORMAL STATUS[ nr][: message]" UPON SYSOUT"

Opinions?


Simon
  

> Am 20.03.2025 um 21:50 schrieb James K. Lowden:
>> On Mar 13, 2025, at 8:04 AM, Simon Sobisch <simonsobisch@gnu.org> wrote:
>>>
>>> exit() allows us to "pass to the operating system" directly; but it doesn't directly say "success" or "fail".
>>>
>>>
>>> Obviously the statements
>>>    STOP RUN WITH NORMAL STATUS 41
>>> and
>>>    STOP RUN ERROR 41
>>>
>>> Should have a different result for the operating system.
>> Or, obviously not.
>> For OSes I'm familiar with, there is no *definition* of
>> success/failure.  There's just convention: 0 is success and nonzero
>> failure.  Even that is honored in the breach, see diff(1).
>> IMO unless the OS defines success/failure outside the value of the
>> exit status value (above, 41), the COBOL compiler cannot supply
>> meaning to STOP RUN NORMAL or ERROR.  It has no meaning in COBOL
>> because it has no meaning outside COBOL.
>> By that reasoning, the two statements above both return 41 because
>> there is no way to say more.  It is for the caller to decide what to
>> do.
>> I do not think -41 is an option; the compiler should not make
>> arbitrary changes to the user's data.
>> It is temping to raise(SIG_TERM) for error, but again the 41 is
>> lost.
>> 
>>> STOP RUN WITH ERROR "Don't do that, Jon!"
>> When no numeric value is supplied, IMO:
>>      • STOP RUN WITH NORMAL STATUS becomes exit(EXIT_SUCCESS)
>>      • STOP RUN WITH ERROR becomes exit(EXIT_FAILURE)
>> That satisfies the Principle of Least Astonishment.  BTW those
>> values are defined by C, not POSIX.
>> --jkl
>
>
> I agree that this could be a reasonable approach:
> * STOP RUN WITH NORMAL STATUS becomes exit(EXIT_SUCCESS)
> * STOP RUN WITH ERROR becomes exit(EXIT_FAILURE)
> * Any text given goes to an internal DISPLAY (_possibly_ WITH ERROR
>   doing a DISPLAY UPON SYSERR)
>
> If I'd not now that "some heavy business applications" actually pass
> the error using specific values (one for deadlock, another for general
> db issues, one for logic issues, ...) I'd say "screw the numbers -
> just DISPLAY them".

So:

  STOP RUN
  EXIT PROGRAM

  should:

  exit (EXIT_SUCCESS).

Then:

  STOP RUN WITH NORMAL STATUS <number>

  should:

  fprintf (stderr, "STOPPED WITH NORMAL STATUS %d", number);
  exit (EXIT_SUCCESS);

Then:

  STOP RUN WITH ERROR STATUS <number>

  should:

  fprintf (stderr, "STOPPED WITH ERROR STATUS %d", number);
  exit (EXIT_FAILURE);

?

> But a combined option would be possible as well:
>
> * output a text of "STOP ... WITH ERROR" is then noted by still doing
>   exit(number_given_if_none_then_EXIT_FAILURE), but always after an
>   internal DISPLAY "STOP WITH ERROR[ nr][: message]" UPON SYSERR"
> * output a text of "STOP ... WITH NORMAL STATUS" is then noted by
>   still doing  exit(number_given_if_none_then_EXIT_SUCCESS),
>   and (possibly only in case of a text or number given) an internal
>   DISPLAY "STOP WITH NORMAL STATUS[ nr][: message]" UPON SYSOUT"
>
> Opinions?
  

Am 21.03.2025 um 11:50 schrieb Jose E. Marchesi:
> 
>> Am 20.03.2025 um 21:50 schrieb James K. Lowden:
>>> On Mar 13, 2025, at 8:04 AM, Simon Sobisch <simonsobisch@gnu.org> wrote:
>>>>
>>>> exit() allows us to "pass to the operating system" directly; but it doesn't directly say "success" or "fail".
>>>>
>>>>
>>>> Obviously the statements
>>>>     STOP RUN WITH NORMAL STATUS 41
>>>> and
>>>>     STOP RUN ERROR 41
>>>>
>>>> Should have a different result for the operating system.
>>> Or, obviously not.
>>> For OSes I'm familiar with, there is no *definition* of
>>> success/failure.  There's just convention: 0 is success and nonzero
>>> failure.  Even that is honored in the breach, see diff(1).
>>> IMO unless the OS defines success/failure outside the value of the
>>> exit status value (above, 41), the COBOL compiler cannot supply
>>> meaning to STOP RUN NORMAL or ERROR.  It has no meaning in COBOL
>>> because it has no meaning outside COBOL.
>>> By that reasoning, the two statements above both return 41 because
>>> there is no way to say more.  It is for the caller to decide what to
>>> do.
>>> I do not think -41 is an option; the compiler should not make
>>> arbitrary changes to the user's data.
>>> It is temping to raise(SIG_TERM) for error, but again the 41 is
>>> lost.
>>>
>>>> STOP RUN WITH ERROR "Don't do that, Jon!"
>>> When no numeric value is supplied, IMO:
>>>       • STOP RUN WITH NORMAL STATUS becomes exit(EXIT_SUCCESS)
>>>       • STOP RUN WITH ERROR becomes exit(EXIT_FAILURE)
>>> That satisfies the Principle of Least Astonishment.  BTW those
>>> values are defined by C, not POSIX.
>>> --jkl
>>
>>
>> I agree that this could be a reasonable approach:
>> * STOP RUN WITH NORMAL STATUS becomes exit(EXIT_SUCCESS)
>> * STOP RUN WITH ERROR becomes exit(EXIT_FAILURE)
>> * Any text given goes to an internal DISPLAY (_possibly_ WITH ERROR
>>    doing a DISPLAY UPON SYSERR)
>>
>> If I'd not now that "some heavy business applications" actually pass
>> the error using specific values (one for deadlock, another for general
>> db issues, one for logic issues, ...) I'd say "screw the numbers -
>> just DISPLAY them".
> 
> So:
> 
>    STOP RUN
>    EXIT PROGRAM

That's not identical, EXIT PROGRAM just leaves the current module (if 
any, otherwise falls through),

> 
>    should:
> 
>    exit (EXIT_SUCCESS).

yes

> 
> Then:
> 
>    STOP RUN WITH NORMAL STATUS <number>
> 
>    should:
> 
>    fprintf (stderr, "STOPPED WITH NORMAL STATUS %d", number);
>    exit (EXIT_SUCCESS);

no, applications already require the option to set that <number> as 
return code to the OS.

> 
> Then:
> 
>    STOP RUN WITH ERROR STATUS <number>
> 
>    should:
> 
>    fprintf (stderr, "STOPPED WITH ERROR STATUS %d", number);
>    exit (EXIT_FAILURE);

same here - error code needed to OS.


Note that:

STOP RUN WITH ERROR

would be

    fprintf (stderr, "STOPPED WITH ERROR");
    exit (EXIT_FAILURE);


and additional both have an optional literal (instead of the number)

STOP RUN WITH ERROR "Bad boy"

STOP RUN WITH alphanumeric-variable
   *> possibly containing something like "order 999 was proceeded".


In this case we have exit (EXIT_SUCESS/EXIT_FAILURE) and

    fprintf (stderr, "STOPPED WITH ERROR %s", message);
    fprintf (stderr, "STOPPED NORMAL WITH MESSAGE %s", message);

or similar (and the stop message would likely be not all-caps and put 
under gettext, of course)

Simon
  

On Fri, 21 Mar 2025 11:50:19 +0100
"Jose E. Marchesi" <jose.marchesi@oracle.com> wrote:

> 
> > Am 20.03.2025 um 21:50 schrieb James K. Lowden:
> >> On Mar 13, 2025, at 8:04 AM, Simon Sobisch <simonsobisch@gnu.org>
> >> wrote:
> >>>
> >>> exit() allows us to "pass to the operating system" directly; but
> >>> it doesn't directly say "success" or "fail".
> >>>
> >>>
> >>> Obviously the statements
> >>>    STOP RUN WITH NORMAL STATUS 41
> >>> and
> >>>    STOP RUN ERROR 41
> >>>
> >>> Should have a different result for the operating system.
> >> Or, obviously not.
> >> For OSes I'm familiar with, there is no *definition* of
> >> success/failure.  There's just convention: 0 is success and nonzero
> >> failure.  Even that is honored in the breach, see diff(1).
> >> IMO unless the OS defines success/failure outside the value of the
> >> exit status value (above, 41), the COBOL compiler cannot supply
> >> meaning to STOP RUN NORMAL or ERROR.  It has no meaning in COBOL
> >> because it has no meaning outside COBOL.
> >> By that reasoning, the two statements above both return 41 because
> >> there is no way to say more.  It is for the caller to decide what
> >> to do.
> >> I do not think -41 is an option; the compiler should not make
> >> arbitrary changes to the user's data.
> >> It is temping to raise(SIG_TERM) for error, but again the 41 is
> >> lost.
> >> 
> >>> STOP RUN WITH ERROR "Don't do that, Jon!"
> >> When no numeric value is supplied, IMO:
> >>      ? STOP RUN WITH NORMAL STATUS becomes exit(EXIT_SUCCESS)
> >>      ? STOP RUN WITH ERROR becomes exit(EXIT_FAILURE)
> >> That satisfies the Principle of Least Astonishment.  BTW those
> >> values are defined by C, not POSIX.
> >> --jkl
> >
> >
> > I agree that this could be a reasonable approach:
> > * STOP RUN WITH NORMAL STATUS becomes exit(EXIT_SUCCESS)
> > * STOP RUN WITH ERROR becomes exit(EXIT_FAILURE)
> > * Any text given goes to an internal DISPLAY (_possibly_ WITH ERROR
> >   doing a DISPLAY UPON SYSERR)
> >
> > If I'd not now that "some heavy business applications" actually pass
> > the error using specific values (one for deadlock, another for
> > general db issues, one for logic issues, ...) I'd say "screw the
> > numbers - just DISPLAY them".
> 
> So:
> 
>   STOP RUN
>   EXIT PROGRAM
> 
>   should:
> 
>   exit (EXIT_SUCCESS).
> 
> Then:
> 
>   STOP RUN WITH NORMAL STATUS <number>
> 
>   should:
> 
>   fprintf (stderr, "STOPPED WITH NORMAL STATUS %d", number);
>   exit (EXIT_SUCCESS);
> 
> Then:
> 
>   STOP RUN WITH ERROR STATUS <number>
> 
>   should:
> 
>   fprintf (stderr, "STOPPED WITH ERROR STATUS %d", number);
>   exit (EXIT_FAILURE);
> 
> ?

My executive summary would be: 

* STOP RUN WITH <any> STATUS <number>
	exit(<number>) 
* STOP RUN WITH NORMAL STATUS <message>
	display <message>
	exit(EXIT_SUCCESS)
* STOP RUN WITH ERROR STATUS <message>
	display <message>
	exit(EXIT_FAILURE)

In 2025 we want to elaborate our trace functionality by writing to
syslog (where supported).  For example, with LOG_NOTICE, enabled but
unhandled Exception Conditions should be logged when raised, whether or
not fatal, for the user's edification.  Similarly,  

	STOP RUN WITH ERROR STATUS 42.

would record the fact of "error status" in the log, where the careful
user can respond accordingly (maybe by changing the program).  

As a reminder, syslog messages can be copied to standard error with
LOG_PERROR.  That feature could be turned on with a command-line option
or environment variable.  

--jkl