我从各种来源(尽管主要来 self 的一位同事)听说，在 g++ 中使用 -O3 的优化级别进行编译在某种程度上是“危险的”，通常应该避免，除非证明是必要的。
这是真的吗？如果是，为什么？我应该坚持使用 -O2 吗？
最佳答案
在 gcc(2.8 等)的早期和 egcs 时代，redhat 2.96 -O3 有时会出现很多问题。但这是十多年前的事了，-O3 与其他级别的优化(在错误方面)没有太大区别。
然而，由于更严格地依赖语言的规则，尤其是极端情况，它确实倾向于揭示人们依赖未定义行为的情况。
作为个人说明，我多年来一直使用 -O3 在金融领域运行生产软件，并且还没有遇到如果我使用 -O2 就不会出现的错误。
根据大众需求，在此补充:
-O3 尤其是附加标志，如 -funroll-loops(-O3 未启用)有时会导致生成更多机器代码。在某些情况下(例如，在具有非常小的 L1 指令缓存的 CPU 上)，这可能会由于所有的代码而导致速度变慢。一些内部循环现在不再适合 L1I。通常 gcc 会努力不生成这么多代码，但由于它通常会优化通用案例，因此可能会发生这种情况。特别容易出现这种情况的选项(如循环展开)通常不包含在 -O3 中，并在手册页中相应地标记。因此，使用 -O3 生成快速代码通常是一个好主意，并且仅在适当时(例如，当分析器指示 L1I 未命中时)回退到 -O2 或 -Os(尝试优化代码大小)。
如果您想将优化发挥到极致，您可以通过 --param 在 gcc 中调整与某些优化相关的成本。另外请注意，gcc 现在能够将属性放在仅控制这些函数的优化设置的函数中，因此，当您发现 -O3 在一个函数中存在问题时(或只想为该函数尝试特殊标志)，你不需要用 O2 编译整个文件甚至整个项目。
otoh 似乎在使用 -Ofast 时必须小心，其中指出:
-Ofast enables all -O3 optimizations. It also enables optimizations that are not valid for all standard compliant programs.
这让我得出结论，-O3 旨在完全符合标准。
关于c++ - g++中的优化级别-O3危险吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/11546075/