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.

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

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 
 

*** Bug 43250 has been marked as a duplicate of this bug. ***

Just adding myself to the cc list, having spent over 2 hours debugging a gobject get property related segfault caused by a missing break.

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.

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
    };

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.

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");
}

*** Bug 53960 has been marked as a duplicate of this bug. ***

As noted in Bug 53960 Clang now implements this warning.

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.

(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.

> 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.

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. :)

(Sorry for the spam.)
The corresponding Clang enhancement is http://llvm.org/bugs/show_bug.cgi?id=14440

(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 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 ;-)

(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.

Created attachment 32716 [details]
Proposed patch

Patch to enable warnings (-Wswitch-fallthrough) when a switch case falls through. Enabled by -Wall.

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;
}

(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.

(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

(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.

(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.

(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).

(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:
    ...

(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.

(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.

(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.

(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...)

(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:
         ....

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! :)

(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

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.

> 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.

(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.

(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.

(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.

(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.

(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.

I'll be experimenting with this.

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.  :/

Patches posted <https://gcc.gnu.org/ml/gcc-patches/2016-07/msg00532.html>.

(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;
}

(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.

Author: mpolacek
Date: Thu Jul 28 15:46:07 2016
New Revision: 238824

URL: https://gcc.gnu.org/viewcvs?rev=238824&root=gcc&view=rev
Log:
	PR c/7652
	* jcf-dump.c (print_constant): Add break.

Modified:
    trunk/gcc/java/ChangeLog
    trunk/gcc/java/jcf-dump.c

Author: mpolacek
Date: Fri Jul 29 11:16:20 2016
New Revision: 238856

URL: https://gcc.gnu.org/viewcvs?rev=238856&root=gcc&view=rev
Log:
	PR c/7652
	* config/rs6000/rs6000.c (altivec_expand_ld_builtin): Likewise.
	(altivec_expand_st_builtin): Likewise.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/rs6000/rs6000.c

Author: mpolacek
Date: Fri Jul 29 11:22:42 2016
New Revision: 238857

URL: https://gcc.gnu.org/viewcvs?rev=238857&root=gcc&view=rev
Log:
	PR c/7652
	* config/rs6000/rs6000.c (altivec_expand_ld_builtin): Likewise.
	(altivec_expand_st_builtin): Likewise.

Modified:
    branches/gcc-6-branch/gcc/ChangeLog
    branches/gcc-6-branch/gcc/config/rs6000/rs6000.c

Author: mpolacek
Date: Fri Jul 29 11:26:46 2016
New Revision: 238858

URL: https://gcc.gnu.org/viewcvs?rev=238858&root=gcc&view=rev
Log:
	PR c/7652
	* config/rs6000/rs6000.c (altivec_expand_ld_builtin): Likewise.
	(altivec_expand_st_builtin): Likewise.

Modified:
    branches/gcc-5-branch/gcc/ChangeLog
    branches/gcc-5-branch/gcc/config/rs6000/rs6000.c

Author: mpolacek
Date: Fri Jul 29 12:39:25 2016
New Revision: 238864

URL: https://gcc.gnu.org/viewcvs?rev=238864&root=gcc&view=rev
Log:
	PR c/7652
	* config/i386/i386.c (ix86_expand_args_builtin): Add break.
	(ix86_expand_round_builtin): Likewise.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/i386/i386.c

(In reply to Marek Polacek from comment #52)
> Author: mpolacek
> Date: Fri Jul 29 12:39:25 2016
> New Revision: 238864
> 
> URL: https://gcc.gnu.org/viewcvs?rev=238864&root=gcc&view=rev
> Log:
> 	PR c/7652
> 	* config/i386/i386.c (ix86_expand_args_builtin): Add break.
> 	(ix86_expand_round_builtin): Likewise.
> 
> Modified:
>     trunk/gcc/ChangeLog
>     trunk/gcc/config/i386/i386.c

Will this be applied to 4.9 branch? The same issue is there too.

(In reply to Ozkan Sezer from comment #53)
> (In reply to Marek Polacek from comment #52)
> > Author: mpolacek
> > Date: Fri Jul 29 12:39:25 2016
> > New Revision: 238864
> > 
> > URL: https://gcc.gnu.org/viewcvs?rev=238864&root=gcc&view=rev
> > Log:
> > 	PR c/7652
> > 	* config/i386/i386.c (ix86_expand_args_builtin): Add break.
> > 	(ix86_expand_round_builtin): Likewise.
> > 
> > Modified:
> >     trunk/gcc/ChangeLog
> >     trunk/gcc/config/i386/i386.c
> 
> Will this be applied to 4.9 branch? The same issue is there too.

Yes, I'll backport the fix to 4.9, too.

Author: mpolacek
Date: Mon Aug  1 16:03:41 2016
New Revision: 238958

URL: https://gcc.gnu.org/viewcvs?rev=238958&root=gcc&view=rev
Log:
	PR c/7652
	* config/i386/i386.c (ix86_expand_args_builtin): Add break.
	(ix86_expand_round_builtin): Likewise.

Modified:
    branches/gcc-4_9-branch/gcc/ChangeLog
    branches/gcc-4_9-branch/gcc/config/i386/i386.c

Author: mpolacek
Date: Tue Aug  9 16:39:28 2016
New Revision: 239297

URL: https://gcc.gnu.org/viewcvs?rev=239297&root=gcc&view=rev
Log:
	PR c/7652
gcc/c-family/
	* c-ada-spec.c (dump_generic_ada_node): Add return.
gcc/
	* cselib.c (cselib_expand_value_rtx_1): Add return.
	* gengtype.c (dbgprint_count_type_at): Likewise.
	* hsa-gen.c (gen_hsa_insn_for_internal_fn_call): Likewise.
	* reg-stack.c (get_true_reg): Restructure to avoid fallthrough warning.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/c-family/ChangeLog
    trunk/gcc/c-family/c-ada-spec.c
    trunk/gcc/cselib.c
    trunk/gcc/gengtype.c
    trunk/gcc/hsa-gen.c
    trunk/gcc/reg-stack.c

Author: mpolacek
Date: Fri Aug 12 10:15:57 2016
New Revision: 239409

URL: https://gcc.gnu.org/viewcvs?rev=239409&root=gcc&view=rev
Log:
	PR c/7652
	* tree-complex.c (expand_complex_division): Add missing break.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/tree-complex.c

Author: mpolacek
Date: Fri Aug 12 10:30:47 2016
New Revision: 239410

URL: https://gcc.gnu.org/viewcvs?rev=239410&root=gcc&view=rev
Log:
	PR c/7652
gcc/
	* alias.c (find_base_value): Adjust fall through comment.
	* cfgexpand.c (expand_debug_expr): Likewise.
	* combine.c (find_split_point): Likewise.
	(expand_compound_operation): Likewise.  Add FALLTHRU.
	(make_compound_operation): Adjust fall through comment.
	(canon_reg_for_combine): Add FALLTHRU.
	(force_to_mode): Adjust fall through comment.
	(simplify_shift_const_1): Likewise.
	(simplify_comparison): Likewise.
	* config/aarch64/aarch64-builtins.c (aarch64_simd_expand_args): Add
	FALLTHRU.
	* config/aarch64/predicates.md: Likewise.
	* config/i386/i386.c (function_arg_advance_32): Likewise.
	(ix86_gimplify_va_arg): Likewise.
	(print_reg): Likewise.
	(ix86_print_operand): Likewise.
	(ix86_build_const_vector): Likewise.
	(ix86_expand_branch): Likewise.
	(ix86_sched_init_global): Adjust fall through comment.
	(ix86_expand_args_builtin): Add FALLTHRU.
	(ix86_expand_builtin): Likewise.
	(ix86_expand_vector_init_one_var): Likewise.
	* config/rs6000/rs6000.c (rs6000_emit_vector_compare_inner): Likewise.
	(rs6000_adjust_cost): Likewise.
	(insn_must_be_first_in_group): Likewise.
	* config/rs6000/rs6000.md: Likewise.  Adjust fall through comment.
	* dbxout.c (dbxout_symbol): Adjust fall through comment.
	* df-scan.c (df_uses_record): Likewise.
	* dojump.c (do_jump): Add FALLTHRU.
	* dwarf2out.c (mem_loc_descriptor): Likewise.  Adjust fall through
	comment.
	(resolve_args_picking_1): Adjust fall through comment.
	(loc_list_from_tree_1): Likewise.
	* expmed.c (make_tree): Likewise.
	* expr.c (expand_expr_real_2): Add FALLTHRU.
	(expand_expr_real_1): Likewise.  Adjust fall through comment.
	* fold-const.c (const_binop): Adjust fall through comment.
	(fold_truth_not_expr): Likewise.
	(fold_cond_expr_with_comparison): Add FALLTHRU.
	(fold_binary_loc): Likewise.
	(contains_label_1): Adjust fall through comment.
	(multiple_of_p): Likewise.
	* gcov-tool.c (process_args): Add FALLTHRU.
	* genattrtab.c (check_attr_test): Likewise.
	(write_test_expr): Likewise.
	* genconfig.c (walk_insn_part): Likewise.
	* genpreds.c (validate_exp): Adjust fall through comment.
	(needs_variable): Likewise.
	* gensupport.c (get_alternatives_number): Add FALLTHRU.
	(subst_dup): Likewise.
	* gimple-pretty-print.c (dump_gimple_assign): Likewise.
	* gimplify.c (gimplify_addr_expr): Adjust fall through comment.
	(gimplify_scan_omp_clauses): Add FALLTHRU.
	(goa_stabilize_expr): Likewise.
	* graphite-isl-ast-to-gimple.c (substitute_ssa_name): Adjust fall
	through comment.
	* hsa-gen.c (get_address_from_value): Likewise.
	* ipa-icf.c (sem_function::hash_stmt): Likewise.
	* ira.c (ira_setup_alts): Add FALLTHRU.
	* lra-eliminations.c (lra_eliminate_regs_1): Adjust fall through
	comment.
	* lto-streamer-out.c (lto_output_tree_ref): Add FALLTHRU.
	* opts.c (common_handle_option): Likewise.
	* read-rtl.c (read_rtx_code): Likewise.
	* real.c (round_for_format): Likewise.
	* recog.c (asm_operand_ok): Likewise.
	* reginfo.c (reg_scan_mark_refs): Adjust fall through comment.
	* reload1.c (set_label_offsets): Likewise.
	(eliminate_regs_1): Likewise.
	(reload_reg_reaches_end_p): Likewise.
	* rtlanal.c (commutative_operand_precedence): Add FALLTHRU.
	(rtx_cost): Likewise.
	* sched-rgn.c (is_exception_free): Likewise.
	* simplify-rtx.c (simplify_rtx): Adjust fall through comment.
	* stor-layout.c (int_mode_for_mode): Likewise.
	* toplev.c (print_to_asm_out_file): Likewise.
	(print_to_stderr): Likewise.
	* tree-cfg.c (gimple_verify_flow_info): Likewise.
	* tree-chrec.c (chrec_fold_plus_1): Add FALLTHRU.
	(chrec_fold_multiply): Likewise.
	(evolution_function_is_invariant_rec_p): Likewise.
	(for_each_scev_op): Likewise.
	* tree-data-ref.c (siv_subscript_p): Likewise.
	(get_references_in_stmt): Likewise.
	* tree.c (find_placeholder_in_expr): Adjust fall through comment.
	(substitute_in_expr): Likewise.
	(type_cache_hasher::equal): Likewise.
	(walk_type_fields): Likewise.
	* var-tracking.c (adjust_mems): Add FALLTHRU.
	(set_dv_changed): Adjust fall through comment.
	* varasm.c (default_function_section): Add FALLTHRU.
gcc/c-family/
	* c-common.c (scalar_to_vector): Adjust fall through comment.
	* c-opts.c (c_common_handle_option): Likewise.
	* c-pragma.c (handle_pragma_pack): Add FALLTHRU.
	* c-pretty-print.c (c_pretty_printer::postfix_expression): Adjust
	fall through comment.
	* cilk.c (extract_free_variables): Add FALLTHRU.
gcc/c/
	* c-parser.c (c_parser_external_declaration): Add FALLTHRU.
	(c_parser_postfix_expression): Likewise.
	* c-typeck.c (build_unary_op): Adjust fall through comment.
	(c_mark_addressable): Likewise.
gcc/cp/
	* call.c (add_builtin_candidate): Add FALLTHRU.
	(build_integral_nontype_arg_conv): Adjust fall through comment.
	(build_new_op_1): Add FALLTHRU.
	(convert_like_real): Adjust fall through comment.
	* class.c (fixed_type_or_null): Likewise.
	* constexpr.c (cxx_eval_constant_expression): Likewise.
	(potential_constant_expression_1): Likewise.  Add FALLTHRU.
	* cp-gimplify.c (cp_gimplify_expr): Adjust fall through comment.
	(cp_fold): Add FALLTHRU.
	* cvt.c (build_expr_type_conversion): Adjust fall through comment.
	* cxx-pretty-print.c (pp_cxx_unqualified_id): Add FALLTHRU.
	(pp_cxx_qualified_id): Likewise.
	(cxx_pretty_printer::constant): Adjust fall through comment.
	(cxx_pretty_printer::primary_expression): Add FALLTHRU.
	(pp_cxx_pm_expression): Adjust fall through comment.
	(cxx_pretty_printer::expression): Add FALLTHRU.
	(cxx_pretty_printer::declaration_specifiers): Reformat code.
	(pp_cxx_type_specifier_seq): Adjust fall through comment.
	(pp_cxx_ptr_operator): Likewise.  Add FALLTHRU.
	* error.c (dump_type): Adjust fall through comment.
	(dump_decl): Likewise.
	* mangle.c (write_type): Likewise.
	* method.c (synthesized_method_walk): Add FALLTHRU.
	* name-lookup.c (arg_assoc_type): Likewise.
	* parser.c (cp_lexer_print_token): Adjust fall through comment.
	(cp_parser_primary_expression): Add FALLTHRU.
	(cp_parser_operator): Likewise.
	* pt.c (find_parameter_packs_r): Likewise.
	(tsubst_aggr_type): Adjust fall through comment.
	* semantics.c (finish_omp_clauses): Add FALLTHRU.
	* tree.c (lvalue_kind): Likewise.
gcc/fortran/
	* decl.c (match_attr_spec): Add FALLTHRU.
	* primary.c (match_arg_list_function): Likewise.
	* resolve.c (resolve_operator): Adjust fall through comment.
	(fixup_charlen): Add FALLTHRU.
	(resolve_allocate_expr): Adjust fall through comment.
	* trans-array.c (gfc_conv_ss_startstride): Add FALLTHRU.
	* trans-intrinsic.c (gfc_conv_intrinsic_len): Adjust fall through
	comment.
gcc/java/
	* expr.c (java_truthvalue_conversion): Adjust fall through comment.
	* jcf-io.c (verify_constant_pool): Likewise.
	* typeck.c (promote_type): Likewise.
gcc/objc/
	* objc-encoding.c (encode_type): Add FALLTHRU.
libcpp/
	* lex.c (search_line_fast): Add FALLTHRU.
	(_cpp_lex_direct): Likewise.
	(cpp_token_val_index): Adjust fall through comment.
	* macro.c (parse_params): Add FALLTHRU.
	* pch.c (count_defs): Adjust fall through comment.
	(write_defs): Likewise.
libiberty/
	* cp-demangle.c (d_print_mod): Add FALLTHRU.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/alias.c
    trunk/gcc/c-family/ChangeLog
    trunk/gcc/c-family/c-common.c
    trunk/gcc/c-family/c-opts.c
    trunk/gcc/c-family/c-pragma.c
    trunk/gcc/c-family/c-pretty-print.c
    trunk/gcc/c-family/cilk.c
    trunk/gcc/c/ChangeLog
    trunk/gcc/c/c-parser.c
    trunk/gcc/c/c-typeck.c
    trunk/gcc/cfgexpand.c
    trunk/gcc/combine.c
    trunk/gcc/config/aarch64/aarch64-builtins.c
    trunk/gcc/config/aarch64/predicates.md
    trunk/gcc/config/i386/i386.c
    trunk/gcc/config/rs6000/rs6000.c
    trunk/gcc/config/rs6000/rs6000.md
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/call.c
    trunk/gcc/cp/class.c
    trunk/gcc/cp/constexpr.c
    trunk/gcc/cp/cp-gimplify.c
    trunk/gcc/cp/cvt.c
    trunk/gcc/cp/cxx-pretty-print.c
    trunk/gcc/cp/error.c
    trunk/gcc/cp/mangle.c
    trunk/gcc/cp/method.c
    trunk/gcc/cp/name-lookup.c
    trunk/gcc/cp/parser.c
    trunk/gcc/cp/pt.c
    trunk/gcc/cp/semantics.c
    trunk/gcc/cp/tree.c
    trunk/gcc/dbxout.c
    trunk/gcc/df-scan.c
    trunk/gcc/dojump.c
    trunk/gcc/dwarf2out.c
    trunk/gcc/expmed.c
    trunk/gcc/expr.c
    trunk/gcc/fold-const.c
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/decl.c
    trunk/gcc/fortran/primary.c
    trunk/gcc/fortran/resolve.c
    trunk/gcc/fortran/trans-array.c
    trunk/gcc/fortran/trans-intrinsic.c
    trunk/gcc/gcov-tool.c
    trunk/gcc/genattrtab.c
    trunk/gcc/genconfig.c
    trunk/gcc/genpreds.c
    trunk/gcc/gensupport.c
    trunk/gcc/gimple-pretty-print.c
    trunk/gcc/gimplify.c
    trunk/gcc/graphite-isl-ast-to-gimple.c
    trunk/gcc/hsa-gen.c
    trunk/gcc/ipa-icf.c
    trunk/gcc/ira.c
    trunk/gcc/java/ChangeLog
    trunk/gcc/java/expr.c
    trunk/gcc/java/jcf-io.c
    trunk/gcc/java/typeck.c
    trunk/gcc/lra-eliminations.c
    trunk/gcc/lto-streamer-out.c
    trunk/gcc/objc/ChangeLog
    trunk/gcc/objc/objc-encoding.c
    trunk/gcc/opts.c
    trunk/gcc/read-rtl.c
    trunk/gcc/real.c
    trunk/gcc/recog.c
    trunk/gcc/reginfo.c
    trunk/gcc/reload1.c
    trunk/gcc/rtlanal.c
    trunk/gcc/sched-rgn.c
    trunk/gcc/simplify-rtx.c
    trunk/gcc/stor-layout.c
    trunk/gcc/toplev.c
    trunk/gcc/tree-cfg.c
    trunk/gcc/tree-chrec.c
    trunk/gcc/tree-data-ref.c
    trunk/gcc/tree.c
    trunk/gcc/var-tracking.c
    trunk/gcc/varasm.c
    trunk/libcpp/ChangeLog
    trunk/libcpp/lex.c
    trunk/libcpp/macro.c
    trunk/libcpp/pch.c
    trunk/libiberty/ChangeLog
    trunk/libiberty/cp-demangle.c

Author: mpolacek
Date: Thu Aug 18 10:28:03 2016
New Revision: 239566

URL: https://gcc.gnu.org/viewcvs?rev=239566&root=gcc&view=rev
Log:
	PR c/7652
gcc/cp/
	* call.c (add_builtin_candidate): Add gcc_fallthrough.
	* cxx-pretty-print.c (pp_cxx_unqualified_id): Likewise.
	* parser.c (cp_parser_skip_to_end_of_statement): Likewise.
	(cp_parser_cache_defarg): Likewise.
libcpp/
	* pch.c (write_macdef): Add CPP_FALLTHRU.

Modified:
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/call.c
    trunk/gcc/cp/cxx-pretty-print.c
    trunk/gcc/cp/parser.c
    trunk/libcpp/ChangeLog
    trunk/libcpp/pch.c

Author: mpolacek
Date: Thu Sep  1 14:59:50 2016
New Revision: 239939

URL: https://gcc.gnu.org/viewcvs?rev=239939&root=gcc&view=rev
Log:
	PR c/7652
gcc/c-family/
	* c-common.c (resolve_overloaded_builtin): Fix formatting.  Add
	FALLTHRU comments.
gcc/c/
	* c-typeck.c (composite_type): Add FALLTHRU comment.
gcc/gcc/cp/
	* error.c (dump_type): Fix falls through comment.
	(dump_decl): Likewise.
	(dump_expr): Likewise.

Modified:
    trunk/gcc/c-family/ChangeLog
    trunk/gcc/c-family/c-common.c
    trunk/gcc/c/ChangeLog
    trunk/gcc/c/c-typeck.c
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/error.c

The -Wimplicit-fallthrough patch has been committed.