Могут ли разные уровни оптимизации привести к функционально другому коду?

Ответ 1

Часть применяемого стандарта С++ является § 1.9 "Исполнение программы". В нем, в частности, говорится:

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

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

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

Итак, да, код может вести себя по-разному на разных уровнях оптимизации, но (при условии, что все уровни создают соответствующий компилятор), но они не могут вести себя по-разному.

EDIT: Позвольте мне исправить мой вывод: Да, код может вести себя по-разному на разных уровнях оптимизации, если каждое поведение, как правило, идентично одному из вариантов поведения стандартной абстрактной машины.

Ответ 2

Можно ли написать код, который ведет себя по-разному, в зависимости от того, уровень оптимизации был скомпилирован с?

Только если вы вызываете ошибку компилятора.

ИЗМЕНИТЬ

Этот пример ведет себя по-разному на gcc 4.5.2:

void foo(int i) {
  foo(i+1);
}

main() {
  foo(0);
}

Скомпилированный с помощью -O0 создает сбой программы с ошибкой сегментации.
Скомпилированный с помощью -O2 создает программу, вступающую в бесконечный цикл.

Ответ 3

Расчеты с плавающей точкой являются зрелым источником различий. В зависимости от того, как упорядочиваются отдельные операции, вы можете получить больше/меньше ошибок округления.

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

И как вы уже упоминали, побочные эффекты в конструкторах копий могут исчезнуть при изменении уровней оптимизации.

Ответ 4

Хорошо, моя вопиющая игра за щедрость, предоставив конкретный пример. Я соберу кусочки из ответов других людей и моих комментариев.

В целях различного поведения на разных уровнях оптимизации "уровень оптимизации A" должен обозначать gcc -O0 (я использую версию 4.3.4, но это не имеет большого значения, я думаю, что любая даже смутно недавняя версия будет показать разницу, которую я получаю после этого), а "уровень оптимизации B" означает gcc -O0 -fno-elide-constructors.

Код прост:

#include <iostream>

struct Foo {
    ~Foo() { std::cout << "~Foo\n"; }
};

int main() {
    Foo f = Foo();
}

Выход на уровне оптимизации A:

~Foo

Выход на уровне оптимизации B:

~Foo
~Foo

Код полностью легален, но результат зависит от реализации из-за исключения конструктора экземпляра и, в частности, он чувствителен к флагом оптимизации gcc, который отключает копирование ctor elision.

Обратите внимание, что в целом "оптимизация" относится к преобразованиям компилятора, которые могут изменять поведение undefined, неопределенное или определенное реализацией, но не поведение, определенное стандартом. Таким образом, любой пример, который удовлетворяет вашим критериям, обязательно является программой, выход которой либо не определен, либо определен в соответствии с реализацией. В этом случае он не определен стандартом, если исключить копирование ctors, мне просто повезло, что GCC надежно удаляет их почти везде, когда это разрешено, но имеет возможность отключить это.

Ответ 5

Для C почти все операции строго определены в абстрактной машине, и оптимизация разрешена только в том случае, если наблюдаемый результат соответствует именно этой абстрактной машине. Исключения из этого правила, которые приходят на ум:

• undefined поведение не должно быть совместимый между различными компиляторами выполнение или выполнение неисправного кода Операции с плавающей запятой могут выполняться
• различное округление
• аргументы для вызовов функций могут быть оценивается в любом порядке
• выражения с volatile квалифицированными тип может быть или не быть оценен просто для их побочных эффектов
• идентичные const квалифицированные составные литералы могут или не могут быть свернуты в одну статическую ячейку памяти

Ответ 6

Все, что есть Undefined Поведение в соответствии со стандартом может изменить его поведение в зависимости от уровня оптимизации (или фазы луны, если на то пошло).

Ответ 7

Параметр -fstrict-aliasing может легко вызывать изменения в поведении, если у вас есть два указателя на один и тот же блок памяти. Это должно быть недействительным, но на самом деле довольно распространено.

Ответ 8

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

Ответ 9

Эта программа C вызывает поведение undefined, но отображает разные результаты на разных уровнях оптимизации:

#include <stdio.h>
/*
$ for i in 0 1 2 3 4 
    do echo -n "$i: " && gcc -O$i x.c && ./a.out 
  done
0: 5
1: 5
2: 5
3: -1
4: -1
*/

void f(int a) {
  int b;
  printf("%d\n", (int)(&a-&b));
}
int main() {
 f(0);
 return 0;
}

Ответ 10

Есть интересный пример в моем курсе OS сегодня. Мы проанализировали некоторые программные мьютексы, которые могут быть повреждены при оптимизации, потому что компилятор не знает о параллельном выполнении.

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