Должен ли я беспокоиться о предупреждениях компилятора в Boost с помощью -O3?

Question

Я обнаружил, что многопоточная программа, созданная с помощью Boost, намного быстрее, когда я активирую флаг -O3. Тем не менее, это вызывает некоторые дополнительные предупреждения компилятора, все из которых говорят следующее:

warning: dereferencing type-punned pointer will break strict-aliasing rules 

Эти предупреждения все генерируется в файле Boost, shared_mutex.hpp. Чтобы быть конкретным, следующая функция вызывает эти предупреждения:

template<typename T> 
T interlocked_compare_exchange(T* target,T new_value,T comparand) 
{ 
    BOOST_STATIC_ASSERT(sizeof(T)==sizeof(long)); 
    long const res=BOOST_INTERLOCKED_COMPARE_EXCHANGE(reinterpret_cast<long*>(target), 
                 *reinterpret_cast<long*>(&new_value), 
                 *reinterpret_cast<long*>(&comparand)); 
    return *reinterpret_cast<T const*>(&res); 
} 

Глядя на this question, похоже, эти предупреждения означает, что код может привести к сбою, но кажется, что вряд ли идет из файла Boost. Теперь моя программа стала довольно сложной, и я видел ее (на редких и, казалось бы, случайных случаях) сбой при работе в течение длительных периодов времени. Возможно ли, что библиотека Boost вызывает это? Если это имеет значение, я использую mingw.

Answer 1

Да, вы должны беспокоиться о предупреждениях с строгим сглаживанием! Компилятор фактически сделает предположения, что нет псевдонима для объекта, который вызовет проблемы. Если ваш код (или код вы используете) не альясинг-чистым, вам необходимо отключить соответствующую опцию:

-fno-strict-aliasing 

Это довольно часто, что эта конкретная оптимизация явно запрещена, потому что много коды фактически нарушает строгое -литизация правил.

Answer 2

Этот сигнал уже был увеличен here, и предупреждение является законным. Если этот код встроен в вызывающую функцию, компилятору разрешено переопределять доступ через эти reinterpret_cast и через исходную переменную.

Это, как говорится, в конкретном фрагменте кода, который использует атомарные операции, поэтому расширение макроса BOOST_INTERLOCKED_COMPARE_EXCHANGE, вероятно, включает в себя защитные устройства для блокирования компилятора и процессора от переупорядочения инструкций ... так что это может быть хорошо.