[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