`static` local variables : show the initialization checks

[Lectem]

When static is used in a function, initialization of the variable will only happen on the first time the block scoped is reached. Since c++11, this is even thread_safe.

I suggest transforming the following code:

struct StructWithCtor
{
    StructWithCtor() { }
};

void func()
{
    static StructWithCtor structWithCtorInstance;
}

to the following for C++11 onward

struct StructWithCtor
{
    StructWithCtor() { }
};

void func()
{
//  static local variable means we need to support thread-safe, one-time initialization . The compiler will generate code like the following:
//
//  if ( obj_guard.first_byte == 0 ) {
//      if ( __cxa_guard_acquire(&obj_guard) ) {
//        try {
//          ... initialize the object structWithCtorInstance ...;
//        } 
//        catch (...) {
//          __cxa_guard_abort(&obj_guard);
//          throw;
//        }
//        ... queue object destructor of structWithCtorInstance with __cxa_atexit() ...;
//        __cxa_guard_release(&obj_guard);
//      }
//   }
//
    static StructWithCtor structWithCtorInstance;
}

Note the comment is adapted from Apple Clang : www.opensource.apple.com/source/libcppabi/libcppabi-14/src/cxa_guard.cxx

I think in this case we can leave it as a comment, because we would otherwise need to add something like
alignas(alignof(StructWithCtor)) char func_structWithCtorInstance _storage[sizeof(StructWithCtor)]; in the global scope and pull in the <new> header for placement new and then have new (&func_structWithCtor_storage) StructWithCtor();.

[andreasfertig]

Hello @Lectem,

I'm so glad that someone is requesting that. Thanks also for the link. Just on Monday I gave a talk at CppOnSea in which I showed the internals of static but couldn't answer whether it uses double checking. This link helps to prove my point. As far as I remember it is true for gcc as well.

Now, to your proposal. I like the alignas because I got that wrong. However, try this modified example of yours. The difference is, that for trivial types it does not matter when they are initialized, as the user cannot tell (see) the difference. With a user provided destructor this changes and you get the additional code for the initialization. What's missing is the thread-safety. I will add that as well as the alignas and the link you posted as a comment in the source code. For now, I ignore the fact that it requires the new header. Please, feel free to provide a patch for that.

Andreas

[Lectem]

I'm so glad that someone is requesting that.

I'm happy to have reported this then, static initialization is something a lot of people don't know/realize !

Now, to your proposal. I like the alignas because I got that wrong.

That's a common mistake with placement new !
I think it is great you already have placement new generation, so what's left is mainly just handle multithreading/exceptions handling + add the alignas and <new>.
I suggested simply adding a comment because I wasn't sure if placement new was "common enough" that people would understand it, but since it's already there, all the better !

The difference is, that for trivial types it does not matter when they are initialized, as the user cannot tell (see) the difference
[...]
With a user provided destructor this changes and you get the additional code for the initialization.

But in the case above, my type is not trivially constructible since I have a user defined constructor, so it should display the additional code for initialization. (You are right to say that trivially_constructible AND trivially_destructible types won't trigger this).

Consider if this was used:

struct StructWithCtor
{
    StructWithCtor() { printf("Constructor called!"); }
};
void func() { static StructWithCtor structWithCtorInstance; }

Then the call to printf will be done only once, when we first call func.

In fact I just ran this through MSVC2019 and when you use Step into inside func you will reach the following functions (found in VC\Tools\MSVC\14.20.27305\crt\src\vcruntime\thread_safe_statics.cpp):

// Control access to the initialization expression.  Only one thread may leave
// this function before the variable has completed initialization, this thread
// will perform initialization.  All other threads are blocked until the
// initialization completes or fails due to an exception.
extern "C" void __cdecl _Init_thread_header(int* const pOnce) noexcept
{
    _Init_thread_lock();

    if (*pOnce == Uninitialized)
    {
        *pOnce = BeingInitialized;
    }
    else
    {
        while (*pOnce == BeingInitialized)
        {
            // Timeout can be replaced with an infinite wait when XP support is
            // removed or the XP-based condition variable is sophisticated enough
            // to guarantee all waiting threads will be woken when the variable is
            // signalled.
            _Init_thread_wait(XpTimeout);

            if (*pOnce == Uninitialized)
            {
                *pOnce = BeingInitialized;
                _Init_thread_unlock();
                return;
            }
        }
        _Init_thread_epoch = _Init_global_epoch;
    }

    _Init_thread_unlock();
}

and also after the constructor is called:

// Called by the thread that completes initialization of a variable.
// Increment the global and per thread counters, mark the variable as
// initialized, and release waiting threads.
extern "C" void __cdecl _Init_thread_footer(int* const pOnce) noexcept
{
    _Init_thread_lock();
    ++_Init_global_epoch;
    *pOnce = _Init_global_epoch;
    _Init_thread_epoch = _Init_global_epoch;
    _Init_thread_unlock();
    _Init_thread_notify();
}

So on MSVC those functions seem to replace __cxa_guard_acquire and __cxa_guard_release, and _Init_thread_abort replaces __cxa_guard_abort
This is confirmed here https://godbolt.org/z/lnUOfL
Also note that the compiler does not generate try/catch unless the constructor throws (or can throw) which is not the case in this example.

struct StructWithCtor
{
    StructWithCtor() { throw; }
};

Will trigger the full code generation with try-catch blocks. https://godbolt.org/z/ck2vgz

Note that

struct StructWithCtor
{
    ~StructWithCtor() {  }
};

Also triggers the initialization because it has to register the destructor if (and only if) the function block was reached. See https://godbolt.org/z/2VHGfZ

Please, feel free to provide a patch for that.

I can not guarantee I will find time for that (I didn't take a look at the codebase yet), but if I do I will ! It will probably be faster if you can do it or point me in the right direction though :)

[andreasfertig]

That’s great! Thank you for that research. I started the first draft yesterday. Just for future reference, the interesting part is here

While on that topic, I looked into the tests of clang and came across this. It looks there are more things protected, not just plain block scope static variables.

[Lectem]

It looks there are more things protected, not just plain block scope static variables.

Oh right, basically anything that can have a side effect. I think the only reason integers and other trivial types do not have the check is that with default initialization it falls under the "as-if rule" and the compilers are allowed optimize it away and do nothing.

[andreasfertig]

Hello @Lectem,

please have a look on what I just pushed. It is the best I can do so far. Feel free to reopen, in case you have additions or see bugs.

Andreas

[Lectem]

Hi!
(I'll be assuming this is already available on the website for my test, but I'm not sure if it's the case or not).

This looks good but I think the static storage and guard should be put to the global scope if possible.

There is also an issue with initializing integers with side effects like this:

int test()
{
  printf("test");
  return 42;
}
  
int main()
{
  static int t = test();
}

which should trigger the initialization checks.
I think that to solve all cases, we need to put the static storage and guard in the global scope, and always show the check even if it is an integer as this would remove any ambiguity.

Note that the following does not trigger the atomic checks only because it is considered already initialized when the application starts (this is a "as-if rule" optimization) and shows no side effect. So entering the static variable scope as no visible impact if it is initialized at application startup or the 1st time someone enters the scope.

int main()
{
  static int t = 0;
}

Edit: It seems I can not re-open this issue, should I open a new one or let you re-open it ?

[andreasfertig]

Hello @Lectem,

correct it is already life.

This looks good but I think the static storage and guard should be put to the global scope if possible.
I don't understand. Can you share an example and a reason?

There is also an issue with initializing integers with side effects like this:
True. As well as sometimes with exceptions. As far as I can see this all happens during code generation in Clang. A while after AST generation. Currently, I don't know a way to get the same result at the AST (front-end) stage. For that reason, I will not spend time on it in the near future. It already shows internals which are compiler dependent with the cxa_... stuff and the new header which is added. Feel free to submit a patch.

Andreas