1) ABI compatibility is not present. With clang-cl you can compile half of your object files with MSVC and half with clang-cl, and link them together. That's very powerful. You might be thinking "but who is really gonna do that anyway?" However, there is more to the ABI than just this. For example, consider what happens if you need to use Structured Exception Handling. Well, with GCC, you can't.

2) Debug Information. GCC does not emit PDBs, it emits DWARF. This means you cannot use Visual Studio to debug, you cannot use vTune or WPA to profile, you cannot use symbol / source servers.

3) There are licensing implications, GPL != BSD and it's easier to use BSD.

These are the main reasons. There are other reasons though, such as if the entire goal is to get down to 1 toolchain and that toolchain is X, then why would you waste your time converting Y to Z?

> if you need to use Structured Exception Handling. Well, with GCC, you can't

You can on 64 bit.

Lack of PDB support is one reason:

https://stackoverflow.com/questions/19269350/how-to-generate...

Lack of VC++ ABI support would be another reason.

Why use it? llvm is the future anyway and lots of players have a stake in it and contribute to it.

In fact, there are way too many c++ compilers if you ask me. I would gladly accept a world where clang is the one and only.

>I would gladly accept a world where clang is the one and only.

And luckily you don’t have any saying in such matters.

Sure. I just vote with my feet, like many others.

> In fact, there are way too many c++ compilers if you ask me. I would gladly accept a world where clang is the one and only.

Not me, IMO clang is where it is due to competition.

It's not ABI compatible with MSVC

I used to use mingw to cross-build a project.

At one point, after updating the toolchain from gcc 4.x to 7.x and from mingw32 to mingw-w64, it started to produce broken binaries.

The manifestation of that brokenness was that binaries refused to start properly on systems where the toolchain was not installed. It just silently exited during startup - no crash, or error message, or anything.

This applied both to binaries that were cross-built on linux, and binaries built using MSYS2 on Windows.

I decided to just switch to clang-cl + MSVC headers instead, which worked properly. The only gotcha there was the need to store the headers on a case insensitive file system (I chose vfat) when compiling on linux, because the case of the includes aren't consistent (e.g. Windows.h vs. windows.h), even in the MSVC headers themselves.

were you missing compiler runtime libraries? like any code compiled with gcc anywhere that links the runtimes as shared libraries, they'll need to be present for executables to run. depending which variant of mingw-w64 you used, there are more runtime library dependencies than there used to be, like winpthreads for c++11 thread support.

Fairly certain that wasn't the case.

As far as I could tell, the only DLLs the binaries referenced were msvcrt.dll and standard windows DLLs (KERNEL32, USER32, etc).

The application was also plain C.

Even if missing compiler runtime libraries were the issue, I would have expected the program crash or fail with an error message.

Unfortunately, mingw profiling code and the toolchain is tainted with GPL.

Isn't it "GPL + GCC exception"?

1. Not abi compatible

2. Not performant (Relative to other solutions)

3. Would be the odd man out. Literally all other development was on clang/llvm at this point.

Supporting mingw would have meant duplicating all performance/etc work for GCC.

4. Chrome also wanted other benefits that clang/LLVM would bring them (easy ability to build various forms of refactoring and analysis tooling, etc)

Performance of the resulting binary, if I was to guess.