https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118853
Bug ID: 118853
Summary: -fmax-errors=N does not stop parsing after the Nth
error
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zack+srcbugz at owlfolio dot org
Target Milestone: ---
Created attachment 60479
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60479&action=edit
Shell script that demonstrates the problem
The documentation makes it sound like -fmax-errors=N will cause GCC to
exit immediately after printing the Nth error. This is not what happens;
GCC seems instead to continue processing until it reaches either the end
of the file or the N+1'th error, and *then* it exits. If there was an
N+1'th error, it is not printed. In contrast, -Wfatal-errors causes
GCC to exit immediately after printing the first error.
This is observable if you have a very long (perhaps machine-generated)
source file with an error near the beginning. The attached shell script
generates such a source file and times execution of your choice of compiler
with -fsyntax-only + (-Wfatal-errors, -fmax-errors=1, nothing). Observe that
the execution time for the latter two is much longer than the execution time
for -Wfatal-errors.
I can see how "-fmax-errors=2" could be understood to mean "halt processing
if _more than_ two errors are encountered", but that's not what the manual
says it does, and also in that case it should print the third error before
giving up, and also in that case -fmax-errors=0 should do what -Wfatal-errors
does. I think user expectations are more likely to be that -fmax-errors=N
stops processing immediately after printing the Nth error, as is currently
the case for -Wfatal-errors with one error.
