Безопасные CFLAGS

Настройка CFLAGS — часть широких возможностей настройки и управления, которыми отличается работа с Gentoo. У всевластия есть свои плюсы и минусы. Не искючение и настройка CFLAGS.

Предупреждение: Использование чего-либо, за исключением -O2 -fomit-frame-pointer -march/-mcpu/-mtune в CFLAGS или CXXFLAGS (а также -mieee, -mabi и т.д. на тех архитектурах, где об этом прямо сказано), и тем более чего бы то ни было в LDFLAGS или ASFLAGS для большинства пользователей не оправдает затраченных усилий. Обычно выгода невелика, если есть вообще, риск неоправдан, а за гигантское время, потраченное на изматывающую настройку, можно было бы с удовольствием сделать массу более интересного.

Недавнее обновление до GCC 4.1 для пользователей стабильных веток x86 и amd64 изменило влияние CFLAGS. Пользователи, подгонявшие свои CFLAGS в GCC 3.4, могут столкнуться с нестабильностью своей системы после обновления до GCC 4.1.

Вот примеры этого:

* nss_ldap прекращает работать с -ffast-math (-ffast-math часто используется не по назначению; его следует считать опасным флагом)
* -fvisibility-inlines-hidden все еще приводит к сбоям в коде
* -ftree-loop-linear в GCC 4.1 нарушает код (по крайней мере, в mesa)
* -ftree-vectorize, как известно, в GCC 4.1 приводит к сбоям (по крайней мере, на x86 и ppc; пользователи amd64 жаловались реже, но никаких гарантий нет)
* -fforce-addr и -fweb на x86 регулярно нарушают код в видеобиблиотеках или в приложениях для обработки графики, которые оптимизированны с помощью ручных ассеблерных вставок (-fweb может быть безопасным на amd64, но, как и выше, никаких гарантий нет)

Вот флаги, заведомо нарушающие код на всех версиях GCC, наличие которых также рекомендуется проверить:

* -fvisibility=hidden
* -frename-registers (может быть безопасным на amd64, на ваш страх и риск)
* -ftracer
* -D_FILE_OFFSET_BITS=64
* -msse, -mmmx, and -m3dnow (не нужны на amd64, они группируются в -march=k8/nocona/... и благополучно используются)
* -W
* -mfpmath=sse,387
* -malign-double

Пользователям с неподдерживаемыми флагами в CFLAGS есть смысл вернуться к безопасным CFLAGS (см. предупреждения выше), если после обновлений часто возникают проблемы со стабильностью системы. С другой стороны, искателям приключений, возможно, захочется поэкспериментировать с CLFAGS, которые не работали корректно с GCC 3.4.6... Как всегда, все в руках прользователя (даже ружье, которое он направил себе в ногу).

Последние замечания:

* Страница руководства GCC содержит предупреждения о некоторых небезопасных параметрах оптимизации. Вы должны внимательно прочитать его перед тем, как начать эксперименты с CFLAGS или начать обновление GCC на системе Gentoo с измененным набором CFLAGS.
* В некоторых файлах ebuild параметры, небезопасные на общесистемном уровне, могут добавляться автоматически (местным переопределением CFLAGS или при помощи функции append-flags класса flag-o-matic), если разработчик счел их безопасными. Например, в сборочные файлы xmame/xmess на большинстве архитектур добавлен параметр -ffast-math, который вам не следует добавлять в свои CFLAGS.
* Вы можете вникнуть в проблемы стабильности, связанных с конкретным параметром оптимизации, запустив find /usr/portage -name '*.ebuild' | xargs grep -- '-вар-рискованный-параметр-оптимизации'. Поищите 'filter-flags': это займет довольно много времени, но может привести к озарению.

http://www.gentoo.org/news/ru/gwn/20061009-newsletter.xml