Bug 7652 - -Wswitch-break : Warn if a switch case falls through
Summary: -Wswitch-break : Warn if a switch case falls through
Status: ASSIGNED
Alias: None
Product: gcc
Classification: Unclassified
Component: c (show other bugs)
Version: unknown
: P3 enhancement
Target Milestone: 7.0
Assignee: Marek Polacek
URL:
Keywords: diagnostic
: 43250 53960 (view as bug list)
Depends on:
Blocks:
 
Reported: 2002-08-20 07:36 UTC by ac131313
Modified: 2016-07-19 07:56 UTC (History)
28 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail: 2.97, 3.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.1, 3.1.1, 3.1.2, 3.2, 3.2.1, 3.2.2, 3.2.3, 3.3, 3.3.1, 3.3.2, 3.3.3, 3.4.0, 4.0.0
Last reconfirmed: 2012-07-14 00:00:00


Attachments
Proposed patch (1.14 KB, patch)
2014-04-30 15:44 UTC, Michael Chapman
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description ac131313 2002-08-20 07:36:02 UTC
Suggest a new -Wswitch variant, -Wswitch-break that warns
when one switch statement falls through to the next one vis:

case (foo)
  {
  case 1: case 2:
    printf ("case 1 and 2\n");
    break;
  case 3: case 4:
    printf ("case 3 and case 4\n");
  case 5:
    printf ("case 5 (and fallthrough for cases 3 and 4\n");
}

Release:
unknown
Comment 1 Wolfgang Bangerth 2002-11-27 07:21:03 UTC
State-Changed-From-To: open->analyzed
State-Changed-Why: I doubt warning if a switch case falls through is a useful
    feature since it is so commonly used in a reasonable way.
    Note that if you write 
      case 1: case 2:
    you are actually using this, since the "case 1" simply falls
    through to the "case 2"...
    
    But I leave it to others to judge whether this would be
    useful.
    W.
Comment 2 ac131313 2002-11-27 10:46:08 UTC
From: Andrew Cagney <ac131313@redhat.com>
To: bangerth@dealii.org, ac131313@redhat.com, gcc-bugs@gcc.gnu.org,
	gcc-prs@gcc.gnu.org, nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: c/7652: -Wswitch-break : Warn if a switch case falls through
Date: Wed, 27 Nov 2002 10:46:08 -0500

 > Synopsis: -Wswitch-break : Warn if a switch case falls through
 > 
 > State-Changed-From-To: open->analyzed
 > State-Changed-By: bangerth
 > State-Changed-When: Wed Nov 27 07:21:03 2002
 > State-Changed-Why:
 >     I doubt warning if a switch case falls through is a useful
 >     feature since it is so commonly used in a reasonable way.
 >     Note that if you write 
 >       case 1: case 2:
 >     you are actually using this, since the "case 1" simply falls
 >     through to the "case 2"...
 >     
 >     But I leave it to others to judge whether this would be
 >     useful.
 >     W.
 
 I've been informed that GCC can differentiate between `case 1: case 2:' 
 and a fall through (something about just needing to check for a branch 
 at the end of a switch case block).
 
 Please also remember that, just like all the other -W flags, this is a tool
 Like all tools, it can can be used in ways that either help or hinder 
 the user.  A skilled user (aka a toolsmith) is, however, capable of 
 determining if/when a tool is applicable.
 
 > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7652
Comment 3 brendan 2004-07-29 09:43:00 UTC
An alternative between "warn about all fall-throughs" and "never do it" would 
be quite useful.  If you have 
  case 0: 
  case 1: 
     foo(); 
  default: 
     bar(); 
gcc could warn only on the 'case 1' line, since it will see that there are 
statements between it and the default beneath it without a 'break' intervening.  
The fact that 'case 0' falls into 'case 1' won't be warned, since there are no 
actions between them. 
 
Most of the time, users will have a good reason to do multiple cases, but less 
often will someone want  
	case 0: 
	   bar(i); 
	case 1: 
	   foo(i); 
	   break; 
For those instances, they'll probably not be using -Wswitch-break (defaulting 
to off) anyway.  At any rate, it'll much more common to make the mistake of 
omitting the break, compared to coding it to have statements between cases 
without 'break'.  My opinion, anyway. 
 
B 
 
Comment 4 Andrew Pinski 2010-03-04 20:48:19 UTC
*** Bug 43250 has been marked as a duplicate of this bug. ***
Comment 5 David Laban 2011-02-02 01:04:33 UTC
Just adding myself to the cc list, having spent over 2 hours debugging a gobject get property related segfault caused by a missing break.
Comment 6 Leo Barnes 2011-05-09 14:41:58 UTC
I also just spent quite some time solving a bug that was caused by switch-case falling through and was thinking of writing some kind of parser to check for this. If gcc could check for it instead, that would be great.

Suggestion:
If possible, also add some kind of tag that can be used in code where you actually want a fall-through to happen.
Comment 7 Daniel Marjamäki 2011-07-29 13:28:41 UTC
In my experience this type of check is really noisy if there is a warning for every fall through.

I recommend that the warning is written only if the fall through cause redundant or bad behaviour. such as:

    switch (foo) {
    case 1: x = y;   // <- redundant assignment
    case 2: x = z;
    };

Or:

    switch (foo) {
    case 1: p = NULL;
    case 2: *p = 2;    // fall through => NULL pointer dereference
    };
Comment 8 Eric Smith 2012-02-21 01:01:19 UTC
Actually, I would want this warning to occur for all non-empty cases that don't end in a break or return.  However, I'd also want some means (perhaps a pragma) to put in the code to suppress the warning for any specific cases that I actually intend to fall through to the next case.
Comment 9 Eric Smith 2012-02-21 01:04:18 UTC
Or, instead of a pragma as I proposed in me previous comment, the warning would be avoided by using a goto to the next case label.  Updated version of the example from the first comment, which would not trip the warning:

case (foo)
  {
  case 1: case 2:
    printf ("case 1 and 2\n");
    break;
  case 3: case 4:
    printf ("case 3 and case 4\n");
    goto 5;
  case 5:
    printf ("case 5 (and fallthrough for cases 3 and 4\n");
}
Comment 10 Andrew Pinski 2012-07-14 04:54:03 UTC
*** Bug 53960 has been marked as a duplicate of this bug. ***
Comment 11 Jonathan Wakely 2012-07-14 11:52:52 UTC
As noted in Bug 53960 Clang now implements this warning.
Comment 12 David Stone 2012-07-14 15:14:13 UTC
However, I think it's important to note that they implement the very noisy behavior of warning for all implicit fall-through. We could make our warning much more useful by being silent for empty case statements, and in light of other warnings starting with -Wswitch, I would recommend we name the warning -Wswitch-fall-through or something similar. If we want to have an additional warning that warns for all fall-through, as clang does, we could also add -Wswitch-empty-fall-through.
Comment 13 Alexander Kornienko 2012-09-17 22:00:49 UTC
(In reply to comment #12)
> However, I think it's important to note that they implement the very noisy
> behavior of warning for all implicit fall-through. We could make our warning
> much more useful by being silent for empty case statements,
FYI, clang's warning does exactly this, i.e. it doesn't (and never did) warn on empty case labels. There's also a way to silence this warning in cases where fallthrough is intended: [[clang::fallthrough]]; construct, which uses custom C++11 statement attribute clang::fallthrough. There's a doc here: http://clang.llvm.org/docs/LanguageExtensions.html#clang__fallthrough

In an ideal world, it would be great if GCC had a compatible implementation using C++11 attributes (except for a namespace of the attribute), or for example, using a built-in function. So that it was possible to have the same syntax in source code, at least using a macro. Command-line flags compatibility would also be nice.

Or if you have any reasonable suggestions on how this diagnostic can be made better, I'll be glad to discuss this.

> and in light of
> other warnings starting with -Wswitch, I would recommend we name the warning
> -Wswitch-fall-through or something similar. If we want to have an additional
> warning that warns for all fall-through, as clang does, we could also add
> -Wswitch-empty-fall-through.
Comment 14 Manuel López-Ibáñez 2012-09-18 11:10:39 UTC
> In an ideal world, it would be great if GCC had a compatible implementation
> using C++11 attributes (except for a namespace of the attribute), or for
> example, using a built-in function. So that it was possible to have the same
> syntax in source code, at least using a macro. Command-line flags compatibility
> would also be nice.

I am pretty sure that if a proper patch is submitted to GCC, it will get approved, even without the special attribute (that could be a follow-up patch). The reason this has not been implemented is simply that no one has stepped forward to do the work.
Comment 15 Arthur O'Dwyer 2012-11-26 22:49:02 UTC
TL;DR — I would like to see GCC and Clang both implement __builtin_fallthrough().

I believe Lint recognizes the "magic comment" /*FALLTHROUGH*/

    case 1:
        foo();
        /*FALLTHROUGH*/
    case 2:

as a hint to suppress the warning. I think EDG's front-end has similar logic; certainly Green Hills' compiler recognizes /*FALLTHROUGH*/. (My memory is fuzzy because I no longer work there, but I know that Green Hills recognized a couple kinds of magic comment before I got there, which would have been six years ago.)  I admit that the "magic comment" approach has problems: for example, you can't #define a macro to expand to a comment. Also it complicates the parser.

Clang currently suppresses the warning only if the C++11 attribute [[clang::fallthrough]] is applied to a null statement immediately preceding "case 2:", but this doesn't work outside of C++11 mode, and it's ridiculously inappropriate as an industrywide solution (as it contains the word "clang" in the name of the attribute).

    case 1:
        foo();
        [[clang::fallthrough]];
    case 2:

Alternatively, someone in this clang-dev thread has proposed adding a __builtin_fallthrough() intrinsic that would suppress the warning, which is not a bad idea at all.
http://clang-developers.42468.n3.nabble.com/should-Wimplicit-fallthrough-require-C-11-td4028144.html
Notice that __builtin_fallthrough() could be #defined away on compilers that don't support it, and unlike a "magic comment", you can #define something to expand *to* it as well.

    case 1:
        foo();
        __builtin_fallthrough();
    case 2:

I'd like to see __builtin_fallthrough() added to all major compilers. :)
Comment 16 Arthur O'Dwyer 2012-11-26 23:02:52 UTC
(Sorry for the spam.)
The corresponding Clang enhancement is http://llvm.org/bugs/show_bug.cgi?id=14440
Comment 17 David Binderman 2013-06-23 06:43:52 UTC
(In reply to Daniel Marjamäki from comment #7)
> In my experience this type of check is really noisy if there is a warning
> for every fall through.
> 
> I recommend that the warning is written only if the fall through cause
> redundant or bad behaviour. such as:
> 
>     switch (foo) {
>     case 1: x = y;   // <- redundant assignment
>     case 2: x = z;
>     };

I'd be happy with gcc warning for this kind of problem.

This specific case should be easier to catch than the 
general case.
Comment 18 Manuel López-Ibáñez 2013-06-23 10:38:34 UTC
(In reply to David Binderman from comment #17)
> (In reply to Daniel Marjamäki from comment #7)
> > In my experience this type of check is really noisy if there is a warning
> > for every fall through.
> > 
> > I recommend that the warning is written only if the fall through cause
> > redundant or bad behaviour. such as:
> > 
> >     switch (foo) {
> >     case 1: x = y;   // <- redundant assignment
> >     case 2: x = z;
> >     };
> 
> I'd be happy with gcc warning for this kind of problem.
> 
> This specific case should be easier to catch than the 
> general case.

In fact, this case is the same outside a switch:

x = y;
x = z;

I think this could be useful, but it will depend a lot on the implementation. So we need someone to implement it ;-)
Comment 19 Chung-Ju Wu 2013-06-23 12:21:39 UTC
(In reply to David Binderman from comment #17)
> (In reply to Daniel Marjamäki from comment #7)
> > In my experience this type of check is really noisy if there is a warning
> > for every fall through.
> > 
> > I recommend that the warning is written only if the fall through cause
> > redundant or bad behaviour. such as:
> > 
> >     switch (foo) {
> >     case 1: x = y;   // <- redundant assignment
> >     case 2: x = z;
> >     };
> 
> I'd be happy with gcc warning for this kind of problem.
> 
> This specific case should be easier to catch than the 
> general case.


I believe such redundant assignment will be optimized out.


$ gcc --version
gcc (20130621) 4.9.0 20130621 (experimental)
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ gcc -O2 -S pr7652.c


[pr7652.c]
  1
  2 extern int a;
  3 extern int b;
  4 extern int c;
  5
  6 int
  7 main(int argc, char **argv)
  8 {
  9   int x;
 10
 11   switch (argc)
 12     {
 13     case 1:
 14       x = a;
 15     case 7:
 16       x = b;
 17       break;
 18     default:
 19       x = c;
 20       break;
 21     }
 22
 23   return x;
 24 }


[pr7652.s]
  1         .file   "pr7652.c"
  2         .section        .text.startup,"ax",@progbits
  3         .p2align 4,,15
  4         .globl  main
  5         .type   main, @function
  6 main:
  7 .LFB0:
  8         .cfi_startproc
  9         movl    4(%esp), %eax
 10         cmpl    $1, %eax
 11         je      .L3
 12         cmpl    $7, %eax
 13         je      .L3
 14         movl    c, %eax
 15         ret
 16 .L3:
 17         movl    b, %eax
 18         ret
 19         .cfi_endproc
 20 .LFE0:
 21         .size   main, .-main
 22         .ident  "GCC: (20130621) 4.9.0 20130621 (experimental)"
 23         .section        .note.GNU-stack,"",@progbits


Apparently it is dead code.  IMHO, it may not be a good idea to
have compiler issue a warning everytime when compiler identifies
dead code statements.
Comment 20 Jackie Rosen 2014-02-16 13:17:37 UTC Comment hidden (spam)
Comment 21 Michael Chapman 2014-04-30 15:44:51 UTC
Created attachment 32716 [details]
Proposed patch

Patch to enable warnings (-Wswitch-fallthrough) when a switch case falls through. Enabled by -Wall.
Comment 22 Matthew Woehlke 2014-04-30 16:09:12 UTC
Thanks for the patch. However, one thing I am not seeing is an easy way to suppress the warning for a specific occurrence (a la [[clang:fallthrough]]). Can that be added also? (Or is it there and I miss something?)

Ideally this would work like:

switch (expr)
{
  case A:
    // empty body, no warning
  case B:
    ...
    [[gcc:fallthrough]] // suppress warning for fall-through to 'case C'
  case C:
    ...
    break;
  case D:
    ...
    // will warn here
  default:
    ...
    break;
}
Comment 23 Manuel López-Ibáñez 2014-04-30 16:10:27 UTC
(In reply to Michael Chapman from comment #21)
> Created attachment 32716 [details]
> Proposed patch
> 
> Patch to enable warnings (-Wswitch-fallthrough) when a switch case falls
> through. Enabled by -Wall.

Thanks! Patches need to be submitted to gcc-patches@gcc.gnu.org with a Changelog after bootstrapping and regression testing. The patch is missing a testcase for the regression testsuite showing in which cases it should warn and in which cases it should not. First of all, you need to have a copyright assignment in place with the FSF. This is slightly annoying to do the first time, but you only have to do it once for all GNU projects. See: http://gcc.gnu.org/contribute.html

About the patch:

+int
+c_stmt_ends_with_goto (tree t)

This should return 'bool'

+{
+  if (TREE_CODE (t) == GOTO_EXPR)
+    return TRUE;
+  if (TREE_CODE (t) == BIND_EXPR)
+    return c_stmt_ends_with_goto (tsi_stmt (tsi_last (BIND_EXPR_BODY (t))));
+  return FALSE;
+}

You can use 'true' and 'false'

+
+/* Handle -Wswitch-fallthrough */
+void 
+c_do_switch_fallthru_warnings (tree body)
+{
+  tree_stmt_iterator i;
+  tree previous_stmt = NULL;
+  tree previous_label = NULL;
+  tree stmts = BIND_EXPR_BODY (body);

I think it would be worthwhile to add:

if (!warn_switch_fallthrough)
   return;

to avoid going through the loop if we are not going to warn anyway.


+Wswitch-fallthrough
+C ObjC C++ ObjC++ Var(warn_switch_fallthrough) Warning LangEnabledBy(C ObjC C++ ObjC++,Wall)
+Warn about switch cases which fall through to the next case
+

This says that the warning is available in C++, but I don't see any code in your patch that calls the new function from the C++ FE.

It would be nice to have the same warning in C++. This will allow testing how noisy it is in GCC itself, for instance. But you (or someone else) could do that as a follow-up.
Comment 24 Jonathan Wakely 2014-04-30 16:11:43 UTC
(In reply to Matthew Woehlke from comment #22)
>     [[gcc:fallthrough]] // suppress warning for fall-through to 'case C'

N.B. the attribute-namespace for GNU extensions is "gnu"

I agree that the attribute is essential before such warning could be enabled by -Wall
Comment 25 Florian Weimer 2014-04-30 16:18:03 UTC
(In reply to Matthew Woehlke from comment #22)

>   case B:
>     ...
>     [[gcc:fallthrough]] // suppress warning for fall-through to 'case C'

Do we have such attributes in the C compiler?

I contemplated using any comment whatsoever as an indicator that fall-through is expected.

In the end, need general (syntax-based) unreachable-code detection, so that return statements and no-return functions suppress the warning as well, and so on.  At least if this will be part of -Wall.
Comment 26 Marek Polacek 2014-04-30 16:23:42 UTC
(In reply to Florian Weimer from comment #25)
> Do we have such attributes in the C compiler?

No, AFAICS.  Perhaps we could invent __builtin_fallthrough or some such.
Comment 27 Matthew Woehlke 2014-04-30 16:34:14 UTC
(In reply to Marek Polacek from comment #26)
> Perhaps we could invent __builtin_fallthrough or some such.

Yes, I was expecting there would be some alternate spelling for cases where C++11 attributes are not available, e.g. using __attribute__ or __builtin_fallthrough or some such. Please support [[gnu:fallthrough]] also, though, for consistency with clang (and it gives more weight to eventually making [[fallthrough]] standardized).
Comment 28 Alexander Kornienko 2014-04-30 16:34:57 UTC
(In reply to Jonathan Wakely from comment #24)
> (In reply to Matthew Woehlke from comment #22)
> >     [[gcc:fallthrough]] // suppress warning for fall-through to 'case C'
> 
> N.B. the attribute-namespace for GNU extensions is "gnu"

And also the attribute must be attached to a declaration or a statement. In Clang, the [[clang::fallthrough]] attribute is attached to an empty statement ';', so the syntax actually is:

switch (x) {
  case 1:
    ...
    [[clang::fallthrough]];  // <- note the semicolon

  case 2:
    ...
Comment 29 Manuel López-Ibáñez 2014-04-30 16:40:42 UTC
(In reply to Marek Polacek from comment #26)
> (In reply to Florian Weimer from comment #25)
> > Do we have such attributes in the C compiler?
> 
> No, AFAICS.  Perhaps we could invent __builtin_fallthrough or some such.

I like the previous suggestion of using "goto LABEL;". In fact, the warning message could explicitly say "use %<goto %D;%> to silence this warning".

(In reply to Florian Weimer from comment #25)
> 
> In the end, need general (syntax-based) unreachable-code detection, so that
> return statements and no-return functions suppress the warning as well, and
> so on.  At least if this will be part of -Wall.

For trivial cases, it should be just a matter of checking the type of the previous statement in c_stmt_ends_with_goto.
Comment 30 Florian Weimer 2014-04-30 16:47:31 UTC
(In reply to Manuel López-Ibáñez from comment #29)

> I like the previous suggestion of using "goto LABEL;". In fact, the warning
> message could explicitly say "use %<goto %D;%> to silence this warning".

Does this mean that you propose a GCC extension which allows to write this?

     goto 5;
   case 5:

I'm not sure if the extension is worth it, and it creates another source of errors/unclarities if another switch branch is inserted before "case 5:".  It looks like fall-through, but it isn't one because the case labels aren't aligned.
Comment 31 Manuel López-Ibáñez 2014-04-30 16:54:51 UTC
(In reply to Florian Weimer from comment #30)
> (In reply to Manuel López-Ibáñez from comment #29)
> 
> > I like the previous suggestion of using "goto LABEL;". In fact, the warning
> > message could explicitly say "use %<goto %D;%> to silence this warning".
> 
> Does this mean that you propose a GCC extension which allows to write this?
> 
>      goto 5;
>    case 5:

Sorry, ignore my comment. I am not sure what I was thinking....

__builtin_fallthrough() seems fine enough. It could be mentioned by the warning message. But as you said, it would be better to detect as many false positives as possible to avoid forcing people to use the __builtin work-around.
Comment 32 Matthew Woehlke 2014-04-30 17:04:24 UTC
(In reply to Florian Weimer from comment #30)
> Does this mean that you propose a GCC extension which allows to write this?
> 
>      goto 5;
>    case 5:

While I personally detest this syntax :-), I feel that I should note that there is a proposal to add e.g. 'goto case 5' to C++17. (Note that I'm not sure if it's even an official proposal yet, though, just that it's been brought up on std-proposals.)

(*I* much prefer __builting_fallthrough() or some such...)
Comment 33 Michael Chapman 2014-04-30 17:20:10 UTC
(In reply to Florian Weimer from comment #30)
> (In reply to Manuel López-Ibáñez from comment #29)
> 
> > I like the previous suggestion of using "goto LABEL;". In fact, the warning
> > message could explicitly say "use %<goto %D;%> to silence this warning".
> 
> Does this mean that you propose a GCC extension which allows to write this?
> 
>      goto 5;
>    case 5:
> 
> I'm not sure if the extension is worth it, and it creates another source of
> errors/unclarities if another switch branch is inserted before "case 5:". 
> It looks like fall-through, but it isn't one because the case labels aren't
> aligned.

Why an extension? What is wrong with:-

        goto case_5;
      case 5: case_5:
         ....
Comment 34 Manuel López-Ibáñez 2014-08-21 01:23:45 UTC
In any case, the current patch needs more work. In case you want to see this in GCC 5.0, you need to hurry up! :)
Comment 35 Michael Thayer 2014-09-23 07:25:21 UTC
(In reply to Florian Weimer from comment #25)
> I contemplated using any comment whatsoever as an indicator that
> fall-through is expected.

Coverity do that:

http://security.coverity.com/blog/2013/Sep/gimme-a-break.html
Comment 36 Tom Tromey 2016-03-07 15:18:14 UTC
This came up for Mozilla today:

https://groups.google.com/forum/#!topic/mozilla.dev.platform/YT7SXFhyr_I

Essentially, this warning and the "intentional fallthrough" attribute
exist for both clang and MSVC and will be enabled there; but GCC
still doesn't have this feature.
Comment 37 Matthew Woehlke 2016-03-07 15:43:00 UTC
> Essentially, this warning and the "intentional fallthrough" attribute
exist for both clang and MSVC and will be enabled there; but GCC
still doesn't have this feature.

[[fallthrough]] was approved for C++17. While the standard does not normatively *require* a diagnostic, it's certainly expected that one be issued. It's a shame that gcc is behind the curve here.
Comment 38 Jonathan Wakely 2016-03-08 05:09:09 UTC
(In reply to Matthew Woehlke from comment #37)
> [[fallthrough]] was approved for C++17. While the standard does not
> normatively *require* a diagnostic, it's certainly expected that one be
> issued. It's a shame that gcc is behind the curve here.

It was approved less than a week ago. It's not 2017 yet. It will get implemented.
Comment 39 Matthew Woehlke 2016-03-08 15:08:22 UTC
(In reply to Jonathan Wakely from comment #38)
> (In reply to Matthew Woehlke from comment #37)
> > [[fallthrough]] was approved for C++17 [...] It's a shame that gcc is behind
> > the curve here.
> 
> It was approved less than a week ago.

So? People have been asking for it for at least *13+ years* (this report was opened in August 2002). Compared to clang which has had this feature for some years already, gcc is lagging.

I'm also not sure how to react to "less than a week ago". The *wording* was approved last week. The *feature* was approved (by EWG¹, which is the approval that matters most for something like this) at Kona, a few months back. If you're claiming you can't implement without wording, that's one thing. If you didn't see it coming, then you didn't do your homework.

(¹ ...about as strongly as you ever see out of EWG, at that:
SF=15, F=5, N=0, A=0, SA=0)

> It will get implemented.

I do hope so, but given that a) it hasn't been implemented in over a decade of people asking for it, and b) isn't actually required for conformance, I'm not holding my breath.
Comment 40 Manuel López-Ibáñez 2016-03-08 16:21:43 UTC
(In reply to Matthew Woehlke from comment #39)
> So? People have been asking for it for at least *13+ years* (this report was
> opened in August 2002). Compared to clang which has had this feature for
> some years already, gcc is lagging.

Unfortunately, Clang has more developers working on just its C-family FE than GCC has developers working on all C-family, Ada, Fortran FEs plus middle-end (optimizations, LTO) and all its back-ends combined. Thus, lagging behind Clang w.r.t. C++ features is normal. What is your solution?

(In fact, it is only a testament to how hard GCC C++ developers work that the gap is not much wider.)

> I do hope so, but given that a) it hasn't been implemented in over a decade
> of people asking for it, and b) isn't actually required for conformance, I'm
> not holding my breath.

Features get implemented when someone implements them. People implement features because a) they get paid for it (are you paying someone who is not delivering?) or b) they have the time and motivation to do it (do you think this is important enough to dedicate your time to implement this?). If the answer to those questions is no, then this cannot be such a critical feature, since nobody has bothered to get it implemented (or paid to do so) in the last decade.
Comment 41 Jonathan Wakely 2016-03-11 16:08:01 UTC
(In reply to Matthew Woehlke from comment #39)
> So? People have been asking for it for at least *13+ years* (this report was
> opened in August 2002). Compared to clang which has had this feature for
> some years already, gcc is lagging.

Until now it was a non-standard extension that GCC didn't support. That's a completely different situation.

> I'm also not sure how to react to "less than a week ago". The *wording* was
> approved last week. The *feature* was approved (by EWG¹, which is the
> approval that matters most for something like this) at Kona, a few months
> back. If you're claiming you can't implement without wording, that's one
> thing. If you didn't see it coming, then you didn't do your homework.

But it wasn't part of the working draft until now. Not everything that gets approved by an EWG poll makes it into a standard.

But I'm sure you know all this and are just whining for the sake of it. If you want the feature desperately and can't wait for it to be implemented then you could provide a patch. Without that your comments are not constructive.
Comment 42 Jonathan Wakely 2016-03-11 16:14:20 UTC
(In reply to Jonathan Wakely from comment #41)
> But it wasn't part of the working draft until now. Not everything that gets
> approved by an EWG poll makes it into a standard.

In case you really don't know: an EWG poll does not mean something is approved, that happens when the full committee takes a poll and agrees to update the working draft. Not everything that EWG approves gets approved by the full committee. Which is why my "less than a week ago comment" was relevant. If you don't know how to react to it politely or calmly, maybe don't bother sharing your reaction here.
Comment 43 Marek Polacek 2016-05-12 11:03:32 UTC
I'll be experimenting with this.
Comment 44 Marek Polacek 2016-06-16 11:28:24 UTC
FYI, I have got a candidate patch, but the trouble comes with code such as

  case 1:
    if (x) 
      bar (); // warn here
    else
      {   
        bar (); 
        return;
      }   
  case 0:

so this is going to require more thinking & tinkering.  :/
Comment 45 Marek Polacek 2016-07-12 07:39:07 UTC
Patches posted <https://gcc.gnu.org/ml/gcc-patches/2016-07/msg00532.html>.
Comment 46 Tim Haines 2016-07-19 00:30:43 UTC
(In reply to Marek Polacek from comment #45)
> Patches posted <https://gcc.gnu.org/ml/gcc-patches/2016-07/msg00532.html>.

Thank you for putting in the work to make this happen! Does the current patch allow calling a [[noreturn]] function without the need to follow it with a call to __builtin_fallthrough()? Something like

int i = ...;
switch (i) {
case 1:
    std::abort();
    // don't warn about fallthrough here
case 2:
    std::cout << "Hello world!\n";
    break;
}
Comment 47 Marek Polacek 2016-07-19 07:56:00 UTC
(In reply to Tim Haines from comment #46)
> (In reply to Marek Polacek from comment #45)
> > Patches posted <https://gcc.gnu.org/ml/gcc-patches/2016-07/msg00532.html>.
> 
> Thank you for putting in the work to make this happen! Does the current
> patch allow calling a [[noreturn]] function without the need to follow it
> with a call to __builtin_fallthrough()? Something like

Yes.  Note that I'm working on another version, so instead of __builtin_fallthrough() you'd use [[fallthrough]]; or __attribute__((fallthrough));.  Noreturn functions are of course still being taken into account.