Possible incorrect code generation when using variable templates (again)

[jonas-eschmann]

Hello,

I'm encountering issues with Clang when initializing nested, templated structs again. A similar, now solved issue is filed here.

I was able to boil it down to this:

https://godbolt.org/z/jvPeYed1x

template <typename T>
struct A {
    T* a = nullptr;
};

template <typename T>
struct B {
    struct {
        A<T> aa;
    } b;
};


float d[] = {0.1337};
A<float> aa = {d};
B<float> b = {
    {aa},
};

template <typename T>
struct C {
    B<T> b;
};

template <typename T>
T factory = {b};

C<float> c = {b};

int main() {
    return factory<C<float>>.b.b.aa.a == nullptr ? 100 : 0;
    // return c.b.b.aa.a == nullptr ? 100 : 0;
}

I expect this to return 0.

This fails in Clang when using the factory. When instantiating C directly it works.

It fails in all Clang versions but works in GCC and MSVC.

Tagging the people involved in the previous issue because it seems very similar:
@shafik
@royjacobson
@erichkeane

[jonas-eschmann]

Actually Claude managed to boil it down even further:
https://godbolt.org/z/PWEzoK7Gs

struct A {
    float* a = nullptr;
};

struct B {
    A aa;
};

float d[] = {0.1337};
A aa = {d};
B b = {aa};

template <typename T>
T factory = {b};

int main() {
    return factory<B>.aa.a == nullptr ? 100 : 0;
}

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: Jonas Eschmann (jonas-eschmann)

Hello,

I'm encountering issues with Clang when initializing nested, templated structs again. A similar, now solved issue is filed here.

I was able to boil it down to this:

https://godbolt.org/z/jvPeYed1x

template <typename T>
struct A {
    T* a = nullptr;
};

template <typename T>
struct B {
    struct {
        A<T> aa;
    } b;
};


float d[] = {0.1337};
A<float> aa = {d};
B<float> b = {
    {aa},
};

template <typename T>
struct C {
    B<T> b;
};

template <typename T>
T factory = {b};

C<float> c = {b};

int main() {
    return factory<C<float>>.b.b.aa.a == nullptr ? 100 : 0;
    // return c.b.b.aa.a == nullptr ? 100 : 0;
}

I expect this to return 0.

This fails in Clang when using the factory. When instantiating C directly it works.

It fails in all Clang versions but works in GCC and MSVC.

Tagging the people involved in the previous issue because it seems very similar:
@shafik
@royjacobson
@erichkeane

[keinflue]

Replying to the reduced test case:

The dynamic initialization of the instantiation of a variable template is unordered with any other dynamic initialization of any global variable.

There is no guarantee that factory<B> will be initialized before b is, which also has dynamic initialization.

So Clang is conforming. Both 100and 0 are valid outcomes.

The problem seems to be similar in the original test case.

[erichkeane]

I took the minimization and ran it here with AST/IR: https://godbolt.org/z/hE67fcGre

LOoks like this is a global ctor-ordering thing. See:

https://en.cppreference.com/w/cpp/language/initialization.html#Non-local_variables

Particularly under dynamic initialization. I THINK this ends up being UB. @shafik can you confirm?

[jonas-eschmann]

Thank you a lot @keinflue and @erichkeane, that is very interesting!

So the solution is to make everything that goes into variable templates const then, to make them part of the static initialization phase and hence make the initialization of the variable template factory in the "Unordered dynamic initialization" phase well-defined behavior?

https://godbolt.org/z/nsqW4qGYj

struct A {
    const float* a = nullptr;
};

struct B {
    A aa;
};

const float d[] = {0.1337};
const A aa = {d};
const B b = {aa};

template <typename T>
T factory = {b};

int main() {
    return factory<B>.aa.a == nullptr ? 100 : 0;
}

[keinflue]

So the solution is to make everything that goes into variable templates const then, to make them part of the static initialization phase

No, the const doesn't actually change anything. You need constexpr or at least constinit for that (the latter only verifies, doesn't actually change anything about initialization kind).

If you only use constinit here on aa though, it will not succeed, because you need constexpr to make the variable usable in constant expressions for the initialization of b, so that it will be constant initialized, as you can verify by giving it constinit.

I.e. the fix is to mark aa as constexpr and maybe constinit on b to verify the fix.

Also be careful that adding const or constexpr without inline/extern will cause the variables to have internal linkage, while the variable template will still have external linkage (even with const), i.e. you are likely to violate ODR if you do this in a header.

[shafik]

I am pretty sure this is #61028 and this one which was dupped is closer to this: #38719