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 8: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.
> 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).

I am not a big fan of adding another extension to GCC.  Especially one
where the documentation does not describe all the interactions with
templates or all of the C++ features.  Also Why can't we use some
preprocess tricks instead of adding this extension?

Andrew Pinski

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