[Bug c++/51680] g++ 4.7 fails to inline trivial template stuff

["miles at gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51680

--- Comment #6 from miles at gnu dot org 2011-12-28 01:04:05 UTC ---
Well, it's just an impression ... :]

I think one reason is that unlike normal functions, template functions are
implicitly sort of "local" (by necessity), in that they can have a definition
in many compilation units without causing a link conflict.  To get this effect
for normal functions, one must use the "static" or "inline" keywords -- so the
impression (rightly or wrongly) is that template functions definitions are like
one of those.

... and of course if a [normal] function definition has "static" or "inline"
attached, gcc does do inlining differently.  As I mentioned in my original
report, gcc 4.6, seems to treat template functions this way w/r/t inlining, as
if they were static.[*]

On another note, I'd kinda expect gcc these days to be making pretty reasonable
decisions about inlining even without hints; that's why I'm surprised at
behavior of my example, where the functions involved are so trivial that
inlining seems almost always a good bet...

[*] For instance, here's a "normal function" version of my example:   extern
void process (float);

   void process_fun_at (float (&fun)(float), float x)
   {
     process (fun (x));
   }

   static float add1 (float x)
   {
     return x + 1;
   }

   void test (float i)
   {
     process_fun_at (add1, i);
   }

gcc 4.6 will compile this differently if "process_fun_at" is declared "static";
if it's static, everything gets inlined, otherwise, nothing is inlined.  gcc
4.6 completely inlines the original template example with no special
declaration for the "process_fun_at" template function, meaning it's being
treated kind of like it's static for inlining purposes.

gcc 4.7 compiles the normal-function example the same as gcc 4.6 for both
static and non-static cases, but _doesn't_ inline the template version by
default.  So if nothing else, this is a change in behavior from gcc 4.6;
whether it's good or bad I dunno.

[and yeah, I know inlining heuristics are a big ball of hair that nobody wants
to mess with if they can help it.... sorry.... :]

Thanks,

-miles