[Bug c/91432] gcc -Wimplicit-fallthrough does not warn when fallthrough to break;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91432 --- Comment #8 from Jakub Jelinek --- Useful for what? What exactly is an advantage to require attribute at such a place? Nothing will warn if you put it there, but I don't see a rationale for requiring it.
[Bug c/91432] gcc -Wimplicit-fallthrough does not warn when fallthrough to break;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91432 --- Comment #7 from Joe Perches --- What could be useful is to add yet another --extra-strict-fallthrough warning flag that would make it possible for these cases to have a warning.
[Bug c/91432] gcc -Wimplicit-fallthrough does not warn when fallthrough to break;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91432 --- Comment #6 from Jakub Jelinek --- (In reply to Nick Desaulniers from comment #5) > > Not warning in this case is a very intentional part of those design > > decisions. > > Can you provide a link to the discussion about this specific case? The discussions are on gcc-patches mailing list, look into archives from July 2016 to August or September, initially with -Wswitch-fallthrough in the subject, later -Wimplicit-fallthrough. > Is re-evaluating the decision out of the question? Yes. It is pointless to start warning about code that obviously can't do any harm, it will only alienate users that will need to mark up more code. The work Marek has done on this warning started with getting through warnings on gcc itself and on other projects and has been fine tuned on where it is essential not to warn and where false positives can be acceptable.
[Bug c/91432] gcc -Wimplicit-fallthrough does not warn when fallthrough to break;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91432 --- Comment #5 from Nick Desaulniers --- > Not warning in this case is a very intentional part of those design decisions. Can you provide a link to the discussion about this specific case? Is re-evaluating the decision out of the question?
[Bug c/91432] gcc -Wimplicit-fallthrough does not warn when fallthrough to break;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91432 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- The warning has been carefully designed not to warn in common cases which pose no problems, see e.g. https://developers.redhat.com/blog/2017/03/10/wimplicit-fallthrough-in-gcc-7 or the lengthy discussions held around the submission of the feature. Not warning in this case is a very intentional part of those design decisions.
[Bug c/91432] gcc -Wimplicit-fallthrough does not warn when fallthrough to break;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91432 Nick Desaulniers changed: What|Removed |Added CC||ndesaulniers at google dot com --- Comment #3 from Nick Desaulniers --- Isn't this still an implicit fallthrough, though? It may not "be a bug," but that's why warnings are not errors; they may not result in "bugs." The issue is that Clang will warn in this case, so developers get confused about writing compiler-portable code with intentional fallthrough vs being warned about unintentional fallthrough. Why shouldn't developers annotate that the implicit fallthrough from `case 1` to `default` was intentional, making it explicit?
[Bug c/91432] gcc -Wimplicit-fallthrough does not warn when fallthrough to break;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91432 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||marxin at gcc dot gnu.org Resolution|--- |INVALID --- Comment #2 from Martin Liška --- I would close this as invalid.
[Bug c/91432] gcc -Wimplicit-fallthrough does not warn when fallthrough to break;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91432 --- Comment #1 from Marc Glisse --- The warning basically says "you may have forgotten 'break;'". If it falls through to break anyway, what difference does it make if I add a redundant break?
