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
