3 ms·
> Conclusion: The problem was specific to Windows x64 builds. > Then I tried a Release build with GCC (MinGW), and I successfully reproduced the bug. GCC (Min
by RcouF1uZ4gsC 4y ago
> Conclusion: The problem was specific to Windows x64 builds.
> Then I tried a Release build with GCC (MinGW), and I successfully reproduced the bug.
GCC (MinGW) is probably the least battle tested of the major C++ compilers on Windows. The vast majority of commercial software on Windows is built with MSVC. Google builds Chrome with Clang. GCC on Windows doesn’t have nearly the same number of (paid) eyeballs looking for problems.
The chances of finding compiler bugs go up if you use less widely used compilers on a platform.
- boris 4y agoI think this is the correct line of reasoning but I disagree with the conclusion: yes, MSVC is (unfortunately) most battle-tested where codegen is concerned. But next I believe is MinGW GCC, not Clang. Clang is used to build Chrome (and Firefox) but both of these codebases have C++ exceptions disabled. The result is you end up with bugs like this[1] which remains unfixed for years. IME, MinGW GCC`s achilles' heel is requiring pthread (via libwinpthreads) for C++11 threads support (see here[2] for details). [1] https://bugs.llvm.org/show_bug.cgi?id=45021 https://bugs.llvm.org/show_bug.cgi?id=45021 [2] https://github.com/build2-packaging/libmingw-stdthread#background https://github.com/build2-packaging/libmingw-stdthread#backg...
- strager 4y agoThat's a good point. I never thought of this. I assumed that, because Clang+MinGW was newer, it's less stable. That's why I went with GCC+MinGW. I completely forgot about the positive corporate influence on Clang.