thread_local成员变量的构造

Question

thread_local成员变量的构造

7

我遇到了一些关于thread_local的奇怪行为，不确定是我做错了什么还是GCC的bug。我有以下最小复现场景：

#include <iostream>

using namespace std;

struct bar {
    struct foo {
        foo () {
            cerr << "foo" << endl;
        }
        int i = 42;
    };

    static thread_local foo FOO;
};

static thread_local bar::foo FREE_FOO;
thread_local bar::foo bar::FOO;

int main() {
    bar b;
    cerr << "main" << endl;
    // cerr << FREE_FOO.i << endl;
    cerr << b.FOO.i << endl;
    return 0;
}

在上面的注释行之前，输出结果如下：

main
0

Ideone

取消注释后，它变成了这样：

main
foo
foo
42
42

Ideone

这里是不是有什么愚蠢的地方我没有注意到？

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.8.1-10ubuntu9' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.1 (Ubuntu/Linaro 4.8.1-10ubuntu9)

更新：

这也会产生意外的结果：

#include <iostream>

using namespace std;

template<class T>
struct bar {
    struct foo {
        foo () {
            cerr << "bar::foo" << endl;
        }
        int i = 42;
    };

    void baz() {
        cerr << bar::FOO.i << endl;
    }

    static thread_local foo FOO;
};

struct far {
    struct foo {
        foo () {
            cerr << "far::foo" << endl;
        }
        int i = 42;
    };

    void baz() {
        cerr << far::FOO.i << endl;
    }

    static thread_local foo FOO;
};

template<class T> thread_local typename bar<T>::foo bar<T>::FOO;
thread_local typename far::foo far::FOO;

int main() {
    cerr << "main" << endl;
    bar<int> b;
    b.baz();

    far f;
    f.baz();
    return 0;
}

结果：

main
0
far::foo
bar::foo
42

- Anomander Rake

为了增加混淆，将b.Foo替换为bar::FOO可以按预期工作： Ideone - Anomander Rake

1

请注意，static thread_local bar :: foo FREE_FOO; 中的 static 没有任何效果，因为您只是修改了链接（默认为内部）。删除它，您将获得相同的行为。 - Andy

一个模板类的成员，通过间接访问时仍然保持未初始化状态，而对于非模板类的成员，同样的访问会触发两个初始化过程。 - Anomander Rake

1

提交了一个错误报告：http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60702 - Anomander Rake

1

Clang由于一个错误而做错了事情，我现在已经修复了这个问题。当发出成员访问表达式的代码时，我们完全忽略了“初始化thread_local变量”的代码路径。 - Richard Smith

显示剩余3条评论

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- amdn · Accepted Answer

这段内容太长了，虽然我不敢说我完全理解它。

我有一个更短的版本，你可以在Coliru上运行。

#include <iostream>
using namespace std;

struct foo {
    int i;
    foo() : i{42} {}
};

struct bar {
    static thread_local foo FOO;
};

thread_local foo bar::FOO;

int main() {
    //cerr << string((bar::FOO.i == 42) ? "Ok" : "Bug") << endl; //Ok
    cerr << string((bar().FOO.i == 42) ? "Ok" : "Bug") << endl;  //Bug
}

我认为bug在这个gcc源文件中：https://chromium.googlesource.com/native_client/nacl-gcc/+/upstream/master/gcc/cp/decl2.c。此时，gcc正在尝试确定是否需要一个包装函数来检测静态成员变量bar中的FOO是否已被初始化...它决定不需要包装函数，这是错误的。它进行了以下检查：

它不是error_operand_p吗？是的，它不是。（我猜）
它是thread_local（DECL_THREAD_LOCAL_P）吗？是的，它是thread_local。
它不是gnu __thread扩展（DECL_GNU_TLS_P）吗？是的，它不是。
它不是在函数作用域中声明的（DECL_FUNCTION_SCOPE_P）吗？是的，它不是。
该变量没有在另一个翻译单元（TU）中定义吗？是的，它没有。（bug？）
它没有非平凡析构函数吗？是的，它没有。
它没有初始化程序或具有常量初始化程序吗？它有一个初始化程序，但它是常量。
它不需要包装函数。

缺陷可能是：

得出结论：如果初始化程序是常量，则它不是动态初始化，或者
未能正确执行静态初始化，或者
未能注意到即使它是成员变量也可以在外部定义。

由于初始化是由构造函数完成的，我认为这是混淆的源头，调用了构造函数，但值是常量。

以下是代码：

/* Returns true iff we can tell that VAR does not have a dynamic
   initializer.  */

static bool
var_defined_without_dynamic_init (tree var)
{
    /* If it's defined in another TU, we can't tell.  */
    if (DECL_EXTERNAL (var))
        return false;
    /* If it has a non-trivial destructor, registering the destructor
        counts as dynamic initialization.  */
    if (TYPE_HAS_NONTRIVIAL_DESTRUCTOR (TREE_TYPE (var)))
        return false;
    /* If it's in this TU, its initializer has been processed.  */
        gcc_assert (DECL_INITIALIZED_P (var));
    /* If it has no initializer or a constant one, it's not dynamic.  */
        return (!DECL_NONTRIVIALLY_INITIALIZED_P (var)
          || DECL_INITIALIZED_BY_CONSTANT_EXPRESSION_P (var));
}

/* Returns true iff VAR is a variable that needs uses to be
   wrapped for possible dynamic initialization.  */

static bool
var_needs_tls_wrapper (tree var)
{
    return (!error_operand_p (var)
          && DECL_THREAD_LOCAL_P (var)
          && !DECL_GNU_TLS_P (var)
          && !DECL_FUNCTION_SCOPE_P (var)
          && !var_defined_without_dynamic_init (var));
}