https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124017
--- Comment #2 from Yuxiao Peng <220246428 at seu dot edu.cn> --- (In reply to Andrew Pinski from comment #1) > So we only error out on the last goto where the undefined label is used. > > If we change the testcase to use different labels then GCC errors out on > each line where the different label is used. > > I think this is actually decent because we don't know if you miss-spelled > the label or just forgot to define it. Once you define the label, all of the > goto will just work. > > > This is the opposite of undeclared indentifiers where only the first rather > than the last one is errored out on. THis is also opposite than what clang > does here where the first rather than last one is errored out on. > > >In large, machine-generated, or complex files (like the attached case), this > >behavior forces a "trial-and-error" debugging process where the developer > >fixes one line only to have the compiler "discover" the previous one in a > >subsequent pass. > > Even erroring out on all of them is not good either because it could just be > not having the lable defined yet. and that is an diagnostic issue too. > > I am not sure which of the 3 ways is better here: first, last or all usage. > All have their benifits and have pitfalls. > > Now the location for the error message should be fixed/improved no matter > what. > So confirmed on that. Thank you for the quick feedback and for confirming the need to improve the location information. I would like to provide more context based on the 2000+ line machine-generated file （attachment） to explain why reporting the last occurrence is particularly problematic: 1. Inconsistency with Identifier Diagnostics As you mentioned, for undeclared identifiers, GCC reports the first occurrence. From a developer's perspective, labels are also identifiers within the function scope. Having different reporting directions (First for variables, Last for labels) creates an unnecessary cognitive load and inconsistency in the diagnostic engine. 2. Misleading "Root Cause" Analysis In the attached seed_0016.chain.c, the goto statements are spread across lines 772, 808, and 923. If a developer accidentally introduces an erroneous goto at line 772, but the compiler points to line 923, the developer will spend time investigating the logic at the end of the function, which might be completely unrelated to the actual mistake made at the beginning. In complex control-flow graphs, the "last" occurrence in source code isn't necessarily the "last" in execution or logical priority. I believe it's appropriate for errors to be reported every single time the code is executed. This allows developers to pinpoint all issues at once and fix all errors in one go. By the way, errors can be reported the first time they occur, with subsequent instances flagged using notes.
