• 阶段2.和3.是对编译器本身的良好测试：如果它能自己编译（通常也能编译一些库，比如libgcc和libstdc++-v3），那么它就能处理一些重要的项目。
• 在阶段2.和3.中，您可以使用不同的选项生成编译器，例如不进行优化（-O0）或启用优化（-O2）。由于程序的输出/副作用不应取决于所使用的优化级别，因此编译器的任一版本必须为相同的源文件产生相同的二进制文件，即使这两个编译器是二进制的，差别很大。这是对编译器的另一个（运行时测试）。

如果出于某种原因您更喜欢非引导，请配置--disable-bootstrap。

从信息论的Angular 考虑这个问题，编译器的三阶段编译中的第一阶段并不产生编译器。它产生了一个需要实验验证的假设。一个好的编译器分发包的标志是，它将产生一个开箱即用的编译器，而不需要系统管理员或编译器开发人员做进一步的工作。发行版版本的工作编译器，并具有该品牌编译器版本的所需功能。
要做到这一点并不简单，要考虑到目标环境中的各种变量。

• 目标操作系统品牌
• 操作系统版本
• 操作系统设置
• Shell环境变量
• 可包含的标题
• 用于链接的库的可用性
• 传递到生成过程的设置
• 目标处理单元的体系结构
• 处理单元数
• 总线架构
• 执行模型的其他特征
• 编译器开发人员可能犯的错误
• 编译器生成人员可能犯的错误

在GNU编译器工具集中，以及在许多tarball发行版中，程序“configure”试图产生一个构建配置，该构建配置尽可能多地适应这些配置的排列。没有来自configure的错误或警告的完成并不能保证编译器将工作。此外，对于这个问题更重要的是，构建的完成也不能保证。
新构建的编译器可能适用于HelloWorld. c，但不适用于名为“智能星际控制和获取系统”的多项目、多存储库软件集合中的一千个源文件集合。
第二阶段和第三阶段是合理的尝试，至少检查一些编译器功能，因为编译器源代码本身很方便，并且对刚刚构建的假设工作的编译器有相当大的要求。
了解阶段一的结果和阶段二的结果不匹配是很重要的。它们的可执行文件和其他构建的工件是来自两个不同编译器的结果。阶段一的结果是用构建系统在“PATH”变量中列出的目录之一找到的任何东西编译的，以编译C和C源代码。阶段二的结果是用假设工作的新编译器编译的。有趣的概率考虑是这样的：
如果使用第一阶段的结果再次编译编译器的结果正好等于使用第二阶段的结果第三次编译编译器的结果，则两者很可能至少对于编译器的源代码所需的特征是正确的。
最后一句话可能需要重读十几遍。这其实是一个简单的想法，但动词compile和名词compiler的冗余会让一个结结结起来，需要几分钟才能解开并重新系上。源、目标和执行的动作都有相同的语言根源，不是一次而是三次。
截至2020年5月25日，编译器的构建说明陈述了相反的情况，这更容易理解，但只是轶事，没有得到三个阶段重要的原因。
如果stage 2和stage 3的比较失败，这通常表示stage 2编译器错误地编译了GCC，因此这是一个潜在的严重错误，您应该调查并报告。
如果我们从可靠性评估、测试优先、极限编程、6-Sigma或全面质量管理的Angular 来考虑C/C开发，在C/C++开发环境中，有什么组件必须比编译器更可靠呢？并不多。甚至GNU编译器包从早期就开始使用的编译器的三阶段自举也是一个合理的测试，但不是详尽的测试。这就是为什么在软件包中有附加测试的原因。
从持续集成的Angular 来看，在编译和部署新编译器之前和之后，应该对那些即将使用新编译器的开发人员正在开发的整个软件主体进行测试。这是确保新编译器不会破坏构建的最方便的方法。
在这三个可靠性检查点之间，大多数人都感到满意。
1.确保编译器以一致的方式编译自身
1.编译器开发人员在其发行版中进行的其他测试
1.开发人员或系统管理员源代码域不会因升级而中断
从数学的Angular 来说，用地球上可用的硅和碳来彻底测试编译器实际上是不可能的。（以及其他）是无限的，所以测试源代码的每一个排列所需的硅或时间的地方实际上不可能存在。在碳方面，没有一群人能够腾出必要的时间来充分研究源代码，以保证编译器源代码不会以某种方式施加某种有限的限制。

这三个层次的检查，其中只有一个是三阶段自举过程，可能会满足我们大多数人。
三阶段编译的另一个好处是，新的编译器是用新的编译器编译的，新的编译器在速度或资源消耗方面可能更好，并且可能在两者方面都更好。