This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

auto-detected pure functions are ``inlined'' in spire of noinline

Aren't you surprised that, when you compile code like this:

void foo() __attribute__((__noinline__));
void f() { foo(); }
void foo() {}

the code output for f() does not call foo()?

Haven't you ever spent some time staring at the function inlining code
just to find out that it wasn't inlining, after all, but rather the
fact that foo() was auto-detected pure, and so the call was replaced
with mere evaluation of its arguments, i.e., nothing at all?

Well, it happened to me twice.  Serious.  Please stop laughing at me

First time, a few months ago, I was convinced the behavior was

Now I'm no longer sure, and thought of two ways to address the problem:

(i) adjust the docs of attribute noinline so as to mention this case,
such that it is not surprising to those who learn about noinline in
the docs and then don't understand why it's not working, or

(ii) arrange for attribute noinline to disable the code that
auto-detects the purity/constness of functions.

I have implemented and tested both changes, but I can't decide which
one I like the best.  Please review and choose one of them to approve
(even if with changes).  Thanks,

Index: gcc/ChangeLog
from  Alexandre Oliva  <>

	* doc/extend.texi (Function Attributes noinline): Document
	apparent inlining of functions detected as pure/const and how to
	prevent it.

Index: gcc/doc/extend.texi
RCS file: /cvs/gcc/gcc/gcc/doc/extend.texi,v
retrieving revision 1.172
diff -u -p -r1.172 extend.texi
--- gcc/doc/extend.texi 5 Dec 2003 08:09:33 -0000 1.172
+++ gcc/doc/extend.texi 6 Dec 2003 01:08:19 -0000
@@ -2051,7 +2051,11 @@ volatile voidfn fatal;
 @cindex @code{noinline} function attribute
 @item noinline
 This function attribute prevents a function from being considered for
+inlining.  Note that, when a function has an empty body and returns
+void, the compiler will decide it is @code{pure} and optimize away
+calls to it, giving the impression that the function was inlined.
+Side effects must be added to the otherwise-empty function to prevent
+this behavior, for example, a do-nothing @code{asm("");} statement.
 @cindex @code{always_inline} function attribute
 @item always_inline
Index: gcc/ChangeLog
from  Alexandre Oliva  <>

	* alias.c (mark_constant_function): Don't consider noinline
	functions as pure/const.

Index: gcc/alias.c
RCS file: /cvs/gcc/gcc/gcc/alias.c,v
retrieving revision 1.203
diff -u -p -r1.203 alias.c
--- gcc/alias.c 2 Oct 2003 17:43:57 -0000 1.203
+++ gcc/alias.c 6 Dec 2003 01:10:15 -0000
@@ -2600,7 +2600,13 @@ mark_constant_function (void)
       || DECL_IS_PURE (current_function_decl)
       || TREE_THIS_VOLATILE (current_function_decl)
       || current_function_has_nonlocal_goto
-      || !(*targetm.binds_local_p) (current_function_decl))
+      || !(*targetm.binds_local_p) (current_function_decl)
+      /* We don't want to consider functions marked as noinline as
+	 PURE or CONST, otherwise we might optimize away calls to
+	 them, giving the impression that they were inlined, which is
+	 very confusing.  */
+      || lookup_attribute ("noinline",
+			   DECL_ATTRIBUTES (current_function_decl)))
   /* A loop might not return which counts as a side effect.  */
Alexandre Oliva   Enjoy Guarana', see
Red Hat GCC Developer                 aoliva@{,}
CS PhD student at IC-Unicamp        oliva@{,}
Free Software Evangelist                Professional serial bug killer

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]