编译器优化会引入错误吗？

Question

今天我和一个朋友讨论了“编译器优化”的问题，我们争论了几个小时。

我捍卫了这样的观点：有时，编译器优化可能会引入错误或至少引入不良行为。

我的朋友完全不同意，他说“编译器是由聪明人构建的，做聪明的事情”，因此，永远不会出错。

他根本没有说服我，但我不得不承认我缺乏现实生活中的例子来加强我的观点。

谁在这里？如果是的话，您是否有任何现实生活中的例子，其中编译器优化在生成的软件中产生了错误？如果我错了，我应该停止编程并学习钓鱼吗？

Answer 1

编译器优化可能会引入错误或不良行为。这就是为什么您可以将它们关闭。

一个例子：编译器可以优化对内存位置的读/写访问，执行诸如消除重复读取或重复写入或重新排序某些操作之类的操作。如果所讨论的内存位置仅由单个线程使用并且实际上是内存，则可能没问题。但如果内存位置是硬件设备 IO 寄存器，那么重新排序或消除写入可能是完全错误的。在这种情况下，您通常必须编写代码，并知道编译器可能会“优化”它，从而知道这种简单的方法行不通。

更新：正如 Adam Robinson 在评论中指出的那样，我上面描述的场景更多的是编程错误，而不是优化器错误。但我试图说明的一点是，某些原本正确的程序与一些本来可以正常工作的优化相结合，当它们组合在一起时可能会在程序中引入错误。在某些情况下，语言规范说“您必须这样做，因为可能会发生此类优化并且您的程序将会失败”，在这种情况下，这是代码中的错误。但有时编译器具有（通常是可选的）优化功能，可能会生成不正确的代码，因为编译器过于努力地优化代码或无法检测到优化是否不合适。在这种情况下，程序员必须知道何时可以安全地打开相关优化。

另一个例子：
Linux 内核有一个错误，在测试该指针为空之前，可能会取消引用该指针。然而，在某些情况下，可以将内存映射到地址零，从而允许取消引用成功。编译器在注意到指针被取消引用后，假设它不能为 NULL，然后删除稍后的 NULL 测试以及该分支中的所有代码。 这在代码中引入了安全漏洞，因为该函数将继续使用包含攻击者提供的数据的无效指针。对于指针合法为空并且内存未映射到地址零的情况，内核仍然会像以前一样发生 OOPS。因此，在优化之前，代码包含一个错误；之后它包含两个，其中一个允许本地 root 漏洞利用。

CERT 有一个演示文稿，名为“危险的优化和Robert C. Seacord 的《因果关系损失》列出了许多在程序中引入（或暴露）错误的优化。它讨论了各种可能的优化，从“做硬件所做的事情”到“​​捕获所有可能的未定义行为”到“做任何不被禁止的事情”。

一些代码示例在积极优化的编译器掌握之前完全正常：

• 检查溢出

  // 由于溢出测试被删除而失败
  if (ptr + len < ptr || ptr + len > max) 返回 EINVAL;
  

• 完全使用溢出算术：

  // 编译器将其优化为无限循环
  对于 (i = 1; i > 0; i += i) ++j;
  

• 清除敏感信息的内存：

  //编译器可以删除这些“无用的写入”
  memset(password_buffer, 0, sizeof(password_buffer));
  

这里的问题是，几十年来，编译器在优化方面不太积极，因此一代又一代的 C 程序员学习并理解诸如固定大小的二进制补码加法之类的东西以及如何它溢出了。然后编译器开发人员修改了C语言标准，尽管硬件没有改变，但微妙的规则发生了变化。 C 语言规范是开发人员和编译器之间的合同，但协议的条款可能会随着时间的推移而发生变化，并不是每个人都理解每个细节，或者都认为这些细节是明智的。

这就是为什么大多数编译器提供标志来关闭（或打开）优化。您编写的程序是否考虑到整数可能会溢出？那么您应该关闭溢出优化，因为它们可能会引入错误。您的程序是否严格避免别名指针？然后，您可以打开假设指针永远不会出现别名的优化。您的程序是否尝试清除内存以避免泄漏信息？哦，在这种情况下你就不走运了：你要么需要关闭死代码删除，要么你需要提前知道你的编译器将消除你的“死”代码，并使用一些工作- 围绕它。

Answer 2

当错误通过禁用优化而消失时，大多数时候它仍然是你的错

我负责一个商业应用程序，主要用 C++ 编写 - 从 VC5 开始，早期移植到 VC6，现在成功移植到VC2008。在过去 10 年里，它增长到了超过 100 万行。

那时我可以确认启用积极优化时发生的单个代码生成错误。

那么我为什么要抱怨呢？因为同时出现了几十个bug让我对编译器产生了怀疑——但事实证明是我对C++标准的理解不够。该标准为编译器可能使用或不使用的优化留出了空间。

多年来，在不同的论坛上，我看到许多帖子指责编译器，最终证明是原始代码中的错误。毫无疑问，其中许多隐藏的错误需要详细了解标准中使用的概念，但仍然是源代码错误。

为什么我回复这么晚：在确认这实际上是编译器的错误之前，请停止指责编译器。

Answer 3

编译器（和运行时）优化肯定会引入不期望的行为 - 但它至少应该只有在您依赖于未指定的行为（或者确实对良好做出错误的假设）时才会发生 -指定的行为）。

除此之外，编译器当然也可能存在错误。其中一些可能与优化有关，其影响可能非常微妙 - 事实上它们很可能，因为明显的错误更有可能得到修复。

假设您将 JIT 作为编译器，我已经在 .NET JIT 和 Hotspot JVM 的发布版本中看到了错误（不幸的是，目前我没有详细信息），这些错误在特别奇怪的情况下是可重现的。我不知道它们是否是由于特定的优化所致。

Answer 4

结合其他帖子：

1. 编译器的代码中偶尔会出现错误，就像大多数软件一样。 “聪明人”的说法与此完全无关，因为美国宇航局卫星和其他由聪明人构建的应用程序也存在错误。进行优化的代码与不进行优化的代码是不同的，因此，如果错误恰好出现在优化器中，那么您的优化代码确实可能包含错误，而未优化的代码则不会。

   编译器

2. 正如 Shiny 和 New 先生所指出的那样，对于并​​发和/或计时问题不了解的代码有可能在没有优化的情况下令人满意地运行，但在优化时会失败，因为这可能会改变执行的计时。你可以将这样的问题归咎于源代码，但如果它只在优化时才会出现，有些人可能会归咎于优化。

Answer 5

仅举一个例子：几天前，有人发现 gcc 4.5 具有以下选项-foptimize-sibling-calls（由 -O2 暗示）生成一个在启动时出现段错误的 Emacs 可执行文件。

此后显然已修复。

Answer 6

我从未听说过或使用过其指令无法改变程序行为的编译器。一般来说，这是一件好事，但它确实需要您阅读手册。

我最近遇到了一个编译器指令“删除”了一个错误的情况。当然，这个错误确实仍然存在，但我有一个临时的解决方法，直到我正确修复程序为止。

Answer 7

是的。一个很好的例子是双重检查锁定模式。在 C++ 中，无法安全地实现双重检查锁定，因为编译器可以以在单线程系统中有意义但在多线程系统中无效的方式重新排序指令。完整的讨论可以在 http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf< /a>

Answer 8

有可能吗？不在主要产品中，但它肯定是可能的。编译器优化生成代码；无论代码来自何处（您编写它或由某些东西生成它），它都可能包含错误。

Answer 9

我在使用较新的编译器构建旧代码时遇到过几次这种情况。旧代码可以工作，但在某些情况下依赖于未定义的行为，例如不正确定义/强制转换运算符重载。它可以在 VS2003 或 VS2005 调试版本中工作，但在发布中会崩溃。

打开生成的程序集，很明显编译器刚刚删除了相关函数 80% 的功能。重写代码以不使用未定义的行为将其清除。

更明显的例子：VS2008 vs GCC

声明：

Function foo( const type & tp ); 

调用：

foo( foo2() );

其中 foo2() 返回类 type 的对象；

在 GCC 中往往会崩溃，因为在这种情况下对象没有在堆栈上分配，但 VS 做了一些优化来解决这个问题，并且它可能会起作用。

Answer 10

别名可能会导致某些优化出现问题，这就是编译器可以选择禁用这些优化的原因。来自维基百科：

为了以可预测的方式启用此类优化，C 编程语言的 ISO 标准（包括其较新的 C99 版本）指定不同类型的指针引用同一内存位置是非法的（有一些例外）。这条规则被称为“严格别名”，可以显着提高性能[需要引用]，但众所周知会破坏一些其他有效的代码。一些软件项目故意违反 C99 标准的这一部分。例如，Python 2.x 这样做是为了实现引用计数，[1] 并且需要更改 Python 3 中的基本对象结构才能实现此优化。 Linux 内核这样做是因为严格的别名会导致内联代码优化出现问题。[2]在这种情况下，当使用 gcc 编译时，会调用选项 -fno-strict-aliasing 以防止可能产生不正确代码的不需要的或无效的优化。

Answer 11

是的，编译器优化可能很危险。通常，硬实时软件项目正是出于这个原因而禁止优化。无论如何，你知道有没有没有错误的软件吗？

激进的优化可能会缓存变量，甚至对变量做出奇怪的假设。问题不仅在于代码的稳定性，而且它们还可以欺骗您的调试器。我曾多次看到调试器无法表示内存内容，因为某些优化在微寄存器中保留了变量值。

您的代码也可能发生同样的情况。优化将变量放入寄存器中，并且在完成之前不要写入该变量。现在想象一下，如果您的代码有指向堆栈中变量的指针并且有多个线程，情况会有多么不同

Answer 12

当然，理论上这是可能的。但是，如果您不相信这些工具能够完成其应有的任务，那么为什么要使用它们呢？但马上，任何从立场上争论的人

“编译器是由聪明人构建的
并做聪明的事情”，因此，可以
永远不会出错。

正在做出愚蠢的论点。

因此，除非您有理由相信编译器正在这样做，否则为什么要对此做出姿态呢？

Answer 13

我当然同意这样说是愚蠢的，因为编译器是由“聪明人”编写的，因此它们是绝对正确的。聪明人还设计了兴登堡大桥和塔科马海峡大桥。即使编译器编写者确实是最聪明的程序员之一，但编译器也是最复杂的程序之一。当然他们也有缺陷。

另一方面，经验告诉我们，商业编译器的可靠性非常高。我已经多次有人告诉我，程序无法运行的原因一定是因为编译器中的错误，因为他已经非常仔细地检查了它，并且他确信它是 100% 正确的......然后我们发现实际上是程序有错误，而不是编译器有错误。我试图回想一下我个人遇到过的一些事情，我确信这是编译器中的一个错误，但我只能回忆起一个例子。

所以总的来说：相信你的编译器。但他们有错吗？当然。

Answer 14

它有可能发生。它甚至影响了 Linux。

Answer 15

我记得，早期的 Delphi 1 有一个错误，即 Min 和 Max 的结果颠倒了。仅当浮点值在 dll 中使用时，某些浮点值还存在一个不明显的错误。诚然，已经十多年了，我的记忆可能有点模糊了。

Answer 16

我在 .NET 3.5 中遇到了一个问题，如果您使用优化进行构建，将另一个变量添加到一个方法，该方法的命名类似于同一范围内相同类型的现有变量，那么两个变量（新变量或旧变量）之一将不会在运行时有效，并且对无效变量的所有引用都将替换为对另一个变量的引用。

因此，例如，如果我有 MyCustomClass 类型的 abcd 和 MyCustomClass 类型的 abdc，并且设置 abcd.a=5 和 abdc.a=7，那么这两个变量都将具有属性 a=7。要解决此问题，应删除这两个变量，编译程序（希望没有错误），然后重新添加它们。

我想我在使用 .NET 4.0 和 C# 做 Silverlight 应用程序时也遇到过几次这个问题。在我上一份工作中，我们经常在 C++ 中遇到这个问题。可能是因为编译需要 15 分钟，所以我们只会构建我们需要的库，但有时优化后的代码与之前的构建完全相同，即使添加了新代码并且没有报告构建错误。

是的，代码优化器是由聪明人构建的。它们也非常复杂，因此出现错误是很常见的。我建议全面测试大型产品的任何优化版本。通常，有限用途产品不值得完整发布，但仍应对其进行总体测试，以确保它们正确执行常见任务。

Answer 17

编译器优化可以揭示（或激活）代码中休眠（或隐藏）的错误。您的 C++ 代码中可能存在您不知道的错误，只是您没有看到它。在这种情况下，它是一个隐藏或休眠的错误，因为代码的该分支没有执行[足够的次数]。

代码中出现错误的可能性比编译器代码中出现错误的可能性大得多（数千倍）：因为编译器经过了广泛的测试。通过 TDD 加上几乎所有自发布以来使用过它们的人！）。因此，几乎不可能一个错误是由您发现的，而不是被其他人使用数十万次才发现的。

休眠错误或隐藏错误只是尚未向程序员揭示的错误。能够声称他们的 C++ 代码没有（隐藏的）错误的人非常罕见。它需要 C++ 知识（很少有人能做到这一点）和对代码的广泛测试。这不仅与程序员有关，还与代码本身（开发风格）有关。容易出现错误取决于代码的特征（测试的严格程度）或/和程序员的特征（测试的纪律程度以及对 C++ 和编程的了解程度）。

安全性+并发错误：如果我们将并发性和安全性视为错误，情况会更糟。但毕竟，这些“都是”错误。编写在并发性和安全性方面首先没有错误的代码几乎是不可能的。这就是为什么代码中总是存在错误，这些错误可能会在编译器优化中被发现（或被遗忘）。

Answer 18

如果您编译的程序具有良好的测试套件，则可以启用更多、更积极的优化。然后就可以运行该套件并更加确定程序运行正确。此外，您还可以准备自己的测试，与您计划在生产中执行的测试紧密匹配。

确实，任何大型程序都可能有（并且可能确实有）一些错误，这些错误与您使用哪些开关来编译它无关。

Answer 19

我从事一个大型工程应用程序的工作，我们时不时地会看到客户报告的仅发布崩溃和其他问题。我们的代码有 37 个文件（超出了
6000），我们在文件顶部有这个，关闭优化来修复此类崩溃：（

#pragma optimize( "", off)

我们使用 Microsoft Visual C++ 本机，2015，但这对于几乎任何编译器都是如此，除了 Intel Fortran 2016 update 2，其中我们还没有关闭任何优化。）

如果您搜索 Microsoft Visual Studio 反馈站点，您也可以在那里找到一些优化错误。我们偶尔会记录一些我们的问题（如果您可以用一小部分代码轻松地重现它并且您愿意花时间）并且它们确实得到修复，但遗憾的是其他问题又被引入。 smiles

编译器是人们编写的程序，任何大型程序都会有错误，相信我。编译器优化选项肯定存在错误，并且打开优化肯定会在程序中引入错误。

Answer 20

您可以想象对程序执行的任何操作都会引入错误。

Answer 21

由于详尽的测试以及实际 C++ 代码的相对简单（C++ 有不到 100 个关键字/运算符），编译器错误相对较少。糟糕的编程风格通常是他们遇到的唯一问题。通常编译器会崩溃或产生内部编译器错误。这条规则的唯一例外是 GCC。 GCC，尤其是旧版本，在 O3 甚至其他 O 级别中启用了许多实验性优化。 GCC 还针对如此多的后端，因此在中间表示中留下了更多的错误空间。

Answer 22

昨天我在 .net 4 上遇到了一个问题，看起来像......

double x=0.4;
if(x<0.5) { below5(); } else { above5(); }

并且它会调用 above5(); 但如果我实际上在某个地方使用 x ，它会调用below5();

double x=0.4;
if(x<0.5) { below5(); } else { System.Console.Write(x); above5(); }

代码不完全相同，但相似。