This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


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

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


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

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