Strict aliasing — когда/где и у кого шалит оптимизатор?

Question

[Marvel_K]

Привет.

Гуглил (habr, доклады, stackoverflow), но в силу строгого и не совсем однозначного изложения непонятно как/где оно может поломаться, и каким образом это предотвратить/исправить. Вроде понял, что в MSVC этой проблемы нету (не считая перекрывающихся областей под личное обязательство разработчика на пару с restrict).. у GCC, вроде, ключи есть, которые "гарантируют/не гарантируют".. Интересует в контексте C99 (но тут стандарт скромничает).

к примеру, всегда делал так:

PBYTE pByte = memory_alloc( ... );

struct header {
    DWORD data_1;
    DWORD data_2;
    BYTE data_other[];
} *s = (struct header *)pByte;

..но теперь сомневаюсь - не учудит ли оптимизатор, при сборке в GCC? Или "char*" туда/сюда можно безболезненно каст'ить?

В голове каша. Кто понимает, проясните пожалуйста доступным языком эту тему =\

UPD: хм, это можно охарактеризовать как "каламбур типизации", инфа под GCC - https://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Optim...

UPD2: в общем, отправная точка этот доклад https://habrahabr.ru/post/306294/ , и можно медитировать до полного понимания

Answer 1

[Marvel_K]

Исходя из доклада протестировал такой пример (clang 5.0.1, MSVC 2015, GCC 6), билды 32 и 64:

float invert(float f)
{
    unsigned int *i = (unsigned int *)&f;

    *i ^= 1 << 31;

    return *(float *)i;
}

...

printf("%.2f\n", invert_sign(-3.14f));

никаких UB не обнаружил - взаимодействия с FPU правильные при разных уровнях оптимизации, а также конкретно в GCC с опцией -strict-aliasing, т.е. новые версии компиляторов багом (конкретно на этом примере (?) ) из серии strict aliasing - не грешат.

Answer 2

[res2001]

Можно кастить. Все нормально будет.
При присваивании непосредственно со значение адреса ничего не происходит. Тип указателя компилятору нужен только для адресной арифметики.
В плюсах могут быть варианты, а тут как угодно можно преобразовывать адреса.