This is the mail archive of the
ecos-devel@sources.redhat.com
mailing list for the eCos project.
Re: GCC 3.3 warnings
- From: Jonathan Larmour <jifl at eCosCentric dot com>
- To: Gary Thomas <gary at mlbassoc dot com>
- Cc: eCos development <ecos-devel at ecos dot sourceware dot org>
- Date: Wed, 18 Feb 2004 06:48:42 +0000
- Subject: Re: GCC 3.3 warnings
- References: <1077063171.17692.339.camel@hermes>
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