[Bug cobol/119776] COBOL '-fmax-errors', 'Separate'

2025-04-14 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119776

--- Comment #3 from GCC Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:e0b57c75e6daa1664bea03ce96733bf1ebb38ced

commit r15-9457-ge0b57c75e6daa1664bea03ce96733bf1ebb38ced
Author: Jakub Jelinek 
Date:   Mon Apr 14 19:33:11 2025 +0200

cobol: Fix -fmax-errors option [PR119776]

There seems to be inconsistency in the -fmax-errors option
naming.  It is a generic option in common.opt (so applies
to all languages) but with the = character in it.
The gcobol.1 man page in one spot documents the generic
option (in the syntax, -fmax-errors=nerror) but in another
spot without the = character.

In common.opt it is
fmax-errors=
Common Joined RejectNegative UInteger Var(flag_max_errors)
-fmax-errors=   Maximum number of errors to report.

I hope the cobol addition is just a mistake, having -fmax-errors variant
without = character when Joined Separate would allow to specify
-fmax-errors 10 with the same meaning as -fmax-errors=10
but also -fmax-errors10 with the same meaning which is just weird.
Also, there is no UInteger and RejectNegative on it, so one can
also specific -fno-max-errors42 or -fmax-errors blah.

So, unless the spelling without = is intentional, here is a patch
to just remove it, the common option already should have arranged
for flag_max_errors to be set to the right number.

Or if it is intentional, I guess we'd need to at least add
RejectNegative UInteger (plus using atoi is generally undesirable
anywhere in the compiler because it does no error checking).
And the man page would need to be updated to specify both forms.

2025-04-14  Jakub Jelinek  

PR cobol/119776
* lang.opt (fmax-errors): Remove.
* lang.opt.urls: Regenerate.
* cobol1.cc (cobol_langhook_handle_option) :
Remove.
* gcobol.1: Document -fmax-errors=nerror rather than
-fmax-errors nerror.

[Bug cobol/119776] COBOL '-fmax-errors', 'Separate'

2025-04-14 Thread jakub at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119776

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |15.0
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Status|NEW |RESOLVED

--- Comment #4 from Jakub Jelinek  ---
Fixed.

[Bug cobol/119776] COBOL '-fmax-errors', 'Separate'

2025-04-14 Thread jakub at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119776

Jakub Jelinek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||jakub at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2025-04-14

--- Comment #1 from Jakub Jelinek  ---
Even the man page is inconsistent.
 gcobol [-Dname[=value]] [-E] [-fdefaultbyte=value] [-fsyntax-only]
[-Icopybook-path] [-fmax-errors=nerror] [-nomain | -main filename |
-main=filename
(here it documents the -fmax-errors=nerror form) and
and
 -fmax-errors nerror
  nerror represents the number of error messages produced.  Without
this option, gcobol attempts to recover from a syntax error by resuming
compilation at the next
  statement, continuing until end-of-file.  With it, gcobol counts
the messages as they're produced, and stops when nerror is reached.
where it doesn't use =.

So, unless it is intentional to also support -fmax-errors nerror form I'd go
for
2025-04-14  Jakub Jelinek  

PR cobol/119776
* lang.opt (fmax-errors): Remove.
* lang.opt.urls: Regenerate.
* cobol1.cc (cobol_langhook_handle_option): Use OPT_fmax_errors_
rather than OPT_fmax_errors.
* gcobol.1: Document -fmax-errors=nerror rather than
-fmax-errors nerror.

--- gcc/cobol/lang.opt.jj   2025-04-14 11:08:31.808821317 +0200
+++ gcc/cobol/lang.opt  2025-04-14 11:20:52.369700721 +0200
@@ -89,10 +89,6 @@ finternal-ebcdic
 Cobol Var(cobol_ebcdic, 1) Init(0)
 -finternal-ebcdic  Internal processing is in EBCDIC Code Page 1140

-fmax-errors
-Cobol Joined Separate
-; Documented in C
-
 fstatic-call
 Cobol Var(cobol_static_call, 1) Init(1)
 Enable/disable static linkage for CALL literals
--- gcc/cobol/lang.opt.urls.jj  2025-04-14 10:57:06.579176798 +0200
+++ gcc/cobol/lang.opt.urls 2025-04-14 11:21:03.157553577 +0200
@@ -16,9 +16,6 @@ LangUrlSuffix_Fortran(gfortran/Fortran-D
 ffree-form
 LangUrlSuffix_Fortran(gfortran/Fortran-Dialect-Options.html#index-ffree-form)

-fmax-errors
-UrlSuffix(gcc/Warning-Options.html#index-fmax-errors)
LangUrlSuffix_D(gdc/Warnings.html#index-fmax-errors)
-
 iprefix
 UrlSuffix(gcc/Directory-Options.html#index-iprefix)
LangUrlSuffix_D(gdc/Directory-Options.html#index-iprefix)
LangUrlSuffix_Fortran(gfortran/Preprocessing-Options.html#index-iprefix)

--- gcc/cobol/cobol1.cc.jj  2025-04-14 11:09:22.619126924 +0200
+++ gcc/cobol/cobol1.cc 2025-04-14 11:26:23.843179471 +0200
@@ -385,7 +385,7 @@ cobol_langhook_handle_option (size_t sco
 return true;
 }

-case OPT_fmax_errors:
+case OPT_fmax_errors_:
 flag_max_errors = atoi(arg);
 return true;

--- gcc/cobol/gcobol.1.jj   2025-04-08 14:08:48.595318840 +0200
+++ gcc/cobol/gcobol.1  2025-04-14 11:19:17.017003687 +0200
@@ -224,7 +224,7 @@ had appeared.
 Not all exception conditions are implemented.  Any that are not
 produce a warning message.
 .
-.It Fl fmax-errors Ar nerror
+.It Fl fmax-errors Ns Li = Ns Ar nerror
 .Ar nerror
 represents the number of error messages produced.  Without this option,
 .Nm

[Bug cobol/119776] COBOL '-fmax-errors', 'Separate'

2025-04-14 Thread jakub at gcc dot gnu.org via Gcc-bugs 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119776

--- Comment #2 from Jakub Jelinek  ---
Perhaps even better with
--- gcc/cobol/cobol1.cc.jj  2025-04-14 11:09:22.619126924 +0200
+++ gcc/cobol/cobol1.cc 2025-04-14 11:32:51.177896287 +0200
@@ -385,10 +385,6 @@ cobol_langhook_handle_option (size_t sco
 return true;
 }

-case OPT_fmax_errors:
-flag_max_errors = atoi(arg);
-return true;
-
 case OPT_ffixed_form:
 cobol_set_indicator_column(-7);
 return true;