I'm not sure about moral per se, but LLVM is practically a painful dependency—it doesn't have API compatibility between versions, release builds are rapidly approaching a gigabyte, you are given some franken-version by the system, and you won't have a good time if you end up linking/loading more than one version for whatever reason.
IIRC there was also some case where an LLVM bump caused tcmalloc to explode inside wine.
Vulkan capture support on Windows was introduced in v25 (on linux you need to use a plugin). There is no Vulkan renderer support—which the post clearly stated...
With the common case of SimplifyCFG turning this into an assumption (for ReleaseFast), this is UB (LLVM def) unless you can prove that the assumption always holds.
I suppose that's par for the course with an unchecked release build, but at the same time memory corruption is much easier to debug as compared to 'the compiler changed the logic of my program in strange/incorrect ways'.
While no compiler is perfect (e.g., pointer provenance), one could just as easily argue that Clang has higher quality—most modern C/++ tooling is built on it, sanitizers are brought up in Clang and sometimes ported to GCC later, all of the modern safety work is in Clang (-Wbounds-safety, the various thread safety approaches, lifetime analysis, Sean’s borrow checked C++, Fil-C). The Clang static analyzer has also been used in production for over a decade, whereas -fanalyzer is still experimental and limited to C, …
I have the feeling that the bugs that aren’t being fixed are either because the bug report is unactionable (3yr old Ubuntu Franken-clang is slower than than 3yr old franken-gcc) or because the problem is very non-trivial (e.g., you can find recent discussion about enabling dependence analysis by default, the aforementioned pointer provenance issues stemming from C, ABI/lowering warts around large _BitInt)
IIRC there was also some case where an LLVM bump caused tcmalloc to explode inside wine.