This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: CVS g++ new warning [-Winline -Werror -O1]
- To: Mark Mitchell <mark at codesourcery dot com>
- Subject: Re: CVS g++ new warning [-Winline -Werror -O1]
- From: Nathan Sidwell <nathan at codesourcery dot com>
- Date: Thu, 09 Mar 2000 17:27:01 +0000
- CC: bkoz at cygnus dot com, gcc-patches at gcc dot gnu dot org
- Organization: CodeSourcery, LLC
- References: <200003090613.WAA01502@haight.constant.com> <20000308224448P.mitchell@codesourcery.com> <38C7D42D.168B7C3F@codesourcery.com> <20000309090006A.mitchell@codesourcery.com>
Mark Mitchell wrote:
> I'm not sure your patch is correct. Aren't the static variables
> that are created as flags for initializing local statics going to be
> marked as DECL_ARTIFICIAL? Or do they end up outside the function?
This needs more investigation -- I'd forgotten about such initializing
vars. However, I suspect that it's safe in that such an artificial
var cannot _cause_ a function to be non-inlinable -- the static var it's
protecting will have done that. But of course we must get the linkage
correct for the initializer var.
> I'm not sure I understand your other comments. It would seem to me
> that maybe_commonize_var should be run before inlining;
Yup.
> how does inlining have an impact here?
maybe_commonixe_var is a nop for non-inline functions. For inline ones
it can mark them as non-inlinable. _But_ that information is squirreled
away and only printed if/when the function is emitted as a non-inline
function. The tree inliner _appears_ to ignore this flag.
AFAICT
1) An unused local static var with a trivial ctor/dtor can be optimized
away (unfortunately non-trivial ctors and dtors can have side effects the
programmer can rely on). __FUNCTION__ etc are now such vars (which we _must_
optimize out).
2) Platforms supporting common linkage can emit a needed static var
defn and still inline the function.
3) Certain platforms don't have common linkage. If an external
function has a static var, it cannot be inlined.
2 & 3 are currently determined at the point of the var's definition,
before we know whether the var is used. Both can cause the function-
cannot-be-inlined flag, even though for (2) it can be, and we don't know
about (1). This is the failure Ben has tripped over.
> static inline void f () { static int i; }
>
> Here, `i' doesn't get commonized, because `f' has internal linkage.
> Then:
>
> static void g() { f(): }
>
> I don't think we want `i' to get commonized in `g', right?
I need to examine the mechanics of the tree inliner carefully, to
comment further.
> I think
> there's already machinery that makes us ignore statics when inlining
> -- either at the inlining stage or at the RTL creation stage.
I think part of this commonize_var code might now be obsolete, given
the tree inliner.
> Am I being dense again?
Not this time! Probably my turn :)
I'm unlikely to be able to look at this carefully until the weekend.
nathan
--
Dr Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery LLC
'But that's a lie.' - 'Yes it is. What's your point?'
nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org