This is the mail archive of the ecos-devel@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GCC 3.3 warnings


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]