[Bug c/7652] -Wswitch-break : Warn if a switch case falls through

[Bug c/7652] -Wswitch-break : Warn if a switch case falls through

[alsuren+gcc at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652

David Laban <alsuren+gcc at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |alsuren+gcc at gmail dot
                   |                            |com

--- Comment #5 from David Laban <alsuren+gcc at gmail dot com> 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.

[Bug c/7652] -Wswitch-break : Warn if a switch case falls through

[barnes.leo at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652

Leo Barnes <barnes.leo at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |barnes.leo at gmail dot com

--- Comment #6 from Leo Barnes <barnes.leo at gmail dot com> 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.

[Bug c/7652] -Wswitch-break : Warn if a switch case falls through

[daniel.marjamaki at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652

Daniel Marjamäki <daniel.marjamaki at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |daniel.marjamaki at gmail
                   |                            |dot com

--- Comment #7 from Daniel Marjamäki <daniel.marjamaki at gmail dot com> 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
    };

[Bug c/7652] -Wswitch-break : Warn if a switch case falls through

[eric at brouhaha dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652

Eric Smith <eric at brouhaha dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |eric at brouhaha dot com

--- Comment #8 from Eric Smith <eric at brouhaha dot com> 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.

[Bug c/7652] -Wswitch-break : Warn if a switch case falls through

[eric at brouhaha dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652

--- Comment #9 from Eric Smith <eric at brouhaha dot com> 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");
}

[Bug c/7652] -Wswitch-break : Warn if a switch case falls through

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |david at doublewise dot net

--- Comment #10 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-07-14 04:54:03 UTC ---
*** Bug 53960 has been marked as a duplicate of this bug. ***

[Bug c/7652] -Wswitch-break : Warn if a switch case falls through

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2005-12-10 05:44:21         |2012-07-14
                 CC|                            |redi at gcc dot gnu.org
      Known to fail|                            |

--- Comment #11 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-07-14 11:52:52 UTC ---
As noted in Bug 53960 Clang now implements this warning.

[Bug c/7652] -Wswitch-break : Warn if a switch case falls through

[david at doublewise dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652

--- Comment #12 from David Stone <david at doublewise dot net> 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.

[Bug c/7652] -Wswitch-break : Warn if a switch case falls through

[alexfh at google dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652

Alexander Kornienko <alexfh at google dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |alexfh at google dot com

--- Comment #13 from Alexander Kornienko <alexfh at google dot com> 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.

[Bug c/7652] -Wswitch-break : Warn if a switch case falls through

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |manu at gcc dot gnu.org

--- Comment #14 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 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.

[Bug c/7652] -Wswitch-break : Warn if a switch case falls through

[arthur.j.odwyer at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652

Arthur O'Dwyer <arthur.j.odwyer at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |arthur.j.odwyer at gmail
                   |                            |dot com

--- Comment #15 from Arthur O'Dwyer <arthur.j.odwyer at gmail dot com> 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. :)

[Bug c/7652] -Wswitch-break : Warn if a switch case falls through

[arthur.j.odwyer at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652

--- Comment #16 from Arthur O'Dwyer <arthur.j.odwyer at gmail dot com> 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

[Bug c/7652] -Wswitch-break : Warn if a switch case falls through

[dcb314 at hotmail dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 3613 bytes --]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652

David Binderman <dcb314 at hotmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dcb314 at hotmail dot com

--- Comment #17 from David Binderman <dcb314 at hotmail dot com> ---
(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.
>From gcc-bugs-return-424878-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Jun 23 07:15:01 2013
Return-Path: <gcc-bugs-return-424878-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 29995 invoked by alias); 23 Jun 2013 07:15:00 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 29318 invoked by uid 48); 23 Jun 2013 07:14:54 -0000
From: "webrown.cpp at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/57682] New: Uniform initialization syntax rejected in function-try-block
Date: Sun, 23 Jun 2013 07:15:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: webrown.cpp at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter attachments.created
Message-ID: <bug-57682-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-06/txt/msg01257.txt.bz2
Content-length: 911

http://gcc.gnu.org/bugzilla/show_bug.cgi?idW682

            Bug ID: 57682
           Summary: Uniform initialization syntax rejected in
                    function-try-block
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: webrown.cpp at gmail dot com

Created attachment 30342
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id0342&actioníit
Source file demonstrating issue

Compiling via:
  g++-mp-4.9 -std=gnu++1y -c bug.cc

Using version:
  g++-mp-4.9 (MacPorts gcc49 4.9-20130616_0) 4.9.0 20130616 (experimental)

Using paren's to initialize a data member will compile successfully, but using
braces in their place produces a diagnostic.  Define/undefine the OOPS macro in
the attachment to reproduce failure/success.

[Bug c/7652] -Wswitch-break : Warn if a switch case falls through

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652

--- Comment #18 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(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 ;-)
>From gcc-bugs-return-424886-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Jun 23 10:58:05 2013
Return-Path: <gcc-bugs-return-424886-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 19239 invoked by alias); 23 Jun 2013 10:58:05 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 19217 invoked by uid 48); 23 Jun 2013 10:58:02 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/57653] filename information discarded when using -imacros
Date: Sun, 23 Jun 2013 10:58:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: 4.8.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: manu at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status cf_reconfirmed_on everconfirmed
Message-ID: <bug-57653-4-aGNSMTCkmr@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57653-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57653-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-06/txt/msg01265.txt.bz2
Content-length: 2442

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57653

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-06-23
     Ever confirmed|0                           |1

--- Comment #9 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Allan McRae from comment #8)
> I really have no idea what I am looking for...  but adding a breakpoint at
> linemap_add I see (reason, file):
> 
> LC_ENTER "foo.c"
> LC_RENAME "<command-line>"
> LC_ENTER "/usr/include/stdc-predef.h"
> LC_LEAVE 0x0
> LC_RENAME "foo.c"
> <- correct output printed here
> LC_LEAVE 0x0
> 
> LC_ENTER "foo.c"
> LC_RENAME "<command-line>"
> LC_ENTER "foo.h"
> LC_LEAVE 0x0
> LC_ENTER "/usr/include/stdc-predef.h"
> LC_RENAME "foo.c"
> LC_LEAVE 0x0
> <- incorrect output printed here
> LC_LEAVE 0x0
> 
> So it looks like it is not leaving "/usr/include/stdc-predef.h" at the right
> time so the wrong thing is being renamed?

It seems a probable cause for this bug. Can you track where the return paths
differ? 

Does 

LC_ENTER "/usr/include/stdc-predef.h"

happen through the same functions in both cases?

and the LC_LEAVE 0x0 just afterwards?

Perhaps there is a missing LC_LEAVE or perhaps the order between 

 LC_RENAME "foo.c"
 LC_LEAVE 0x0

should be reversed.

Strangely, I still cannot reproduce this:

manuel@gcc10:~$ ~/test1/200330/install/bin/gcc -imacros foo.h foo.c
foo.c: In function ‘main’:
foo.c:1:21: error: expected expression before ‘}’ token
 int main() { return }
                     ^
manuel@gcc10:~$ ~/test1/200330/install/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/home/manuel/test1/200330/install/bin/gcc
COLLECT_LTO_WRAPPER=/home/manuel/test1/200330/install/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/manuel/test1/src/configure
--prefix=/home/manuel/test1/./200330/install
--enable-languages=c,c++,objc,fortran,ada,obj-c++
Thread model: posix
gcc version 4.9.0 20130622 (experimental) [trunk revision 195333] (GCC) 

Are you sure you don't have some local arch-linux patches? Have you tried
directly downloading the svn version?
>From gcc-bugs-return-424887-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Jun 23 10:59:18 2013
Return-Path: <gcc-bugs-return-424887-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 20061 invoked by alias); 23 Jun 2013 10:59:18 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 20039 invoked by uid 48); 23 Jun 2013 10:59:15 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/57653] filename information discarded when using -imacros
Date: Sun, 23 Jun 2013 10:59:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: 4.8.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: manu at gcc dot gnu.org
X-Bugzilla-Status: WAITING
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status
Message-ID: <bug-57653-4-h1fMdVtUCQ@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57653-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57653-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-06/txt/msg01266.txt.bz2
Content-length: 476

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57653

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING

--- Comment #10 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
Sorry, I didn't intend to confirm it until someone else can reproduce it.
>From gcc-bugs-return-424888-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Jun 23 11:23:04 2013
Return-Path: <gcc-bugs-return-424888-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 30866 invoked by alias); 23 Jun 2013 11:23:04 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 30769 invoked by uid 48); 23 Jun 2013 11:22:59 -0000
From: "bluescarni at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/57684] New: [c++11] Lambda is not convertible to std::function
Date: Sun, 23 Jun 2013 11:23:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.8.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: bluescarni at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter attachments.created
Message-ID: <bug-57684-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-06/txt/msg01267.txt.bz2
Content-length: 3794

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57684

            Bug ID: 57684
           Summary: [c++11] Lambda is not convertible to std::function
           Product: gcc
           Version: 4.8.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: bluescarni at gmail dot com

Created attachment 30344
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30344&action=edit
Code snippet demonstrating the problem.

A specific setup with CRTP pattern and a static unordered_map member in the
base class is preventing conversion from a lambda expression to an
std::function. The problem is reproduced in the attached code snippet. The
error produced by GCC 4.8.1 is:

----
main.cpp: In function ‘int main()’:
main.cpp:20:3: error: no matching function for call to
‘std::function<derived(const derived&)>::function(main()::__lambda0)’
  });
   ^
main.cpp:20:3: note: candidates are:
In file included from main.cpp:1:0:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/include/g++-v4/functional:2255:2: note:
template<class _Functor, class> std::function<_Res(_ArgTypes
...)>::function(_Functor)
  function(_Functor);
  ^
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/include/g++-v4/functional:2255:2: note: 
 template argument deduction/substitution failed:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/include/g++-v4/functional:2230:7: note:
std::function<_Res(_ArgTypes ...)>::function(std::function<_Res(_ArgTypes
...)>&&) [with _Res = derived; _ArgTypes = {const derived&}]
       function(function&& __x) : _Function_base()
       ^
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/include/g++-v4/functional:2230:7: note: 
 no known conversion for argument 1 from ‘main()::__lambda0’ to
‘std::function<derived(const derived&)>&&’
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/include/g++-v4/functional:2433:5: note:
std::function<_Res(_ArgTypes ...)>::function(const std::function<_Res(_ArgTypes
...)>&) [with _Res = derived; _ArgTypes = {const derived&}]
     function<_Res(_ArgTypes...)>::
     ^
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/include/g++-v4/functional:2433:5: note: 
 no known conversion for argument 1 from ‘main()::__lambda0’ to ‘const
std::function<derived(const derived&)>&’
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/include/g++-v4/functional:2210:7: note:
std::function<_Res(_ArgTypes ...)>::function(std::nullptr_t) [with _Res =
derived; _ArgTypes = {const derived&}; std::nullptr_t = std::nullptr_t]
       function(nullptr_t) noexcept
       ^
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/include/g++-v4/functional:2210:7: note: 
 no known conversion for argument 1 from ‘main()::__lambda0’ to
‘std::nullptr_t’
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/include/g++-v4/functional:2203:7: note:
std::function<_Res(_ArgTypes ...)>::function() [with _Res = derived; _ArgTypes
= {const derived&}]
       function() noexcept
       ^
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/include/g++-v4/functional:2203:7: note: 
 candidate expects 0 arguments, 1 provided
----

(Sorry for not being able to reduce the test case further, but I was able to
reproduce the problem only by pulling in std::unordered_map. GCC 4.7.3 and
Clang++ 3.3 both compile the snippet without errors.)

The problem disappears if one replaces the static member definition with one of
the commented lines or even if one replaces the existing main() body with this:

----
    std::function<void (const derived &)> foo([](const derived &d) {
        return d;
    });
----

I.e., by changing the std::function to return void instead of derived.
>From gcc-bugs-return-424889-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Jun 23 12:01:49 2013
Return-Path: <gcc-bugs-return-424889-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 10086 invoked by alias); 23 Jun 2013 12:01:49 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 10006 invoked by uid 48); 23 Jun 2013 12:01:41 -0000
From: "dominiq at lps dot ens.fr" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/52413] Incorrect behavior of FRACTION when applied to a constant
Date: Sun, 23 Jun 2013 12:01:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 4.8.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: dominiq at lps dot ens.fr
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P4
X-Bugzilla-Assigned-To: kargl at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-52413-4-VlwBvqxtu9@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-52413-4@http.gcc.gnu.org/bugzilla/>
References: <bug-52413-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-06/txt/msg01268.txt.bz2
Content-length: 745

http://gcc.gnu.org/bugzilla/show_bug.cgi?idR413

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #5 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> I do not have any problems if you want to pick up where I left
> off with this bug.  I simply do not have much time for gfortran
> anymore.

The problem with the patch in comment #1 is that it uses mpfr_frexp which has
been introduced in the mpfr release 3.1.0. AFAICT the GCC prerequisite is
2.4.2. Is there any plan to bump the prerequisite version?

[Bug c/7652] -Wswitch-break : Warn if a switch case falls through

[jasonwucj at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652

Chung-Ju Wu <jasonwucj at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jasonwucj at gmail dot com

--- Comment #19 from Chung-Ju Wu <jasonwucj at gmail dot com> ---
(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.
>From gcc-bugs-return-424895-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Jun 23 12:25:40 2013
Return-Path: <gcc-bugs-return-424895-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 20466 invoked by alias); 23 Jun 2013 12:25:40 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 20443 invoked by uid 48); 23 Jun 2013 12:25:36 -0000
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/57684] [c++11] Lambda is not convertible to std::function
Date: Sun, 23 Jun 2013 12:25:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.8.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: redi at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-57684-4-SJSSHIcDVs@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57684-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57684-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-06/txt/msg01274.txt.bz2
Content-length: 569

http://gcc.gnu.org/bugzilla/show_bug.cgi?idW684

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Yes, because std::unique_ptr has a special exception that says it can be
instantiated with incomplete types, so that should work OK (like your case
where the static member is a raw pointer, which prevents unordered_map being
instantiated when base<> is instantiated.

I hope for GCC 4.9 we can make unordered_map support incomplete types again, so
the original code would work, but it doesn't support them currently, which is
allowed by the standard.

[Bug c/7652] -Wswitch-break : Warn if a switch case falls through

[jackie.rosen at hushmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652

Jackie Rosen <jackie.rosen at hushmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jackie.rosen at hushmail dot com

--- Comment #20 from Jackie Rosen <jackie.rosen at hushmail dot com> ---
*** Bug 260998 has been marked as a duplicate of this bug. ***
Seen from the domain http://volichat.com
Page where seen: http://volichat.com/adult-chat-rooms
Marked for reference. Resolved as fixed @bugzilla.

[Bug c/7652] -Wswitch-break : Warn if a switch case falls through

[michael.chapman at cortus dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652

Michael Chapman <michael.chapman at cortus dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |michael.chapman at cortus dot com

--- Comment #21 from Michael Chapman <michael.chapman at cortus dot com> ---
Created attachment 32716
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32716&action=edit
Proposed patch

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

[Bug c/7652] -Wswitch-break : Warn if a switch case falls through

[mw_triad at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652

--- Comment #22 from Matthew Woehlke <mw_triad at users dot sourceforge.net> ---
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;
}

[Bug c/7652] -Wswitch-break : Warn if a switch case falls through

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652

--- Comment #23 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(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.
>From gcc-bugs-return-450267-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Apr 30 16:11:49 2014
Return-Path: <gcc-bugs-return-450267-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 26929 invoked by alias); 30 Apr 2014 16:11:49 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 26847 invoked by uid 48); 30 Apr 2014 16:11:45 -0000
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/7652] -Wswitch-break : Warn if a switch case falls through
Date: Wed, 30 Apr 2014 16:11:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: redi at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-7652-4-lF15yFbDVj@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-7652-4@http.gcc.gnu.org/bugzilla/>
References: <bug-7652-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-04/txt/msg02287.txt.bz2
Content-length: 385

http://gcc.gnu.org/bugzilla/show_bug.cgi?idv52

--- Comment #24 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(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

[Bug c/7652] -Wswitch-break : Warn if a switch case falls through

[fweimer at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652

--- Comment #25 from Florian Weimer <fweimer at redhat dot com> ---
(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.

[Bug c/7652] -Wswitch-break : Warn if a switch case falls through

[mpolacek at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mpolacek at gcc dot gnu.org

--- Comment #26 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
(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.

[Bug c/7652] -Wswitch-break : Warn if a switch case falls through

[alexfh at google dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652

--- Comment #28 from Alexander Kornienko <alexfh at google dot com> ---
(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:
    ...

[Bug c/7652] -Wswitch-break : Warn if a switch case falls through

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652

--- Comment #29 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(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.
>From gcc-bugs-return-450276-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Apr 30 16:47:39 2014
Return-Path: <gcc-bugs-return-450276-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 969 invoked by alias); 30 Apr 2014 16:47:39 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 737 invoked by uid 48); 30 Apr 2014 16:47:34 -0000
From: "fweimer at redhat dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/7652] -Wswitch-break : Warn if a switch case falls through
Date: Wed, 30 Apr 2014 16:47:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: fweimer at redhat dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-7652-4-GzLKcgIvZP@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-7652-4@http.gcc.gnu.org/bugzilla/>
References: <bug-7652-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-04/txt/msg02296.txt.bz2
Content-length: 683

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652

--- Comment #30 from Florian Weimer <fweimer at redhat dot com> ---
(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.
>From gcc-bugs-return-450277-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Apr 30 16:54:57 2014
Return-Path: <gcc-bugs-return-450277-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 10431 invoked by alias); 30 Apr 2014 16:54:57 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 10355 invoked by uid 48); 30 Apr 2014 16:54:53 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/7652] -Wswitch-break : Warn if a switch case falls through
Date: Wed, 30 Apr 2014 16:54:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: manu at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-7652-4-vsuK6xyrSW@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-7652-4@http.gcc.gnu.org/bugzilla/>
References: <bug-7652-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-04/txt/msg02297.txt.bz2
Content-length: 835

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652

--- Comment #31 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(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.
>From gcc-bugs-return-450278-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Apr 30 17:02:02 2014
Return-Path: <gcc-bugs-return-450278-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 21488 invoked by alias); 30 Apr 2014 17:02:02 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 21437 invoked by uid 48); 30 Apr 2014 17:01:58 -0000
From: "jason at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/60992] [4.9/4.10 Regression] ICE in tsubst_copy, at cp/pt.c:12637
Date: Wed, 30 Apr 2014 17:02:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jason at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: jason at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.1
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status assigned_to
Message-ID: <bug-60992-4-v8vgBMNCsU@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60992-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60992-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-04/txt/msg02298.txt.bz2
Content-length: 374

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`992

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |jason at gcc dot gnu.org

[Bug c/7652] -Wswitch-break : Warn if a switch case falls through

[mw_triad at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652

--- Comment #32 from Matthew Woehlke <mw_triad at users dot sourceforge.net> ---
(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...)

[Bug c/7652] -Wswitch-break : Warn if a switch case falls through

[michael.chapman at cortus dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652

--- Comment #33 from Michael Chapman <michael.chapman at cortus dot com> ---
(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:
         ....
>From gcc-bugs-return-450284-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Apr 30 17:27:48 2014
Return-Path: <gcc-bugs-return-450284-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 11494 invoked by alias); 30 Apr 2014 17:27:48 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 11469 invoked by uid 48); 30 Apr 2014 17:27:44 -0000
From: "ppluzhnikov at google dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/61020] New: [4.9/4.10 Regression] typeid(typeid(X)) produces 'ud2'
Date: Wed, 30 Apr 2014 17:27:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ppluzhnikov at google dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter
Message-ID: <bug-61020-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-04/txt/msg02304.txt.bz2
Content-length: 1275

http://gcc.gnu.org/bugzilla/show_bug.cgi?ida020

            Bug ID: 61020
           Summary: [4.9/4.10 Regression] typeid(typeid(X)) produces 'ud2'
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ppluzhnikov at google dot com

The test case:

#include <typeinfo>

struct Base {
  virtual ~Base() { }
};

struct Derived : public Base {
};

int compare(const Base& base)
{
  return typeid(base) == typeid(typeid(Derived));
}

int main()
{
  Base base;
  Derived derived;

  if (compare(base)) return 1;
  if (compare(derived)) return 2;
  return 0;
}


Using trunk @ r209848
g++ -g t.cc && ./a.out && echo OK
OK

g++ -g t.cc -O2 && ./a.out
Segmentation fault (core dumped)

(gdb) disas main
Dump of assembler code for function main():
   0x00000000004004c0 <+0>:     mov    0x8,%rax
   0x00000000004004c8 <+8>:     ud2
End of assembler dump.


It appears that GCC believes the test to invoke undefined behavior.
However, I don't see anything in the standard to support this.

P.S. Same result in C++98 and C++11
P.P.S. In the original code, the double application of typeid() was a bug.

[Bug c/7652] -Wswitch-break : Warn if a switch case falls through

[m.j.thayer at googlemail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652

Michael T. <m.j.thayer at googlemail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |m.j.thayer at googlemail dot com

--- Comment #35 from Michael T. <m.j.thayer at googlemail dot com> ---
(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

[Bug c/7652] -Wswitch-break : Warn if a switch case falls through

[pinskia at gcc dot gnu dot org]

------- Comment #4 from pinskia at gcc dot gnu dot org  2010-03-04 20:48 -------
*** Bug 43250 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |eugene dot zelenko at gmail
                   |                            |dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652

[Bug c/7652] -Wswitch-break : Warn if a switch case falls through

[brendan at zen dot org]

------- Additional Comments From brendan at zen dot org  2004-07-29 09:43 -------
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 
 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652