我最近在工作中发现，由于存在编译器错误的风险，不为硬实时嵌入式系统使用编译器优化是一项政策(我们主要使用 gcc，但该政策也扩展到其他编译器)。显然，这项政策的开始是因为过去有人被优化器的错误烧毁了。我的直觉是这过于偏执，所以我已经开始寻找关于这个问题的数据，但问题是我找不到任何关于这个的硬数据。
有谁知道实际获取此类数据的方法？可以使用 gcc bugzilla 页面生成一些错误与编译器优化级别的统计信息吗？甚至有可能获得这样的无偏见数据吗？
最佳答案
我没有任何数据(也没有听说过任何人这样做......)但是......
在我选择禁用优化之前，我会选择我将使用的编译器。换句话说，我不会使用任何我不相信优化的编译器。
linux内核是用-Os编译的。这比任何 bugzilla 分析都更有说服力。
就个人而言，我对任何版本的 gcc linux 都可以。
作为另一个数据点，Apple 一直在从 gcc 转换为 llvm，有和没有 clang。 llvm 传统上在某些 C++ 方面存在问题，虽然 llvm-gcc 现在好多了，但 clang++ 似乎仍然存在问题。但这只是证明了这种模式:虽然 Apple(据称)现在使用 clang 编译 OS X 和 iOS，但它们并没有使用太多 C++ 和 Objective C++。所以对于纯 C 和 Objective C，我会信任 clang，但我仍然不信任 clang++。
关于compiler-construction - 编译器优化安全吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/9059265/