开发者——至我们所有人！是否经常焦虑自己的代码被否定。不存在的，就算有，也肯定是编译器的错。
而实际情况是一段代码出错几乎(一万个几乎)不可能是由于编译器、解释器、OS、应用服务、数据库、内存管理器，或任何系统级的软件导致的。你信或者不信，bug就在那里，只是没你想的那么普遍。
我有次是真遇到这种情况，编译器错误地优化了循环变量，但在此之前我已经在脑瓜里意淫过无数遍(就是编译器的错)。我浪费了大把的时间，都把时间花在意淫里，然而事后证明就是自己的错时，又感觉自己多么愚昧。
假设一个工具被广泛使用，且成熟应用于各技术栈当中，那只可能有很少的情况下应该去质疑它的质量。当然，除非它刚发布，或者用的人很少，再或者下载量小，0.1版本，开源软件等情况下，确实有可能找到很多质疑点。(同样，商业软件的alpha版本也会被质疑)。
编译器级别的bug如此罕见，你其实可以更好地花时间和精力去找到错误，而不仅仅是为了证明是编译器的错。利用所有可用的调试手段，隔离问题，存根调用，包围式打击(测试)；检查所有调用约定、共享库、版本号；和别人解释；找出堆栈破损以及变量类型不匹配的地方；尝试在不同机器及不同构建配置中重新跑这段代码，比如debug和release版本；
质疑你自己的假设和他人的假设。工具出自不同厂商之手，就会有不同的情景假设来构建它们——同一个厂商的不同工具也可能。当其他人在报告这个问题你就没必要重复了，去看看他们在做什么。他们可能正在做一些你从未想过或不按套路走的事情。
如果有bug却无法定位问题的时候，个人往往会认为问题出在编译器，并把时间用来查找堆栈破损。如果经过跟踪调试后解决了该问题，那就确定无疑了。
其他代码中的bug引发的多线程问题可以把你头发都急白了。所有建议都赞同，简单的代码在多线程系统里将变得不简单。调试和单元测试在查找一致性错误时会变得不可靠，所以请保持简单朴素的设计。
所以，先别急着去怪编译器，记住夏洛克·福尔摩斯的一句话：“排除一切不合理，无论剩下什么，无论多么不可能，那就是真相”。更喜欢Dirk Gently的另一句话：“排除一切的不可能，无论剩下什么，无论多么不合理，那就是真相”。
