GCC 3.3 warnings

[Jonathan Larmour]

Gary Thomas wrote:
> I'm experimenting with GCC-3.3.1.  For the most part, it's been pretty smooth,
> except for the raft of warnings that I get:

I'm using 3.3.2 right now.

>   /work2/ecos/packages/compat/posix/current/src/mqueue.cxx: In function `void do_mq_unlink(mqtabent*)':
>   /work/moab/t/install/include/cyg/kernel/mqueue.inl:255: warning: inlining  failed in call to `Cyg_Mqueue::~Cyg_Mqueue()'
> 
> Does anyone have any ideas how I might silence them?

There's many more than that, at least with 3.3.2. Much of the kernel build 
causes warnings. And they're particularly lengthy warnings too (more than 
you quoted). The simplest workaround is to remove -Winline.

A better solution is to make better judgements about what should and 
shouldn't be inlined. After all the point of the warning is that stuff 
isn't inlined which the code would otherwise indicate should be. Perhaps it 
really does meant it shouldn't be?

Admittedly some of this is compiler dependent, and can be tweaked - look at 
the doc on -finline-limit in invoke.texi. In fact an alternative workaround 
is to add maybe -finline-limit=$LARGENUMBER instead but I don't know if 
that's a good idea.

Certainly removing -Winline shouldn't be done hastily because it performs a 
useful service - there are some circumstances when it's important for us 
that a function is inlined, and we want to know if it isn't. -Winline 
originally went in because Hugo bashed his head against a problem for ages 
which turned out to be because something wasn't inlined, but -Winline would 
have told him. I think it was for the first one of these reasons:
"Some calls cannot be integrated for various reasons (in particular,
calls that precede the function's definition cannot be integrated, and
neither can recursive calls within the definition)."

If a function is too big to inline the compiler will generate an "out"line 
reference, and in some cases, this will result in duplicated code (I've 
never been sure when GCC does or doesn't use the .gnu.linkonce.t.* sections 
for this, but it doesn't seem consistent). "extern inline" would result in 
a better implementation, but requires code munging. Obviously in eCos we'd 
want to avoid potential wastage.

The example of mqueue is interesting... the reason all that stuff is 
inlined is because the POSIX functions that call it are mostly a veneer - 
we should avoid the overhead of a separate function call as it would be 
unnecessary - it's only a separate function (marked inline) for 
componentization and modularity, not any other reason.

It isn't the only example though - the many warnings in the memory pool 
stuff are the same principle, a simple function veneer calls a much larger 
inline function, e.g.:
cyg_uint8 *
Cyg_Mempool_Variable::alloc(cyg_int32 size)
{
     return mypool.alloc( size );
}

where mypool.alloc is declared inline, but won't be inlined due to its 
size... but not inlining saves us nothing, and in fact just adds an 
irrelevant function call overhead.

So I think overall I'm inclined to try increasing -finline-limit - that at 
least means that if something is inlined which shouldn't be, it's our fault 
and we can fix it, whereas removing -Winline will hide all sorts of stuff. 
I haven't yet played and found the values that work, maybe just doing 
-finline-limit=1000000 is okay but I'm undecided. Unless I'm mistaken, that 
also makes the behaviour more like previous GCC.

Unhelpfully -finline-limit is rejected by older GCC. It's accepted in GCC 
3.2.1 at least though (i.e. the version we have up for download). Since we 
don't have automagic detection of GCC versions I don't know if we should 
just insist on recent GCC or not - not everyone has a choice.

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
Visit us at Embedded World 2004, Nürnberg, Germany, 17-19 Feb, Stand 12-449
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine