[compiler-rt] Clarify support for windows

[h-vetinari]

In 0318ce8, @AaronBallman added the following to the C status page for support of <complex.h>:

_Complex support requires an underlying support library such as compiler-rt to provide functions like __divsc3, but compiler-rt is not supported on Windows.

The following discussion ensued in the corresponding PR:

@h-vetinari: I'm surprised about the "compiler-rt is not supported on windows" comment - in our distribution, we've been building compiler-rt on windows for years, and I don't remember significant issues.

It's true that __divsc3 is not available without compiler-rt (i.e. just relying on the msvc runtime libraries), but together with compiler-rt these things are generally possible? Note that a similar situation exists on osx-arm for example - in certain situations, linking compiler-rt is unavoidable.

@AaronBallman: CC @petrhosek as compiler-rt CRT code owner -- is compiler-rt officially supported for Windows? The official documentation does not mention it under platform support: https://compiler-rt.llvm.org/

That statement of lack of support was now reiterated in 918ef31, and so I thought I'd open this issue to discuss.

In conda-forge¹, we've been building and shipping compiler-rt since LLVM 9.0, and I'm not aware of fundamental issues that render the runtime unusable. To the contrary, it's been a required component to get our flang-support for windows off the ground (which itself was a very long story).

As such, I'd very much like for compiler-rt to stay at least as usable as it has been over the last 5 years, even if perhaps the support may not be on par with other platforms. Better still would be explicit support of course. :)

Footnotes

1. can be thought of as a rolling distribution across linux, osx, windows simultaneously ↩

[h-vetinari]

FWIW, #101462 adds support for compiler-rt on windows with an architecture that's way less common than x64. CC @mstorsjo

[mstorsjo]

FWIW, #101462 adds support for compiler-rt on windows with an architecture that's way less common than x64.

To expand on this a little. compiler-rt builtins have worked for Windows on arm32 for a very long time already. The sanitizers have failed to build so far though. Now they compile successfully, but asan runtime hooking doesn't work, on neither arm nor aarch64.

Anyway, compiler-rt does work on Windows, and I know of a number of organizations that continuously use it in such settings. The sanitizers exist and work. The builtins also work - but they just aren't linked in automatically in MSVC style setups. In MinGW style setups, they do work (you either link libgcc or compiler-rt, but either one does get linked in automatically).

It's sad that @petrhosek didn't reply when asked in #88161 (comment) though. Maybe @vitalybuka can step in as well, if @petrhosek doesn't have time to reply?

I would say that the way forward here is:

1. Make a PR and add Windows to the list of officially supported OSes in https://compiler-rt.llvm.org/
2. Make a PR to the newly added Clang docs, and clarify the wording. When saying "Windows", it covers both MSVC and MinGW style setups. MinGW style setups have no problem here at all. MSVC style setups don't get compiler-rt builtins linked in automatically. But whether compiler-rt supports Windows or not, is not part of the problem at all.

[mstorsjo]

I filed such PRs in #106874 and #106875.

[petrhosek]

I somehow completely missed #88161 (comment) (I'm also not the owner of compiler-rt, CRT in CODE_OWNERS.TXT refers only to crtbegin.o and crtend.o). I agree with @mstorsjo's assessment and proposed plan.

[mstorsjo]

Both #106874 and #106875 were merged now, so I guess this issue is fixed then?

Relatedly, when looking at https://compiler-rt.llvm.org, it seems like the list of supported architectures is extremely outdated. From a quick comparison with e.g. compiler-rt/lib/builtins, we have at least some code for aarch64, riscv, loongarch, VE, hexagon and AVR, in addition to the OSes listed on that webpage. Not sure what the maturity is for all of them, but I would expect that at least aarch64 and riscv are quite mature.

[h-vetinari]

Fine for me to close - thanks a lot for confirming that this is supported! :)