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

["manu at gcc dot gnu.org" <gcc-bugzilla@gcc.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?