__attribute__((always_inline)) fiasco

[Albert Cahalan <albert@users.sf.net>]

> I'm displeased with someone's workaround for decisions made by
> the (rather weak) inliner in gcc 3.[123].  In particular, that
> someone doesn't understand all of the implications of always_inline.
...
> In the Alpha port I have a number of places in which I have 
> functions that I would like inlined when they are called directly,
> but I also need to take their address so that they may be registered
> as part of a dispatch vector for the specific machine model.
>
> This scheme fails because my functions got marked always_inline
> behind my back, which means they didn't get emitted in the right
> place.

If it hurts, don't do that. It looks like bloat anyway.

Are benchmarks significantly affected if you remove the inline?
If so, simply have a second function:

extern void uninline_foo(void);
...
void uninline_foo(void)
{
        foo();
}

> Rather than fight the unwinnable fight to remove this hack entirely,
> may I ask that at least one of the different names for inline, e.g.
> __inline__, be left un-touched so that it can be used by those that
> understand what the keyword is supposed to mean?
>
> Of course, there does not exist a variant that isn't used by all
> sorts of random code, so presumably all existing occurences would
> have to get renamed to plan "inline" in order to keep people happy..

Hey, I argued for INLINE when the static/extern changes
came along. That's the sanest, because one never knows
what the next annoying compiler will demand. Then you
can have one of:

#define INLINE
#define INLINE inline
#define INLINE static inline  // an oxymoron
#define INLINE extern inline  // an oxymoron
#define INLINE __force_inline
#define INLINE __attribute__((always_inline))
#define INLINE _Pragma("inline")
#define INLINE __inline_or_die_you_foul_compiler
#define INLINE _Please inline