This is the mail archive of the 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]
Other format: [Raw text]

Re: [C++ PATCH] Implement new "force_static" attribute

On Mon, Jul 1, 2013 at 10:36 AM, David Malcolm <> wrote:
> My plan for removal of global variables in gcc 4.9 [1] calls for several
> hundred new classes, which will be singletons in a classic monolithic
> build, but have multiple instances in a shared-library build.
> In order to avoid the register pressure of passing a redundant "this"
> pointer around for the classic case, I've been looking at optimizing
> singletons.
> I'm attaching an optimization for this: a new "force_static" attribute
> for the C++ frontend, which when added to a class implicitly adds
> "static" to all members of said class.  This gives a way of avoiding a
> "this" pointer in the classic build (in stages 2 and 3, once the
> attribute is recognized), whilst supporting it in a shared-library
> build, with relatively little boilerplate, preprocessor hackery or
> syntactic differences.
> See:
> for more information on how this would be used in GCC itself.

Hi David,

I am still a little bit confused by this.  Help me out:
   1. if we don't need to pass `this', why should we ever find
       ourselves to writing functions that need one in the first place?
       How do shared libraries get into this water?

   2. regarding your comment about constexpr.  If you think that is useful
       you can add it to gnu++03 as __constexpr__ and use it, following
       the pattern suggested by RTH.

   3.  Is it that GCC does not know how to optimize objects of empty classes?

> With this optimization, the generated machine code *with classes* (with
> "methods" and "fields") is identical to that with just functions and
> global variables (apart from the ordering of the functions/"methods"
> within the .text sections of their respective .o files). [2]
> FWIW I've also been looking at another approach:
> which is even lower boilerplate, though I don't have that working yet;
> it touches the internals of classes and methods much more deeply.
> BTW, I'm not 100% sold on "force_static" as the name of the attribute;
> would "implicit_static" be a better name? (the latter is growing on me).
> Successfully bootstrapped on x86_64-unknown-linux-gnu; all old testcases
> have the same results as an unpatched build, and all new testcases pass
> (using r200562 as the baseline).
> Dave
> [1] See
> [2] I've written an "asmdiff" tool to help check this:

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