https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120771
--- Comment #2 from Simon Sobisch <simonsobisch at gnu dot org> --- (In reply to James K. Lowden from comment #1) > For the following input > > $IF C-OBS-ARCH = "x86" > $if nested-missing = 7 > 77 something value "never". > $else > 77 something value "hi". > $end > $ELSE > 77 something value "bye". > $END > > I see, with correct line numbers: > > In file included from tbug.cbl:2: > blargh4.cpy:12:11: error: CDF error: no such variable 'C-OBS-ARCH' > 12 | $IF C-OBS-ARCH = "x86" > | ^ > blargh4.cpy:12:11: error: incommensurate comparison is FALSE: %ld = '%s' > blargh4.cpy:13:13: warning: CDF skipping: no such variable 'nested-missing' > (ignored) > 13 | $if nested-missing = 7 > | ^ > blargh4.cpy:19:13: error: syntax error, unexpected NAME, expecting '.' > 19 | 77 something value "bye". > | ^ > cobol1: error: failed compiling tbug.cbl if that word is not part of gcc diagnostics otherwise, I'd suggest to replace "incommensurate". I've used a lot of compilers and don't consider myself "bad" in English, but that's the first time I've read it. "inconsistent" seem to deliver the same message and is a word I'm reading from time to time. There is something "bad" though. While > blargh4.cpy:13:13: warning: CDF skipping: no such variable 'nested-missing' > (ignored) > 13 | $if nested-missing = 7 is very nice > blargh4.cpy:12:11: error: CDF error: no such variable 'C-OBS-ARCH' > 12 | $IF C-OBS-ARCH = "x86" > | ^ > blargh4.cpy:12:11: error: incommensurate comparison is FALSE: %ld = '%s' isn't - I'd like to see the same warning as above instead of two errors. > Perhaps these messages now have the correct line numbers due to other > pending fixes for copybook line numbers. That would be nice. > > the same conditional is raising the same warning > > The user's control is -fmax-error Sure, but just output the same issue once like GCC does in C would be nicer. -fmax-error luckily does not apply to warnings when not using -Wfatal. > > after gcobol reported it as a warning, it raises an error > > Unable to reproduce, so far. OK, maybe I was tricked by the line numbers that should not have been identical. Will test possibly tomorrow by downstream parser branch.
