>> Есть баланс между толерантностью к ошибкам и качеством оптимизации. Включаешь оптимизатор — будь готов к тому, что кривой код он не простит.
> Ну так -O3 уже никто и не включает. Или пацаны хотят добиться,
> что и -O2 включать не будут?Включаю -O3 в продакшене на корректно написанном коде, брат жив.
> Баланс, разумеется есть, но gcc регулярно шагает за баланс в сторону оптимизации.
Есть у меня один знакомый, который как раз поэтому gcc и обожает, что там код работает на 5-10% быстрее, чем в clang, как правило.
> Нижеприведённый код qsort в стандарт был введён в 1999 году, а
> на C писали и до этого года. Т.е. оптимизация ярковыраженно ломает
> нормальный код, написанный 20 лет назад.
-std=c90 или подобное никто не запрещает передавать. Если при этом gcc откуда-то возьмёт требование к ненулёвости соответствующего аргумента qsort — вот тогда это проблема и баг в gcc. А если авторы пишут на C до 99 года, а передают ключи, соответствующие более свежему стандарту — ну, чо, ССЗБ.
> Причём, как это обычно у gccшников, без объявления войны. Хотя бы предупреждения
> о выбрасывании кода можно было выкинуть. Ну, типа unreachable code.
Unreachable code в этом случае выкидывать — это либо прокидывать какой коллбек из optimization pass в морду, что, вполне возможно, с текущей архитектурой gcc фиг сделаешь, либо делать полноценный статический анализ на этапе разбора кода, а это на времени компиляции скажется не очень позитивно.
Да и вообще, на этапе оптимизации, как правило, довольно много кода может выкидываться, передвигаться, и так далее. На всё это ворнингами плеваться — их столько появится, что никто эту простыню читать не будет.
А вообще, за хорошим анализом кода при обычной компиляции и предупреждениями — это к clang :)
