[Bug cobol/119777] [15 Regression] COBOL '-fsyntax-only', 'RejectNegative'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119777 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #10 from Jakub Jelinek --- Fixed.
[Bug cobol/119777] [15 Regression] COBOL '-fsyntax-only', 'RejectNegative'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119777 --- Comment #9 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:d0b41f3d6d0ace2b0ca57d105cd7fd8361d0b2a8 commit r15-9456-gd0b41f3d6d0ace2b0ca57d105cd7fd8361d0b2a8 Author: Jakub Jelinek Date: Mon Apr 14 19:32:43 2025 +0200 cobol: Fix up COBOL -include [PR119777] I was looking through options.cc diff between GCC 14 and 15, looking for entries with added CL_Cobol where at least one other language is present and was present before too. Besides the -fsyntax-only changes this is the only other one I found, COBOL adds Var(cobol_include) to something which didn't have a Var at all before and IMHO it is actively harmful. Because one can specify multiple -include file1 -include file2 options, both in C/C++ etc. and in COBOL as well (as documented in the man page). A Var can track just one entry. cobol_langhook_handle_option should use arg instead. 2025-04-14 Jakub Jelinek PR cobol/119777 * lang.opt (include): Remove Var(cobol_include). * cobol1.cc (cobol_langhook_handle_option) : Use arg instead of cobol_include.
[Bug cobol/119777] [15 Regression] COBOL '-fsyntax-only', 'RejectNegative'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119777 --- Comment #8 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:e96cb35ceb08bb6d12670172115f27819c806e82 commit r15-9455-ge96cb35ceb08bb6d12670172115f27819c806e82 Author: Jakub Jelinek Date: Mon Apr 14 19:32:06 2025 +0200 cobol: Drop -fsyntax-only from COBOL lang.opt [PR119777] The comment is incorrect, fsyntax-only is not documented in c.opt, but in common.opt: fsyntax-only Common Var(flag_syntax_only) Check for syntax errors, then stop. and as such it applies to all languages, so adding CL_Cobol to the CL_COMMON is both unnecessary and because of RejectNegative which contradicts the generic option very harmful, because it makes -fno-syntax-only invalid for all languages. Fixed by just dropping it. 2025-04-14 Jakub Jelinek PR cobol/119777 * lang.opt (fsyntax-only): Remove. * lang.opt.urls: Regenerate.
[Bug cobol/119777] [15 Regression] COBOL '-fsyntax-only', 'RejectNegative'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119777 --- Comment #7 from Thomas Schwinge --- In case that was unclear: (In reply to Simon Sobisch from comment #1) > Do you say there should be a -fno-syntax-only?` I'm saying that there *used to be* a "Common" '-fno-syntax-only', which got invalidated by the COBOL front end commit. Of course, having test cases (COBOL as well as non-COBOL ones) for this wouldn't hurt.
[Bug cobol/119777] [15 Regression] COBOL '-fsyntax-only', 'RejectNegative'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119777 --- Comment #6 from Simon Sobisch --- Looks good to me (and yes, --include should be possible multiple times), but I haven't tested this or am a maintainer for gcobol... Seems -Wall and --verbose (or -v only?) are different beasts, then.
[Bug cobol/119777] [15 Regression] COBOL '-fsyntax-only', 'RejectNegative'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119777
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed||2025-04-14
--- Comment #5 from Jakub Jelinek ---
And for the -include issue I'd go with
2025-04-14 Jakub Jelinek
PR cobol/119777
* lang.opt (include): Remove Var(cobol_include).
* cobol1.cc (cobol_langhook_handle_option) : Use
arg instead of cobol_include.
--- gcc/cobol/lang.opt.jj 2025-04-14 10:56:28.739693026 +0200
+++ gcc/cobol/lang.opt 2025-04-14 11:08:31.808821317 +0200
@@ -114,7 +114,7 @@ Cobol Joined Separate
; Documented in C
include
-Cobol Joined Separate Var(cobol_include)
+Cobol Joined Separate
; Documented in C
isysroot
--- gcc/cobol/cobol1.cc.jj 2025-04-12 13:10:31.592523688 +0200
+++ gcc/cobol/cobol1.cc 2025-04-14 11:09:22.619126924 +0200
@@ -413,8 +413,8 @@ cobol_langhook_handle_option (size_t sco
}
return true;
case OPT_include:
- if( ! include_file_add(cobol_include) ) {
-cbl_errx( "could not include %s", cobol_include);
+ if( ! include_file_add(arg) ) {
+cbl_errx( "could not include %s", arg);
}
return true;
[Bug cobol/119777] [15 Regression] COBOL '-fsyntax-only', 'RejectNegative'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119777 --- Comment #4 from Jakub Jelinek --- For -fsyntax-only I'd go with 2025-04-14 Jakub Jelinek PR cobol/119777 * lang.opt (fsyntax-only): Remove. * lang.opt.urls: Regenerate. --- gcc/cobol/lang.opt.jj 2025-04-08 14:08:48.662317907 +0200 +++ gcc/cobol/lang.opt 2025-04-14 10:56:28.739693026 +0200 @@ -77,10 +77,6 @@ ffixed-form Cobol RejectNegative Assume that the source file is fixed form. -fsyntax-only -Cobol RejectNegative -; Documented in c.opt - ffree-form Cobol RejectNegative Assume that the source file is free form. --- gcc/cobol/lang.opt.urls.jj 2025-04-08 14:08:48.662317907 +0200 +++ gcc/cobol/lang.opt.urls 2025-04-14 10:57:06.579176798 +0200 @@ -13,9 +13,6 @@ UrlSuffix(gcc/Directory-Options.html#ind ffixed-form LangUrlSuffix_Fortran(gfortran/Fortran-Dialect-Options.html#index-ffixed-form) -fsyntax-only -UrlSuffix(gcc/Warning-Options.html#index-fsyntax-only) LangUrlSuffix_D(gdc/Warnings.html#index-fno-syntax-only) LangUrlSuffix_Fortran(gfortran/Error-and-Warning-Options.html#index-fsyntax-only) - ffree-form LangUrlSuffix_Fortran(gfortran/Fortran-Dialect-Options.html#index-ffree-form)
[Bug cobol/119777] [15 Regression] COBOL '-fsyntax-only', 'RejectNegative'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119777 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- So, I've diffed gcc 14 options.cc to gcc trunk options.cc and looked for differences in entries which have CL_Cobol + at least one other language (i.e. where COBOL version merges with the other language or common version). The only differences were "-fsyntax-only", "Check for syntax errors, then stop.", NULL, NULL, -NULL, NULL, N_OPTS, N_OPTS, 12, /* .neg_idx = */ 1760, -CL_COMMON, -0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, +NULL, NULL, N_OPTS, N_OPTS, 12, /* .neg_idx = */ -1, +CL_Cobol | CL_COMMON, +0, 0, 0, 0, 0, 0, 1 /* RejectNegative */, 0, 0, 0, 0, 0, offsetof (struct gcc_options, x_flag_syntax_only), 0, CLVC_INTEGER, 0, -1, -1 }, discussed here where obviously the COBOL entry should be just removed, CL_COMMON applies to all languages, and "-include", "-includeInclude the contents of before other files.", "missing filename after %qs", NULL, NULL, NULL, N_OPTS, N_OPTS, 7, /* .neg_idx = */ -1, -CL_C | CL_CXX | CL_ObjC | CL_ObjCXX | CL_JOINED | CL_SEPARATE, +CL_C | CL_CXX | CL_Cobol | CL_ObjC | CL_ObjCXX | CL_JOINED | CL_SEPARATE, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, -(unsigned short) -1, 0, CLVC_STRING, 0, -1, -1 }, +offsetof (struct gcc_options, x_cobol_include), 0, CLVC_STRING, 0, -1, -1 }, where probably the addition of Var(cobol_include) is not actively harmful to other FEs, but I don't really see how one variable can hold the -include argument. At least in C, it is quite normal to use -include a.h -include b.h -include c.h.
[Bug cobol/119777] [15 Regression] COBOL '-fsyntax-only', 'RejectNegative'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119777 Richard Biener changed: What|Removed |Added Target Milestone|--- |15.0 --- Comment #2 from Richard Biener --- I think the "duplicate" options should be identical, given we do not handle "duplicates" very well, at least if they differ in semantics.
[Bug cobol/119777] [15 Regression] COBOL '-fsyntax-only', 'RejectNegative'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119777 Simon Sobisch changed: What|Removed |Added CC||simonsobisch at gnu dot org --- Comment #1 from Simon Sobisch --- I don't understand completely what you mean apart from "should definitely be handled 'common'"... Do you say there should be a -fno-syntax-only?` ... makes me wonder what gcc -fsyntax-only -o some.out some.c other.c does (I _think_ that should at least be valid - if also "partially duplicate" when -E is added as well).
