Static initialization order of variables in a single TU

[tchatow]

I left a question on stack overflow detailing the issue: https://stackoverflow.com/q/72286507/5336393, but no answers yet. I'm not sure whether it is a Clang bug or if there is no initialization order guarantee.

The example is:

#include <cstdio>

struct TestValue;

inline const TestValue* v_ptr = nullptr;

struct TestValue {
    static const TestValue v1;

    TestValue() {
        v_ptr = this;
        printf("TestValue Initialized at %p\n", this);
    }
};

struct CallTest {
    CallTest() {
        printf("CallTest Initalized at %p\n", this);
        printf("v_ptr = %p\n", v_ptr);
    }
};

const inline TestValue TestValue::v1{};
const inline CallTest ct{};


int main() {}

Surprisingly, ct is initialized before v1

Using Clang 14.0.3, but this issue goes back further. Is this a bug or are there no guarantees about the initialization order?

https://clang.godbolt.org/z/M9e757r46

[llvmbot]

@llvm/issue-subscribers-clang-codegen

[yuanfang-chen]

@zygoloid @rnk

Based on the discussion https://reviews.llvm.org/D126341/new/#3541259, presume the test case here is valid (which I think so), this is due to our using COMDAT for inline variables (and we can't rely on the order in llvm.global_ctors), right?

[rnk]

It's not clear to me if static data member is an inline variable which has the same ordering requirements from the standard, but essentially, yes, that's the issue.

[yuanfang-chen]

It's not clear to me if static data member is an inline variable which has the same ordering requirements from the standard, but essentially, yes, that's the issue.

Thanks for the confirmation. I'll take a look at this.

[zygoloid]

Based on the discussion https://reviews.llvm.org/D126341/new/#3541259, presume the test case here is valid (which I think so), this is due to our using COMDAT for inline variables (and we can't rely on the order in llvm.global_ctors), right?

I don't think the use of COMDATs is relevant here. That might cause similar problems in multi-translation-unit cases if the linker selects COMDATs inconsistently (but I don't think we know whether any real linkers do so). The entries in llvm.global_ctors are emitted in the wrong order, so even if LLVM preserves the order (which it seems to), we will perform initialization in the wrong order. I'm not sure why we're doing that; it looks to me like CodeGen should be emitting these initializers eagerly and in order.

Certainly switching away from using separate initialization functions and COMDATs for inline variables would solve this. I'm still optimistic that we can avoid doing so.

[zygoloid]

Certainly switching away from using separate initialization functions and COMDATs for inline variables would solve this. I'm still optimistic that we can avoid doing so.

If not, I think we should assign mangled names to the initialization functions for inline variables so we can at least deduplicate them across TUs, even if we're going to end up invoking them more than once each.

[yuanfang-chen]

Thanks for the suggestions. I've put up a fix here https://reviews.llvm.org/D127233.