* [Bug c/7652] -Wswitch-break : Warn if a switch case falls through
[not found] <bug-7652-4@http.gcc.gnu.org/bugzilla/>
@ 2011-02-02 1:04 ` alsuren+gcc at gmail dot com
2011-05-09 14:48 ` barnes.leo at gmail dot com
` (24 subsequent siblings)
25 siblings, 0 replies; 28+ messages in thread
From: alsuren+gcc at gmail dot com @ 2011-02-02 1:04 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug c/7652] -Wswitch-break : Warn if a switch case falls through
[not found] <bug-7652-4@http.gcc.gnu.org/bugzilla/>
2011-02-02 1:04 ` [Bug c/7652] -Wswitch-break : Warn if a switch case falls through alsuren+gcc at gmail dot com
@ 2011-05-09 14:48 ` barnes.leo at gmail dot com
2011-07-29 13:29 ` daniel.marjamaki at gmail dot com
` (23 subsequent siblings)
25 siblings, 0 replies; 28+ messages in thread
From: barnes.leo at gmail dot com @ 2011-05-09 14:48 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug c/7652] -Wswitch-break : Warn if a switch case falls through
[not found] <bug-7652-4@http.gcc.gnu.org/bugzilla/>
2011-02-02 1:04 ` [Bug c/7652] -Wswitch-break : Warn if a switch case falls through alsuren+gcc at gmail dot com
2011-05-09 14:48 ` barnes.leo at gmail dot com
@ 2011-07-29 13:29 ` daniel.marjamaki at gmail dot com
2012-02-21 1:04 ` eric at brouhaha dot com
` (22 subsequent siblings)
25 siblings, 0 replies; 28+ messages in thread
From: daniel.marjamaki at gmail dot com @ 2011-07-29 13:29 UTC (permalink / raw)
To: gcc-bugs
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
};
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug c/7652] -Wswitch-break : Warn if a switch case falls through
[not found] <bug-7652-4@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2011-07-29 13:29 ` daniel.marjamaki at gmail dot com
@ 2012-02-21 1:04 ` eric at brouhaha dot com
2012-02-21 1:14 ` eric at brouhaha dot com
` (21 subsequent siblings)
25 siblings, 0 replies; 28+ messages in thread
From: eric at brouhaha dot com @ 2012-02-21 1:04 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug c/7652] -Wswitch-break : Warn if a switch case falls through
[not found] <bug-7652-4@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2012-02-21 1:04 ` eric at brouhaha dot com
@ 2012-02-21 1:14 ` eric at brouhaha dot com
2012-07-14 4:55 ` pinskia at gcc dot gnu.org
` (20 subsequent siblings)
25 siblings, 0 replies; 28+ messages in thread
From: eric at brouhaha dot com @ 2012-02-21 1:14 UTC (permalink / raw)
To: gcc-bugs
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");
}
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug c/7652] -Wswitch-break : Warn if a switch case falls through
[not found] <bug-7652-4@http.gcc.gnu.org/bugzilla/>
` (4 preceding siblings ...)
2012-02-21 1:14 ` eric at brouhaha dot com
@ 2012-07-14 4:55 ` pinskia at gcc dot gnu.org
2012-07-14 11:54 ` redi at gcc dot gnu.org
` (19 subsequent siblings)
25 siblings, 0 replies; 28+ messages in thread
From: pinskia at gcc dot gnu.org @ 2012-07-14 4:55 UTC (permalink / raw)
To: gcc-bugs
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. ***
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug c/7652] -Wswitch-break : Warn if a switch case falls through
[not found] <bug-7652-4@http.gcc.gnu.org/bugzilla/>
` (5 preceding siblings ...)
2012-07-14 4:55 ` pinskia at gcc dot gnu.org
@ 2012-07-14 11:54 ` redi at gcc dot gnu.org
2012-07-14 15:15 ` david at doublewise dot net
` (18 subsequent siblings)
25 siblings, 0 replies; 28+ messages in thread
From: redi at gcc dot gnu.org @ 2012-07-14 11:54 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug c/7652] -Wswitch-break : Warn if a switch case falls through
[not found] <bug-7652-4@http.gcc.gnu.org/bugzilla/>
` (6 preceding siblings ...)
2012-07-14 11:54 ` redi at gcc dot gnu.org
@ 2012-07-14 15:15 ` david at doublewise dot net
2012-09-17 22:02 ` alexfh at google dot com
` (17 subsequent siblings)
25 siblings, 0 replies; 28+ messages in thread
From: david at doublewise dot net @ 2012-07-14 15:15 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug c/7652] -Wswitch-break : Warn if a switch case falls through
[not found] <bug-7652-4@http.gcc.gnu.org/bugzilla/>
` (7 preceding siblings ...)
2012-07-14 15:15 ` david at doublewise dot net
@ 2012-09-17 22:02 ` alexfh at google dot com
2012-09-18 11:12 ` manu at gcc dot gnu.org
` (16 subsequent siblings)
25 siblings, 0 replies; 28+ messages in thread
From: alexfh at google dot com @ 2012-09-17 22:02 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug c/7652] -Wswitch-break : Warn if a switch case falls through
[not found] <bug-7652-4@http.gcc.gnu.org/bugzilla/>
` (8 preceding siblings ...)
2012-09-17 22:02 ` alexfh at google dot com
@ 2012-09-18 11:12 ` manu at gcc dot gnu.org
2012-11-26 22:49 ` arthur.j.odwyer at gmail dot com
` (15 subsequent siblings)
25 siblings, 0 replies; 28+ messages in thread
From: manu at gcc dot gnu.org @ 2012-09-18 11:12 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug c/7652] -Wswitch-break : Warn if a switch case falls through
[not found] <bug-7652-4@http.gcc.gnu.org/bugzilla/>
` (9 preceding siblings ...)
2012-09-18 11:12 ` manu at gcc dot gnu.org
@ 2012-11-26 22:49 ` arthur.j.odwyer at gmail dot com
2012-11-26 23:03 ` arthur.j.odwyer at gmail dot com
` (14 subsequent siblings)
25 siblings, 0 replies; 28+ messages in thread
From: arthur.j.odwyer at gmail dot com @ 2012-11-26 22:49 UTC (permalink / raw)
To: gcc-bugs
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. :)
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug c/7652] -Wswitch-break : Warn if a switch case falls through
[not found] <bug-7652-4@http.gcc.gnu.org/bugzilla/>
` (10 preceding siblings ...)
2012-11-26 22:49 ` arthur.j.odwyer at gmail dot com
@ 2012-11-26 23:03 ` arthur.j.odwyer at gmail dot com
2013-06-23 6:44 ` dcb314 at hotmail dot com
` (13 subsequent siblings)
25 siblings, 0 replies; 28+ messages in thread
From: arthur.j.odwyer at gmail dot com @ 2012-11-26 23:03 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug c/7652] -Wswitch-break : Warn if a switch case falls through
[not found] <bug-7652-4@http.gcc.gnu.org/bugzilla/>
` (11 preceding siblings ...)
2012-11-26 23:03 ` arthur.j.odwyer at gmail dot com
@ 2013-06-23 6:44 ` dcb314 at hotmail dot com
2013-06-23 10:38 ` manu at gcc dot gnu.org
` (12 subsequent siblings)
25 siblings, 0 replies; 28+ messages in thread
From: dcb314 at hotmail dot com @ 2013-06-23 6:44 UTC (permalink / raw)
To: gcc-bugs
[-- 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.
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug c/7652] -Wswitch-break : Warn if a switch case falls through
[not found] <bug-7652-4@http.gcc.gnu.org/bugzilla/>
` (12 preceding siblings ...)
2013-06-23 6:44 ` dcb314 at hotmail dot com
@ 2013-06-23 10:38 ` manu at gcc dot gnu.org
2013-06-23 12:21 ` jasonwucj at gmail dot com
` (11 subsequent siblings)
25 siblings, 0 replies; 28+ messages in thread
From: manu at gcc dot gnu.org @ 2013-06-23 10:38 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug c/7652] -Wswitch-break : Warn if a switch case falls through
[not found] <bug-7652-4@http.gcc.gnu.org/bugzilla/>
` (13 preceding siblings ...)
2013-06-23 10:38 ` manu at gcc dot gnu.org
@ 2013-06-23 12:21 ` jasonwucj at gmail dot com
2014-02-16 13:18 ` jackie.rosen at hushmail dot com
` (10 subsequent siblings)
25 siblings, 0 replies; 28+ messages in thread
From: jasonwucj at gmail dot com @ 2013-06-23 12:21 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug c/7652] -Wswitch-break : Warn if a switch case falls through
[not found] <bug-7652-4@http.gcc.gnu.org/bugzilla/>
` (14 preceding siblings ...)
2013-06-23 12:21 ` jasonwucj at gmail dot com
@ 2014-02-16 13:18 ` jackie.rosen at hushmail dot com
2014-04-30 15:45 ` michael.chapman at cortus dot com
` (9 subsequent siblings)
25 siblings, 0 replies; 28+ messages in thread
From: jackie.rosen at hushmail dot com @ 2014-02-16 13:18 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug c/7652] -Wswitch-break : Warn if a switch case falls through
[not found] <bug-7652-4@http.gcc.gnu.org/bugzilla/>
` (15 preceding siblings ...)
2014-02-16 13:18 ` jackie.rosen at hushmail dot com
@ 2014-04-30 15:45 ` michael.chapman at cortus dot com
2014-04-30 16:09 ` mw_triad at users dot sourceforge.net
` (8 subsequent siblings)
25 siblings, 0 replies; 28+ messages in thread
From: michael.chapman at cortus dot com @ 2014-04-30 15:45 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug c/7652] -Wswitch-break : Warn if a switch case falls through
[not found] <bug-7652-4@http.gcc.gnu.org/bugzilla/>
` (16 preceding siblings ...)
2014-04-30 15:45 ` michael.chapman at cortus dot com
@ 2014-04-30 16:09 ` mw_triad at users dot sourceforge.net
2014-04-30 16:10 ` manu at gcc dot gnu.org
` (7 subsequent siblings)
25 siblings, 0 replies; 28+ messages in thread
From: mw_triad at users dot sourceforge.net @ 2014-04-30 16:09 UTC (permalink / raw)
To: gcc-bugs
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;
}
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug c/7652] -Wswitch-break : Warn if a switch case falls through
[not found] <bug-7652-4@http.gcc.gnu.org/bugzilla/>
` (17 preceding siblings ...)
2014-04-30 16:09 ` mw_triad at users dot sourceforge.net
@ 2014-04-30 16:10 ` manu at gcc dot gnu.org
2014-04-30 16:18 ` fweimer at redhat dot com
` (6 subsequent siblings)
25 siblings, 0 replies; 28+ messages in thread
From: manu at gcc dot gnu.org @ 2014-04-30 16:10 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug c/7652] -Wswitch-break : Warn if a switch case falls through
[not found] <bug-7652-4@http.gcc.gnu.org/bugzilla/>
` (18 preceding siblings ...)
2014-04-30 16:10 ` manu at gcc dot gnu.org
@ 2014-04-30 16:18 ` fweimer at redhat dot com
2014-04-30 16:23 ` mpolacek at gcc dot gnu.org
` (5 subsequent siblings)
25 siblings, 0 replies; 28+ messages in thread
From: fweimer at redhat dot com @ 2014-04-30 16:18 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug c/7652] -Wswitch-break : Warn if a switch case falls through
[not found] <bug-7652-4@http.gcc.gnu.org/bugzilla/>
` (19 preceding siblings ...)
2014-04-30 16:18 ` fweimer at redhat dot com
@ 2014-04-30 16:23 ` mpolacek at gcc dot gnu.org
2014-04-30 16:35 ` alexfh at google dot com
` (4 subsequent siblings)
25 siblings, 0 replies; 28+ messages in thread
From: mpolacek at gcc dot gnu.org @ 2014-04-30 16:23 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug c/7652] -Wswitch-break : Warn if a switch case falls through
[not found] <bug-7652-4@http.gcc.gnu.org/bugzilla/>
` (20 preceding siblings ...)
2014-04-30 16:23 ` mpolacek at gcc dot gnu.org
@ 2014-04-30 16:35 ` alexfh at google dot com
2014-04-30 16:40 ` manu at gcc dot gnu.org
` (3 subsequent siblings)
25 siblings, 0 replies; 28+ messages in thread
From: alexfh at google dot com @ 2014-04-30 16:35 UTC (permalink / raw)
To: gcc-bugs
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:
...
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug c/7652] -Wswitch-break : Warn if a switch case falls through
[not found] <bug-7652-4@http.gcc.gnu.org/bugzilla/>
` (21 preceding siblings ...)
2014-04-30 16:35 ` alexfh at google dot com
@ 2014-04-30 16:40 ` manu at gcc dot gnu.org
2014-04-30 17:04 ` mw_triad at users dot sourceforge.net
` (2 subsequent siblings)
25 siblings, 0 replies; 28+ messages in thread
From: manu at gcc dot gnu.org @ 2014-04-30 16:40 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug c/7652] -Wswitch-break : Warn if a switch case falls through
[not found] <bug-7652-4@http.gcc.gnu.org/bugzilla/>
` (22 preceding siblings ...)
2014-04-30 16:40 ` manu at gcc dot gnu.org
@ 2014-04-30 17:04 ` mw_triad at users dot sourceforge.net
2014-04-30 17:20 ` michael.chapman at cortus dot com
2014-09-23 7:25 ` m.j.thayer at googlemail dot com
25 siblings, 0 replies; 28+ messages in thread
From: mw_triad at users dot sourceforge.net @ 2014-04-30 17:04 UTC (permalink / raw)
To: gcc-bugs
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...)
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug c/7652] -Wswitch-break : Warn if a switch case falls through
[not found] <bug-7652-4@http.gcc.gnu.org/bugzilla/>
` (23 preceding siblings ...)
2014-04-30 17:04 ` mw_triad at users dot sourceforge.net
@ 2014-04-30 17:20 ` michael.chapman at cortus dot com
2014-09-23 7:25 ` m.j.thayer at googlemail dot com
25 siblings, 0 replies; 28+ messages in thread
From: michael.chapman at cortus dot com @ 2014-04-30 17:20 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug c/7652] -Wswitch-break : Warn if a switch case falls through
[not found] <bug-7652-4@http.gcc.gnu.org/bugzilla/>
` (24 preceding siblings ...)
2014-04-30 17:20 ` michael.chapman at cortus dot com
@ 2014-09-23 7:25 ` m.j.thayer at googlemail dot com
25 siblings, 0 replies; 28+ messages in thread
From: m.j.thayer at googlemail dot com @ 2014-09-23 7:25 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 28+ messages in thread