Martin Storsjö

I merged https://github.com/mstorsjo/llvm-mingw/pull/385 now, so this should be fixed in future builds (including nightly builds). FWIW, earlier, one of my main concerns was that the GitHub Actions based builds were...

> Personally, I'd consider dropping ARM support to offset the build time bloat caused by NVPTX. Microsoft has already [dropped arm32](https://blogs.windows.com/windows-insider/2023/07/12/announcing-windows-11-insider-preview-build-25905/). I wouldn't quite go so far to drop support...

A prerelease with LLVM 18.1.0 RC 1 is out now, at https://github.com/mstorsjo/llvm-mingw/releases/tag/20240130, where this issue should be fixed.

I'm not familiar with the CUDA bits of LLVM at all, unfortunately. If I've understood correctly, even if you build CUDA code with LLVM, you still need to compile the...

> After a few months of 20-second compiles on Windows that would take 1 second on Linux, I stumbled into this and immediately noticed that it doesn't exhibit the horrific...

> > And secondly, the Clang executables I distribute for Windows are hardcoded to default to `--rtlib=compiler-rt` builtin, and for the MSVC target, there doesn't seem to be any way...

> > Unfortunately, the way this is done right now, by setting `-DCLANG_DEFAULT_RTLIB=compiler-rt` when doing the cmake configuration, it applies to any cross target. Allowing to hardcode different defaults for...

> > Originally, I also had big monolithic executables, but since the following release after that, I enabled `-DLLVM_LINK_LLVM_DYLIB=ON` in the build, which keeps most of the code in shared...

> > That works fine in general, but it does require you to run in an environment with `INCLUDE` and `LIB` already set up. The codepath for detecting a modern...

> > That works fine in general, but it does require you to run in an environment with INCLUDE and LIB already set up. The codepath for detecting a modern...