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

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

///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() я соврал - у меня было больше потоков, чем я думал - корректно работает.

Anatoly MoskovskySiemarglНу не так - он должен выругаться об неоднозначности, а не линковать что первое попало.
Не должен.
Как раз по дизайну он должен брать первое из нескольких имен в порядке указания их библиотек.Где кстати прописано поведение линкера ?
Ты как спец по стандартам, можешь знать )

Илья, я категорически против правки моих постов, даже с благой целью улучшения этого убогого сайта. Ок ?

Что то у меня не получается воспроизвести, хотя точно был какой то казус

Воспроизводится для С, но не CPP.

Причем msvc2003 и gcc работают в этом случае одинаково.

Век живи, век учись (

Вот. Как раз повторно наткнулся на грабли 2)

Претензии:
1)Полный бордель внутри каталога gcc
-include лежат в gcc\include,
но
для С++ есть своя версия, лежит gcc\lib\gcc\mingw32\4.9.2\include\c++

-ar.exe, as.exe и еще пяток хранятся в двух копиях в разных подкаталогах

-lib частично лежат в gcc\lib,
но
немного в gcc\mingw32\4.9.2

2)ИЧСХ, обычно компилятор сам знает, где искать свое барахло, но иногда....
Ну не хочет он, ****, при сборке dll видеть -lgcc, ни сам, ни если ему под нос положить.
Решил: Помогает только положить под нос и сказать ld ... libgcc.a

3)Статическая сборка как минимум под Windows потребует замену gcc libc,
Но динамическую же сборку - могу записать в плюс: сборку с-программ с msvcrt.dll без лишних зависимостей вообще, а С++ рантайм пару мегабайт и без геморроя с манифестами и версиями.

4)Одна и так же версия компилятора, с одинаковым makefile порождает библиотеки разного размера, если компилить под Win и под Lin.
Страшно брать и линковать с разных мест сборки, но вроде работает.

dbpatchSiemargl1)Полный бордель внутри каталога gcc
И? Кто тебе виноват, что ты используешь кривую и неродную систему, с оберточным костылем?
Пересаживайся на Linux, где gcc мейснтрим, там будет тебе феншуй по полнойНесмотря на то, что я в 96% случаев пользуюсь MingGW, вполне в состоянии посмотреть и в "родной" системе (под рукой Ubuntu14):
include находим в /usr/include, но
часть лежит в /usr/lib/gcc/x86_64-linux-gnu/4.8/include
бинарники лежат в /usr/bin, но
cc1 и cc1plus лежит в /usr/lib/gcc/x86_64-linux-gnu/4.8/

Практически такой же бардак (только либы (.a) вместе лежат, что впрочем (2) лечит)
dbpatchSiemargl3)Статическая сборка как минимум под Windows потребует
Ну что за детский сад, штаны на лямках!

Под Windows есть clang/C2 в составе MS VS 2015, если так уж сильно хочется последних C++ ништяков.

Какой смысл сидеть и колоться об реально никем не поддерживаемую платформу?Ага, Clang под Windows только вышел, никем не используется (а еще он в CBuilder10 есть).
И уровень поддержки там отличается от gcc. /sarcasm

Кроме того, я часто пользуюсь кросс-компилятором, где выбора у меня просто нет.
dbpatchSiemargl4)Одна и так же версия компилятора, с одинаковым makefile порождает библиотеки разного размера, если компилить под Win и под Lin.
Страшно брать и линковать с разных мест сборки, но вроде работает.

Вообще жесть. Ты поди и про отличия в ABI еще не почитал нигде?
https://en.wikipedia.org/wiki/X86_calling_conventions#x86-64_calling_conventions

Ах ну да, про XMM регистры было зачтено за бред, я забыл :):)ABI тут ни при чем, целевой таргет одинаковый, как и версии компилятора.

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

dbpatch,

Читать ты не умеешь, по делу сказать тоже не можешь. Так что отвечать тебе смысла не вижу.

Кстати, не уточнил.

Весь этот файловый бардак обычно не заметен.

Пока не нужно использовать -nostdlib, который используется в основном при кросс-компиляции.

Следующее чудо - не gcc, но друг его GNU make. Перестал собираться элементарный пример.

Возможно, сменилась версия make c 3.82 на 3.82.90, но не факт, что это причина

Перестало подхватываться правило (а работало раньше)


Причем, в make есть builtin правила - и оно подхватывает CFLAGS, но не INCLUDES, так что выглядело очень похоже на верную строку.
<tab> имеется

Пилять, рядом такой же файл обрабатывается.

В общем, если

то правило обнаруживается и работает.
А если
то не работает =)

Еще можно убрать вообще зависимость от SOURCES в неявном правиле.