>> Включаю -O3 в продакшене на корректно написанном коде, брат жив.
> Я очень рад за вас и вашего брата. Но таки вы -
> исключение. Стандартные флаги оптимизации в дистрибутивах (т.е. в 99% открытого софта)
> - O2.

Ну, это дело другое, и я бы на самом деле поспорил, что дело именно в ломающем код оптимизаторе. Впрочем, это оффтопик.

>> Есть у меня один знакомый, который как раз поэтому gcc и обожает,
>> что там код работает на 5-10% быстрее, чем в clang, как
>> правило.
> Про clang пока даже речи не было. Совершенно неизвестно, что тамошние бравые
> парни наворотили. Есть отдельные места - http://clang.llvm.org/doxygen/ToolChains_8cpp_source.html

Какой-то файл с костылями, честное слово.

> которые заставляют несколько усомниться в их квалификации.

Да, там тоже есть свои проблемы. Но, по опыту, для кода, написанного по стандартам, а не по gcc, clang лучше себя ведёт.

>> А вообще, за хорошим анализом кода при обычной компиляции и предупреждениями —
>> это к clang :)
> Он совершенно никакого сравнения с PVS-кой не выдерживает.

У меня совершенно обратный опыт. Гонял один товарищ PVS по кое-чему из моего кода, ни единого сообщения по делу. В основном ругается на 32 и прочие подобные константы, считая это хардкодом битности машины, в коде вроде

auto pixmap = icon.pixmap (32, 32);

Ну и местами предлагает T на const T& заменить, не всегда по делу. Итого, сложилось впечатление, что это какая-то мешанина на регекспах, а не статический анализатор кода на плюсах.

clang'овский static-analyzer же, в свою очередь, несколько действительно проблемных мест мне нашёл.