https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70006
--- Comment #6 from kargl at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #5) > > OK, How about WONTFIX? If the programmer fixes the > > issue reported in the "duplicate" error message, then > > the problem goes away. > > Well, this is quite general: if your code does not generate any error you'll > never the the shortcomings of the error handling! Nevertheless the laters > have to be fixed from a QOI point of view. It's not general at all. If the programmer fixes the error reported in the first message, then the second error message will not occur. Fairly simple concept. (It's clear that when I added -fmax-errors to gfortran, I should have made the default 1 instead of 25.) > > Amazing what an error message can convey! > > > > PS: The first duplicate error can be fixed by a > > trivial 3 character patch. The second duplicate > > error will probably take a significant rewrite of > > how labels are handle. Good luck. > > AFAIU the gfortran error handling, "duplicate" here does not mean that the > errors are repeated more than once as in pr44978, but rather that the first > errors are "shadowed" by the last ones. Compiling the following modified test gfortran is reporting the correct number of error messages as there are four errors in the original code. I've actually read the code (and fixed the first issue in my local code repository). The first set of duplicate error messages can be fixed with these three characters: loc. The second set of duplicated error messages requires someone to rewrite how labels are handled. Given that a sensible error message is emitted, it's not worth the effort.
