CVS g++ new warning [-Winline -Werror -O1]

Nathan Sidwell
Thu Mar 9 09:30:00 GMT 2000

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; 

> 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.

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.


Dr Nathan Sidwell   ::   ::   CodeSourcery LLC
         'But that's a lie.' - 'Yes it is. What's your point?' : :

More information about the Gcc-patches mailing list