UB

[thedeemon]

Слева - результат компенсации движения здорового человека. Справа - результат компенсации движения курильщика.



Не, на самом деле слева - результат компенсации движения, полученный при компиляции программы интеловским компилятором (в Release) или MSVC в режиме Debug, а справа - результат на тех же данных той же программы, собранной MSVC в Release. Глюк исчезает, и результат становится в точности как слева, если в исходнике убрать одно единственное слово. Угадаете, какое?

Comments

бинго!

[thedeemon.livejournal.com]

Баг только в MSVC/Release, в дебаг варианте оба компилятора делают код без глюков.

Совершенно верно, это был __restrict! Небольшой массив float'ов на стеке, который в одном месте использовался как массив float'ов, а рядом - как массив F32vec4 через указатель, на который по ошибке был навешен модификатор __restrict. Нарушение обещания не алиасить вызывает UB, который в данном случае привел к мусору в результирующем буфере.

Re: бинго!

[mejedi.livejournal.com]

Кстати на gcc и clang __m128 определяется примерно так, что в моем понимании позволяет легально кастовать указатели на сабж в указатели на флоат и обратно.

typedef float __m128 __attribute__ ((vector_size (16)));

Вобще самобытное восприятие типов в MSVC доставляет. Я как-то обнаружил, что MSVC считает, что int64_t из stdint.h это не то же самое, что long long int (размер совпадает).

Re: бинго!

[qehgt.livejournal.com]

Значит, типы и правда разные. char/signed char/unsigned char - это три разных типа, к примеру. "long int"/"long long int" тоже всегда будут разные, даже если размер их одинаков.

Re: бинго!

[mejedi.livejournal.com]

Угу. Но это делает типы с фиксированным размером из stdint.h бесполезными, когда приходится работать с кодом, который описывает те же самые типы по своему (legacy или по другим причинам).