Martin Kinkelin

Thanks, confirmed, it's a more general issue with our CMake script having an outdated whitelist of directories from which the runtime modules are pulled in. I'll work on a more...

That particular `etc.linux.memoryerror` module causes additional, non-trivial trouble, see #1917. I'm pretty sure I recently read something about it being scheduled for deprecation (from Walter), so I won't put any...

* Doesn't work on macOS yet, because it's not using a host clang with the same LLVM version. * Loads of hash mismatches on both Windows and Linux. The main...

> Loads of hash mismatches on both Windows and Linux. Using LTO for the instrumented binary too hasn't gotten rid of those, although the relevant CMake flags should be identical...

Ah, so `-fprofile-instr-*` != `-fprofile-*` for clang either - it works now on Linux. On Windows, `clang-cl` supports `-fprofile-generate`, but not `-fprofile-use` (**edit**: https://github.com/llvm/llvm-project/issues/55564)...

There are some WTF moments here. So first of all, using vanilla clang 14 as C(++) compiler for the macOS jobs worked fine, even for arm64 cross-compilation. I was expecting...

Okay, that's sorted now too; those hash mismatches originated from the D parts of the ldc2-unittest executable, which don't use the PGO profiles anymore now.

For some Symmetry code and a Linux debug build, I'm seeing some ~1% reduction in compile times over frontend-PGO only.

Thanks, looking good.

> BetterC build are still possible, and don't use the runtime. Yes, but WASI libc won't be linked automatically, as `-betterC` discards all `-defaultlib`. The compiler has a hardcoded list...