This is what I do. I use clang for everything except the final release. I get clang's speed and superior error messages while I'm editing code, and I get the very slightly, but measurably faster code generated by GCC.

I've always used gcc on all platforms for C and C++, but since last year I also use clangformat.

On the other hand, the effort of learning clang options, error messages and paths in order to have two compilers available can wait indefinitely until I really need a second opinion about some compilation error; so far it hasn't happened.

You could build with bazel, which ships compiler configs for clang and gcc on linux (among other combinations) in its "CROSSTOOL"[1] file. Then it's trivial to switch compilers with one argument. This feature is a result of Google's years-long support of both GCC and clang for its own build, test, and release.

  $ bazel build --compiler=my_favorite_compiler //my/fine:program

1: https://github.com/bazelbuild/bazel/wiki/Building-with-a-cus...

Sorry, I lost you at "bazel". Do you believe constructing clang command lines in addition to gcc command lines is harder than setting up a particularly complex build tool like Bazel? Not to mention that it doesn't appear to support GCC and Clang on Windows.

Bazel comes with an installer package that you click and run. I didn't find it that complicated. It comes out of the box with CROSSTOOL support for GCC, clang, and MSVC on Windows, among dozens of other toolchains.

https://github.com/bazelbuild/bazel/blob/master/tools/cpp/CR...

The official documentation at https://docs.bazel.build/versions/master/windows.html says:

Build C++

To build C++ targets, you need:

•The Visual C++ compiler.

Whether the developers gave up on the Mingw64 GCC and Clang toolchains or it's a documentation mistake, this statement places Bazel support for Windows in the "don't touch with a 10' pole" category.

But my point was that adopting Bazel is obviously far more complex than adapting existing build scripts and build script generators for Make, Cmake, Ninja etc to use Clang.

Options are mostly the same. You can easily switch out the two compilers in most build systems. Make: make CC=clang CXX=clang++. Cmake: cmake -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++. Autoconf: CC=clang CXX=clang++ ./configure.

This seems like it would be a nightmare to deal with if things ever went wrong. Is this actually a viable option?

Just run CI + tests using the release compiler instead of the dev one. Not a big deal.

Also it’s trivial to change the dev compiler when debugging something that might be a compiler error (it never is though).

I had a similar workflow, except icc for release, which still outperforms gcc on certain types of codebases.