You don't have to _build_ anything, you are simply using the Clang compiler with the GCC standard library

The C++ compiler and the C++ standard library exist as separate components. You're free to mix and match them. You just need to configure the relevant compiler and linker flags (which may be harder on GCC than Clang, for instance)

And if you mean to just #include <ranges>, that's not right at all

For instance, installing LLVM/Clang on Fedora Rawhide uses Redhat GCC 12.2 as the default stdlib right now, and including <ranges> works perfectly fine:

  [user@MSI ~]$ clang++-15 -v
  clang version 15.0.0 (Fedora 15.0.0-5.fc38)
  Target: x86_64-redhat-linux-gnu
  Thread model: posix
  InstalledDir: /usr/bin
  Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-redhat-linux/12
  Selected GCC installation: /usr/bin/../lib/gcc/x86_64-redhat-linux/12

EDIT: I take it back, you're right. You can #include it but if you try to use parts of it, it will cause compile errors

> The C++ compiler and the C++ standard library exist as separate components

this is not really true. Aside from the fact that the standard library need not be a library at all and could just be built-in, in practice the standard library provided by a compiler is intimately tied with that (specific version of the) compiler. libstdc++ uses plenty of GCC specific non-standard extensions and relies on implementation specific and often undocumented behaviour.

Clang tries to implement all the same extensions and GCC developers try not to break clang support too often (sometimes even providing clang specific workarounds or gating out non-implemented features), but as you have experienced, breakage does happen form time to time.

In this case the breakage is not caused by extensions, though. It's caused by a bug in the C++20 support in clang, at least according to the GNU people.