конструкция переменной-члена thread_local

Я столкнулся с каким-то странным поведением с thread_local и не уверен, делаю ли я что-то не так или это ошибка GCC. У меня есть следующий минимальный сценарий воспроизведения:

#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

Идея

Я просто пропустил что-то глупое здесь?

$ 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

person Anomander Rake    schedule 28.03.2014    source источник
comment
Чтобы добавить путаницы, замена b.Foo на bar::FOO работает как положено: Ideone   -  person Anomander Rake    schedule 29.03.2014
comment
Обратите внимание, что static на static thread_local bar::foo FREE_FOO; не имеет никакого эффекта, поскольку вы просто изменяете связь там (которая по умолчанию является внутренней). Удалите его, и вы получите такое же поведение.   -  person Andy    schedule 29.03.2014
comment
Член класса-шаблона, к которому обращаются косвенно, также остается неинициализированным, в то время как тот же доступ к члену класса, не являющегося шаблоном, вызывает обе инициализации: Идея   -  person Anomander Rake    schedule 29.03.2014
comment
Энди: хороший улов! Таковы капризы безрассудного копирования и вставки.   -  person Anomander Rake    schedule 29.03.2014
comment
Отправлен отчет об ошибке: gcc.gnu.org/bugzilla/show_bug.cgi?id =60702   -  person Anomander Rake    schedule 29.03.2014
comment
Да, я думаю, это выход. Не мог понять это в clang или gcc 4.8.1. Удачи!   -  person Andy    schedule 29.03.2014
comment
Вот более короткий тестовый пример, демонстрирующий ошибку в clang coliru.stacked-crooked.com/a/959f4c60a9f90116< /а>   -  person amdn    schedule 29.03.2014
comment
Clang делал что-то не так из-за ошибки, которую я сейчас исправлено. Мы полностью пропустили кодовый путь «инициализировать переменную thread_local» при создании кода для выражения доступа к членам.   -  person Richard Smith    schedule 31.03.2014


Ответы (1)


Это слишком долго для комментария, хотя я не претендую на то, чтобы полностью его понять.

У меня есть более короткая версия, которую вы можете запустить в 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
}

Я думаю, что ошибка в этом исходном файле gcc

https://chromium.googlesource.com/native_client/nacl-gcc/+/upstream/master/gcc/cp/decl2.c

В этот момент gcc пытается решить, нужна ли FOO, которая является статическим членом bar, функция-оболочка, чтобы определить, была ли она инициализирована... она решает, что оболочка не нужна, что неверно. Он проверяет

  1. Разве это не error_operand_p ? Да, это не так. (Наверное)
  2. Это thread_local (DECL_THREAD_LOCAL_P)? Да, это thread_local.
  3. Разве это не расширение gnu __thread (DECL_GNU_TLS_P)? Да, это не так.
  4. Разве это не объявлено в области действия функции (DECL_FUNCTION_SCOPE_P)? Да, это не так.
  5. Переменная не определена в другой единице перевода (ЕП)? Да, это не так. (ошибка?)
  6. Разве у него нет нетривиального деструктора? Да, это не так.
  7. У него нет инициализатора или он константный? У него есть инициализатор, но он постоянный.
  8. Ему не нужна обертка

Недостаток либо:

  1. Заключение о том, что если инициализатор является постоянным, он не инициализируется динамически или
  2. Неспособность правильно выполнить статическую инициализацию или
  3. Не замечая, что даже если это переменная-член, она может быть определена извне.

Поскольку инициализация выполняется конструктором, я думаю, что это источник путаницы, вызывается конструктор, но значение является константой.

Вот код

/* 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));
}
person amdn    schedule 29.03.2014
comment
Было бы здорово, если бы вы добавили свои выводы в отчет об ошибке. Спасибо! - person Anomander Rake; 02.04.2014
comment
@AnomanderRake clang также не прошел тест, который вы создали, как и моя более короткая версия, я отправил это команде clang, и они обнаружили, что это дубликат ошибки, которую они недавно исправили, которая была связана с доступом к статическому потоку thread_local через указатель this . Я обновлю ваш отчет об ошибке, чтобы указать на исправленную ошибку clang... Я только заметил, что Ричард Смит оставил здесь комментарий на этот счет. - person amdn; 02.04.2014
comment
@AnomanderRake Я обновил ваш отчет об ошибке gcc, добавил более короткий тестовый пример и указал команде gcc на исправление clang, я думаю, что это более продуктивно, чем мои предположения. - person amdn; 03.04.2014
comment
Нельзя сказать, что в компиляторе нет ошибок, но обращаться к статическим членам через this — плохая практика. Это делает код менее самодокументируемым и подверженным ошибкам (если не для себя, то для тех, кому приходится работать с вашим кодом). - person rustyx; 17.08.2016
comment
кажется, ошибка все еще не исправлена, используя gcc 7.1 - person Tinro; 14.11.2017