构建调试目标时最好的 g++ 优化级别是什么? [英] What's the best g++ optimization level when building a debug target?

问题描述

当您想要构建可调试的东西(特别是 g++，但可能与 gcc 共享答案)时，最好的 -O 级别是什么?换句话说，在构建调试"目标而不是发布"目标时.

When you want to build something that's debuggable (g++ specifically, but perhaps shares an answer with gcc), what's the best -O level? In other words, when building a "debug" target rather than a "release" target.

gcc 在线文档在比较 -O0 和 -O1 时有点粗略(这里).我的解释是 -O1 只启用一种甚至可能影响可调试性的优化，即 -fomit-frame-pointer.但是引用文档，它仅在 -O1 中启用这样做不会干扰调试".我的解释正确吗?

The gcc online docs are a little sketchy when comparing -O0 and -O1 (here). My interpretation is that -O1 only enables one optimization that even may affect debugability, which is -fomit-frame-pointer. But to quote the doc, it's only enabled in -O1 "where doing so does not interfere with debugging." Am I interpreting that correctly?

本网站上的另一篇文章(这里)谈到 -特别是 O2，答案基本上是它可以工作，但你会出现乱序执行".根据事情的严重程度，IMO 的范围从烦人到毁灭性不等.

Another post on this site (here) talks about -O2 specifically, and the answer is basically "it works but you get out-of-order execution". Which, IMO, can range from annoying to devastating depending on how badly things jump around.

推荐答案

GCC 4.8 引入了一个新的优化级别:-Og 两全其美.

GCC 4.8 introduces a new optimization level: -Og for the best of both worlds.

-Og
优化调试体验.-Og 启用不干扰的优化调试.它应该是标准选择的优化级别编辑-编译-调试周期，提供合理的优化水平，同时保持快速编译和良好的调试体验.

-Og
Optimize debugging experience. -Og enables optimizations that do not interfere with debugging. It should be the optimization level of choice for the standard edit-compile-debug cycle, offering a reasonable level of optimization while maintaining fast compilation and a good debugging experience.

通过这种方式进行了一些优化，因此您可以获得更好的性能、更好的可能未初始化变量检测，并且您还可以在 GDB 中单步执行程序，而无需在函数中来回跳转.

This way some optimization is done so you get better performance, better possibly-uninitialized variable detection and you can also step through a program in GDB without jumping back-and-forth through the function.

这篇关于构建调试目标时最好的 g++ 优化级别是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！