在G ++中，优化级别-O3是否危险？
我从各种各样的消息来源（虽然大部分是我的一位同事）听说的，-O3以g ++的优化级别进行编译在某种程度上是“危险的”，除非被证明是必要的，否则通常应该避免编译。
这是真的吗？如果是这样，为什么？我应该坚持-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现在可以将属性放在仅控制这些功能的优化设置的功能上，因此，当您发现一个功能中的-O3有问题（或想尝试该功能的特殊标志）时，您无需使用O2编译整个文件甚至整个项目。
在使用-Ofast时，似乎必须小心，它指出：
-Ofast启用所有-O3优化。它还启用了并非对所有符合标准的程序都有效的优化。
这使我得出结论，-O3旨在完全符合标准。
-
我从不同的渠道（尽管主要是从我的一个同事那里）听说，在G++中使用的优化级别进行编译是“危险的”，除非证明是必要的，否则通常应该避免。 这是真的吗？如果是，为什么？我应该坚持吗？
-
在任何人告诉我查找旧答案或RTFM之前，请注意我已经这样做了，所以请在指示我查找其他地方之前阅读详细信息。 我已经确定，优化级别的差异并不像为更高的优化级别启用了一些不同类型的优化标志那么简单。 例如，我首先通过以下步骤发现了O0和O1的优化标志的差异： 这给了我一个O1对O0启用的各种优化标志的列表。 然后，我用-O0编译了代码，但是添加了O1对O0启用的所有单独的优化标志，因为结果应该和O1一
-
在具有管道和转发功能的MIPS体系结构上： add指令将在步骤3（执行操作）准备好结果，但我假设sw指令希望在步骤2（指令解码）得到结果 David A. Patterson的《计算机组织与设计》一书中有一个已解决的练习：在以下代码段中找到危险并重新排序指令以避免任何管道停滞： 解决方案： 在解决方案中，它正确识别加载使用危险并相应地重新排列代码，但是否也存在执行存储危险？
-
例子 $ gcc -Q --help=optimizers The following options control optimizations: -O<number> -Ofast -Os -falig
-
我有log4j2.xml，它部分配置为： 但是，跟踪消息并不存在于两个文件附加符（fileinfo/filedebug）中。当我更改FileDebug log level=“TRACE”时，就会出现跟踪消息。
-
问题内容： 在Linux实时进程优先级范围为1到99的情况下，我不清楚哪个是最高优先级，即1或99。 “了解Linux内核”（O’Reilly）的7.2.2节说1是最高优先级，考虑到正常进程的静态优先级从100到139，其中100是最高优先级，这是有道理的： “每个实时过程都与一个实时优先级相关联，该优先级的值范围是1（最高优先级）到99（最低优先级）。” 另一方面，sched_setschedu