По просьбам зрителей, да и что то у меня накопилось.

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

///1
Пример первый - есть структурка - в которой перемешаны int16_t и int32_t, компилятор 32-битный. Структурка передается параметром чужим функциям и соответственно, чувствительна к выравниванию.
Так вот, структурка до 98 байт - не выравнивается, т.е ее размер соответствует сумме мемберов. А вот на 98байте компилятору ну просто очень нужно выровнять на оффсет 4.
Я конечно понимаю, что он ничего не должен, но ожидаю предсказуемого поведения в сходных случаях.

///2
Окай, я такой значит уже умный - вставляю __attribute__ ((__packed__)) и вроде счастлив. Авотмуй!
///2.1
Во первых, есть такой баг, мало того что плавающий (не всегда проявляется), а еще и мигрирующий между версиями.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52991
Т.е даже пример из документации https://gcc.gnu.org/onlinedocs/gcc/Common-Type-Attributes.html#Common-Type-Attributes
может просто не работать!

///2.2
Целая песня, если у вас вложенные структуры, юнионы и смесь. Не надо думать, что вы написали __attribute__ ((__packed__)), и всё - с несанкционированными выравниваниями покончено. Работа этого аттрибута вполне зависит от погоды, наличия имени структуры, наличия typedef и положения аттрибута относительно порядка имя-аттрибут.

///3
Отдельная тема - качество и понятность генерируемого ассемблера, а за компанию и работа гнусного дизассемблера, которые не попадает в адреса относительно кода.

///4
Который раз твердили миру, -О3 не работает уже 10 лет. Если ваша программа крашится, нужно откатиться на -О2, а лучше и не пробовать. Последний раз - мы тут на форуме гоняли рейтрейсинг, живой пример.

///5
Из мелких придирок - отвратительно медленный старт под Windows всего гнусного тулчейна, жручесть памяти и скорость работы компилятора.

Сходу всё не вспоминается, потом продолжу.

Как я уже написал, невыровненные структурки нужны для обмена по чужому ABI.

Еще пару вещей вспомнил

- Red zone. Коснется вас если только вы используете ассемблер (ну или ловите баги порчи стека) - укуренное использование. Т.е ваш стековый массив может краешком лежать в редзоне. Временные переменные, даже не ваши временные, а которые потребовались при оптимизации - тоже. Почему не размещаться с начала по порядку - хз. Возможно используется по порядку с конца.

- С99 в исполнении gcc обязывает вас все inine функции переписать как static inline, иначе будет ошибка линковки. Static inline это навязано стандартом, но реализация могла бы и упростить.... Я теперь знаю про extern inline, но в любом случае это жутко неудобно и несовместимо.

Пётр Седов,

А)Подтверждаю, это еще одна "фича" gcc - ld - просто берется первая функция с нужным именем по порядку объектников в командной строке линкера, остальные не проверяются.

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

Раньше вроде MS-линкер обнаруживал дублирование и ругался, может дело в классах.


Б) Сразу добавлю в темку - после смены версии вырос размер исполняемого файла. Для обычного helloworld для проверки - в 6 раз.
Посмотрел в .map - ОМГ сколько мусора, и фиг разберешься что зачем.

Справедливости ради, то если разберешься, то можно ручками сделать скрипт линкера с отбрасыванием чего тебе ненужного, вроде размотки стека исключений для .c программ (я еще не разобрался)

+1 assert'ы не удаляются в релизной сборке без явно указанного NDEBUG

+2 std::thread
в сборке i686-6.2.0-win32-sjlj-rt_v5-rev1 отсутствует
а в сборке i686-6.2.0-posix-dwarf-rt_v5-rev1 работает через жо - thread.join() не гарантирует ожидания конца, как обязана

В архитектуре x32 не использует AVX, хотя ему явно сказано
>-m32 -O2 -march=core-avx2 -mtune=core-avx2

Похоже, что работа ведется только для x86-64

SiemarglВ архитектуре x32 не использует AVX, хотя ему явно сказано
>-m32 -O2 -march=core-avx2 -mtune=core-avx2

Похоже, что работа ведется только для x86-64
Не совсем так. Просто надо ручками дополнительно писать -mfpmath=sse

Basil A. SidorovSiemargl+1 assert'ы не удаляются в релизной сборке без явно указанного NDEBUGНе очень, правда, понятно почему вас это удивляет и почему макрос препроцессора должен зависеть от типа сборки???Да, и вправду, похоже меня IDE разбаловали, которые сами добавляют.
MasterZivSiemarglПётр Седов,

А)Подтверждаю, это еще одна "фича" gcc - ld - просто берется первая функция с нужным именем по порядку объектников в командной строке линкера, остальные не проверяются.
Так любой линкер так и должен работать!
То, что ты нарушаешь ODR -- это ТВОИ проблемы!Ну не так - он должен выругаться об неоднозначности, а не линковать что первое попало.
dbpatch..бред про ХММ убран...
...а тут ты передаешь over 98 байт, и спрашивается в задаче, кто ССЗБ ? Будь как все, передавай указатель на свою копию в стеке, конечный эффект будет такой-же.Я и передаю по указателю. Какая разница, если выравнивание навернуто.

Так так, похоже про thread.join() я соврал - у меня было больше потоков, чем я думал - корректно работает.