[cfe-dev] always_inline and noinline attributes

Mike Stump mrs at apple.com
Tue Jul 22 18:03:53 PDT 2008


On Jul 22, 2008, at 5:38 PM, Devang Patel wrote:
> On Jul 22, 2008, at 5:10 PM, Eli Friedman wrote:
>> Oh... okay, thanks for clarifying.  That said, it seems sort of  
>> silly.
>> If the function can't be removed, doesn't always_inline just force
>> the compiler to bloat the code?
>>
>> Is there some attribute that would enforce throwing away the
>> definition?  If not, would it be useful to add one?  Or is
>> always_inline along with static generally good enough?
>
> I *think* using "static" is the only option. Note, this is a gcc
> extension.

I have a different take.  gcc allows one to do:

static int foo(int) __attribute__ ((always_inline));

inline int foo(int i) { return i + 1; }

volatile void *vp = foo;

int main() {
   return foo(0);
}

because they allow this, they have to emit the always_inline  
function.  This goes against common sense, so, I'd argue this is a bug  
that should be fixed, and when fixed, there can't be any references to  
the always_inline function. If you want one in the file, you have to  
have one without always_inline, pedantically, this is even probably  
wrong (ODR).

While I don't mind being slavishly compatible with gcc/g++, I do think  
we should draw the line at bug for bug compatibility.  If there is a  
question as to wether this is a bug or feature, certainly a gcc bug  
report should be able to answer that.



More information about the cfe-dev mailing list