在GCC中使用-O3是否有任何弊端? [英] Are there any drawbacks to using -O3 in GCC?

问题描述

我已经用各种语言担任软件工程师13年了，尽管我现在正在进入C语言和后来的C ++语言.在学习C的同时，我正在使用GCC编译器来编译程序，并且我想知道是否有使用-O3或其他优化标志的陷阱.我的软件是否有可能以无法测试未经编译的代码无法捕获的方式崩溃，或者在交叉编译期间，我可能会无意间为其他平台弄乱了东西.

I've been a Software Engineer for 13 years in various languages, though I'm just now making my way into C and later C++. As I'm learning C, I'm using the GCC compiler to compile my programs, and I'm wondering if there are any gotchas to using -O3 or other optimization flags. Is there a chance that my software will break in ways that I won't be able to catch without testing the compiled code, or perhaps during cross-compilation, I might inadvertently mess something up for a different platform.

在我盲目地打开这些选项之前，我想知道我能期待什么.另外，随着-Ofast打开不符合标准的标志，我倾向于不使用它.我的假设是正确的，即-Ofast最有可能产生副作用"?

Before I blindly turn those options on, I'd like to know what I can expect. Also, as -Ofast turns on non-standards-compliant flags, I'm leaning towards not using that. Am I correct in my assumptions that -Ofast will most likely have "side-effects?"

我浏览了 https://gcc.gnu.org/onlinedocs/gcc/Optimize-在我发布此问题之前，先使用Options.html .

推荐答案

-O3 的唯一缺点应该是无法在调试器中遵循代码.

The only drawback of -O3 should be the inability to follow the code in a debugger.

使用 -Ofast 可能会影响您的某些浮点运算，从而导致舍入错误，但是除非您运行的是特别长的浮点计算链，否则您不太可能注意到.

The use of -Ofast can affect some of your floating point operations causing rounding errors, but unless you are running specifically long chains of floating point calculations you are unlikely to ever notice.

残破的代码(具有错误指针的代码或具有未定义行为的语句)在不同的优化级别上的行为可能会有所不同-许多程序员的第一个反应是将责任归咎于编译器-启用所有警告并修复它们通常会有所帮助.

Broken code (code with bad pointers or statements with undefined behavior) is likely to behave differently at different level of optimization -- the first reaction of many programmers is to blame the compiler -- enabling all warnings and fixing them usually helps.

这篇关于在GCC中使用-O3是否有任何弊端?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！