我见过的大多数构建环境至少有两种策略：调试构建与最终/优化/发布构建。对于gcc，这通常意味着-g与-O的某些版本。现在，我看到一种情况，其中优化的构建是使用-O3构建的，而调试版本是使用-g3和-O3构建的。 man gcc确实表明这是可能的，但是出于实际调试的目的，这对我来说似乎违反直觉。
回顾http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html让我想起了-Og，它允许进行优化而不会干扰调试。这对我来说很有意义，但是使用-O3 -g3进行调试有什么令人信服的原因，除非您基本上是在尝试调试gcc自身的优化能力？
最佳答案
有时人们会编写错误的代码-例如，可能导致未定义行为的代码。现在让我们说，在优化程度较低或没有优化的情况下，未定义的行为似乎可以“正确”运行，但是在-O3处会造成灾难性的崩溃。您将要在-O3调试此问题，对吗？因此，即使调试经验可能会因优化而有所降低，但您别无选择，只能添加-g标志并开始使用。
通常，构建系统将“调试/发布”轴与“优化/未优化”轴合并在一起是一个大问题。实际上，它们应该是正交的-例如，通常需要通过日志记录来构建“调试”版本，但是在启用优化的情况下仍可以使其快速运行。同样，如果在优化的版本中没有可用的调试符号，可能很难跟踪与优化程序有关的错误。
+--------------------------------+
| Optimizations |
+-----------------+--------------+
| On | Off |
+----------+------+-----------------+--------------+
| | On | Debug optimized | Best debug |
| Debug | | code | experience |
| Logging/ +------+-----------------+--------------+
| Symbols | Off | Release build | Probably not |
| | | for customers | useful |
+----------+------+-----------------+--------------+