编译器优化安全吗？

Question

我最近在工作中发现，由于存在编译器错误的风险，不为硬实时嵌入式系统使用编译器优化的策略是（我们主要使用 gcc，但该策略也扩展到其他编译器）。显然，这项政策的开始是因为过去有人被优化器的错误烧毁了。我的直觉是这过于偏执，所以我已经开始寻找关于这个问题的数据，但问题是我找不到任何关于这个的硬数据。

有谁知道实际获取此类数据的方法？可以使用 gcc bugzilla 页面生成一些错误与编译器优化级别的统计信息吗？甚至有可能获得这样的无偏​​见数据吗？

Answer 1

我没有任何数据（也没有听说过有人这样做......）但是......

在选择禁用优化之前，我会选择要使用的编译器。换句话说，我不会使用任何我不能信任其优化的编译器。

Linux内核是用-Os编译的。对我来说，这比任何 bugzilla 分析都更有说服力。

就我个人而言，我可以接受 linux 可以接受的任何 gcc 版本。

作为另一个数据点，Apple 一直在从 gcc 转换为 llvm，无论有没有 clang。llvm 传统上在某些 C++ 方面存在问题，虽然 llvm-gcc 现在好多了，但 clang++ 似乎仍然存在问题。但这只是证明了这种模式：虽然 Apple（据称）现在使用 clang 编译 OS X 和 iOS，但他们并没有使用太多 C++ 和 Objective C++。所以对于纯 C 和 Objective C，我会信任 clang，但我仍然不信任 clang++。