public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* [RFC] missing return warnings
@ 2007-09-06  7:01 Jan Hubicka
  2007-09-06 10:03 ` Manuel López-Ibáñez
  2007-09-06 21:02 ` Mark Mitchell
  0 siblings, 2 replies; 7+ messages in thread
From: Jan Hubicka @ 2007-09-06  7:01 UTC (permalink / raw)
  To: gcc, mark

Hi,
I am looking into what parts of frontend stil depends on frontend inline
decision (ie DECL_INLINE now ignored by middle end).  All these uses
strike wrong, given that inlining decisions are independent on it.
These divergences for example requires us to enable expensive
-finline-functions for --profile-generate even though we really want it
only for --profile-use (where it is a lot cheaper given that profile
blocks unnecesary inlining).

For C++ there are number of cases I need to go through dealing with
attempts to not instantiate non-inline methods that won't be needed.
My plan is to make instantiation unconditional and measure effect on our
C++ benchmarks.
For C it seems to be single case for return warning:
/* PR c++/4872 */
/* { dg-do compile } */
/* { dg-options "-Wreturn-type" } */

static inline int f() {}     /* { dg-warning "return" "missing return" } */

In this case we produce missing return warning from frontend. 
This however is not truly consistent - if I make the function used, we
actually get two warnings - one from frontend, one from middle end
(that is CFG aware and does not merely check for presence of return
statement in  function).  If I remove the inline keyword, we lose the
warning since C frontend does not expect that we can now optimize out
static functions for a while.

The code in question is:

Index: c-decl.c
===================================================================
*** c-decl.c	(revision 128161)
--- c-decl.c	(working copy)
*************** finish_function (void)
*** 6752,6776 ****
  
    finish_fname_decls ();
  
-   /* Complain if there's just no return statement.  */
-   if (warn_return_type
-       && TREE_CODE (TREE_TYPE (TREE_TYPE (fndecl))) != VOID_TYPE
-       && !current_function_returns_value && !current_function_returns_null
-       /* Don't complain if we are no-return.  */
-       && !current_function_returns_abnormally
-       /* Don't warn for main().  */
-       && !MAIN_NAME_P (DECL_NAME (fndecl))
-       /* Or if they didn't actually specify a return type.  */
-       && !C_FUNCTION_IMPLICIT_INT (fndecl)
-       /* Normally, with -Wreturn-type, flow will complain.  Unless we're an
- 	 inline function, as we might never be compiled separately.  */
-       && DECL_INLINE (fndecl))
-     {
-       warning (OPT_Wreturn_type,
- 	       "no return statement in function returning non-void");
-       TREE_NO_WARNING (fndecl) = 1;
-     }
- 
    /* Store the end of the function, so that we get good line number
       info for the epilogue.  */
    cfun->function_end_locus = input_location;
--- 6725,6730 ----

I wonder what we want to do here - I guess we can either make the
warning unconditional and declare it as two indpendent things or we can
just drop the feature since user will get properly warned on every
function he actually uses.

What would be preferred solution here?

Similarly there is equivalent C++ frotned code.

Honza

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2007-09-07  1:06 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-09-06  7:01 [RFC] missing return warnings Jan Hubicka
2007-09-06 10:03 ` Manuel López-Ibáñez
2007-09-06 21:02 ` Mark Mitchell
2007-09-06 22:50   ` Jan Hubicka
2007-09-06 22:54     ` Mark Mitchell
2007-09-06 23:19       ` Jan Hubicka
2007-09-07  1:06         ` Mark Mitchell

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).