Compiled with MinGW port of g++, compiles without errors or warnings: g++ bug.cpp -o bug.exe Minimal sample bug.cpp: #include <iostream> using namespace std; class Example { protected: int m_x; public: Example() { m_x = 0; } Example( const Example &ref ) { m_x = ref.m_x; } ~Example() { } int get() { return m_x; } void set( int x ) { m_x = x; } Example &operator =( Example ref ) { m_x = ref.m_x; return *this; } }; Example func( Example p ) { Example m; m.set( p.get() ); // ! COMPILER DOES NOT DETECT ABSENCE OF FUNCTION RETURN ! } int main() { Example m; m.set( 7 ); Example k; k = func( m ); // ! CONSEQUENTLY RESULT IS RANDOM ! cout << k.get() << endl; return 0; }
(In reply to comment #0) > Compiled with MinGW port of g++, compiles without errors or warnings: It does warn if you ask it to: -Wall
(In reply to comment #1) > (In reply to comment #0) > > Compiled with MinGW port of g++, compiles without errors or warnings: > > It does warn if you ask it to: -Wall I can understand that this is ok behavior for C, but to have to EXPLICITLY ASK typesafe language like C++ to inform me if function WITH RETURN TYPE does not return anything ? If this is not bug why shouldn't we make int n; n =; printf("%d",n); to be legal code, compiler should simply assign whatever it wants. Right ? Could anyone explain what for should missing return on typical C++ function be useful at all ? Not to mention probability that it has been forgotten by mistake. -Wreturn-type should be set by default.
(In reply to comment #2) > If this is not bug why shouldn't we make > > int n; > n =; > printf("%d",n); > > to be legal code, compiler should simply assign whatever it wants. Right ? No, because that's not even legal syntax, so that's a completely different case. > -Wreturn-type should be set by default. OK, so let's change the report to say that then. In general though, please don't report bugs claiming there are no warnings if you haven't even tried -Wall, there's a notice when you report a bug asking you to check that. Reduced example: struct A { int i; }; A f() { A a = { 0 }; // missing return } int main() { A a = f(); return a.i; }
Let's do this then.
Sorry, not me, not now: hundreds of testcases need fixing.
Patch proposed here: http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01781.html
Author: jason Date: Thu Jan 23 18:54:08 2014 New Revision: 207001 URL: http://gcc.gnu.org/viewcvs?rev=207001&root=gcc&view=rev Log: PR c++/55189 * cp-tree.h (struct language_function): Add infinite_loop and infinite_loops. (current_function_infinite_loop): New. * semantics.c (begin_maybe_infinite_loop, end_maybe_infinite_loop) (break_maybe_infinite_loop): New. (finish_while_stmt_cond, finish_while_stmt, begin_do_stmt) (finish_do_stmt, finish_for_cond, finish_for_stmt) (begin_range_for_stmt): Use them. * decl.c (finish_function): Don't warn about missing return if current_function_infinite_loop. * pt.c (instantiate_decl): Copy current_function_infinite_loop. * parser.c (cp_parser_jump_statement): Call break_maybe_infinite_loop. Added: trunk/gcc/testsuite/g++.dg/warn/Wreturn-type-9.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl.c trunk/gcc/cp/parser.c trunk/gcc/cp/pt.c trunk/gcc/cp/semantics.c
The patches to fix this bug are available here: https://github.com/sylvestre/gcc I am doing the legal FSF papers to be able to apply it.
(In reply to Sylvestre Ledru from comment #8) > The patches to fix this bug are available here: > https://github.com/sylvestre/gcc > I am doing the legal FSF papers to be able to apply it. Cool! Hopefully it goes quickly. After that, I would suggest that you submit the patch to gcc-patches and CC Jason Merrill and Dodji Seketeli, either of them should be able to approve this. I noticed that your patch does not update doc/invoke.texi to reflect the fact that -Wreturn-type is enabled by default instead of by -Wall (it would be great to automatically generate some parts of the manual from the options description). I also noticed that you did not include -Wmissing-return in your patch as discussed here: http://gcc.gnu.org/ml/gcc/2013-11/msg00288.html (Perhaps you did, and I am using github incorrectly?) I think you will get easier approval if you include it (or send two patches in the same email) and point out to the previous discussion (in particular Dodji, Joseph and Jason's approval of this idea).
(In reply to Manuel López-Ibáñez from comment #9) > > Cool! Hopefully it goes quickly. After that, I would suggest that you submit > the patch to gcc-patches and CC Jason Merrill and Dodji Seketeli, either of > them should be able to approve this. Sure. Thanks for the suggestion. > I noticed that your patch does not update doc/invoke.texi to reflect the > fact that -Wreturn-type is enabled by default instead of by -Wall (it would > be great to automatically generate some parts of the manual from the options > description). I will have a look! > I also noticed that you did not include -Wmissing-return in your patch as > discussed here: http://gcc.gnu.org/ml/gcc/2013-11/msg00288.html > > (Perhaps you did, and I am using github incorrectly?) I did... removed it :) I've followed Jason suggestion here: http://gcc.gnu.org/ml/gcc-patches/2014-01/msg01033.html The problem that we were trying to address with -Wmissing-return has been fixed (AFAIK) by the commit description in comment #7 > I think you will get easier approval if you include it (or send two patches > in the same email) and point out to the previous discussion (in particular > Dodji, Joseph and Jason's approval of this idea). Sure. Thanks for the advice.
cc-ing Martin Liska because I think he fixed this recently
I take it, I have fixed test-suite fallout. Hopefully this time the patch will land to trunk.
Fixed on trunk, there will be no backport.