[7/N] [libcxx] Don't use __int128 for msvc targets

[mstorsjo]

Summary

While clang-cl can compile it just fine, the compiler support lib lacks support for it (as compiler-rt builtins aren't used).

This means that file_time_type has a shorter range on this target (+/- 292 years from the epoch). This is smaller than the range of the windows native file time type (which is 64 bit, with a 100 ns unit, from an epoch of year 1601), but covers the practically used range just fine. See docs/DesignDocs/FileTimeType.rst for more of the tradeoffs this means.

[ldionne]

This influences the ABI IIRC, so this choice may be forever. Shouldn't we fix the compiler support lib on Windows instead?

[mstorsjo]

In D91139#2386019, @ldionne wrote:

This influences the ABI IIRC, so this choice may be forever.

Well afaik the ABI of libc++ on windows is rather non-fixed so far anyway

Shouldn't we fix the compiler support lib on Windows instead?

The thing is, in setups when building with clang-cl, i.e. clang operating in MSVC mode, we only use the MSVC provided support libs, so there's not much we can fix ourselves there.

@rnk, @thakis, what do you guys think?

[mstorsjo]

I guess the alternative is to lift implementations of __divti3 and __udivti3 from compiler-rt and place in libcxx/src/filesystem - there's already a copy of __muloti4 there, due to libgcc missing it, and we could provide those other two as well, for msvc builds.

[mstorsjo]

In D91139#2386965, @mstorsjo wrote:

I guess the alternative is to lift implementations of __divti3 and __udivti3 from compiler-rt and place in libcxx/src/filesystem - there's already a copy of __muloti4 there, due to libgcc missing it, and we could provide those other two as well, for msvc builds.

Made such an alternative fix in D91413.

[amccarth]

I'm out of my depth on 128-bit arithmetic and ABIs.

[rnk]

After having dealt with an increasing number of user complaints about lack of i128 support, I am of the opinion that we should start shipping, auto-linking, and requiring clang_rt.builtins in clang-cl.

However, it's a bit of a project to make this work out of the box, since clang's runtime libraries are not on the linker search path. We'd need to update our msbuild integration bits and some documentation. But it's time to do that work already.

[ldionne]

In D91139#2429595, @rnk wrote:

After having dealt with an increasing number of user complaints about lack of i128 support, I am of the opinion that we should start shipping, auto-linking, and requiring clang_rt.builtins in clang-cl.

However, it's a bit of a project to make this work out of the box, since clang's runtime libraries are not on the linker search path. We'd need to update our msbuild integration bits and some documentation. But it's time to do that work already.

So, if I understand correctly, you're suggesting that the int128 builtins should be provided on Windows, and this workaround shouldn't be necessary once that's done? In that case, unless @mstorsjo disagrees, I think we're better holding off with this patch.

[mstorsjo]

In D91139#2431269, @ldionne wrote:

In D91139#2429595, @rnk wrote:

After having dealt with an increasing number of user complaints about lack of i128 support, I am of the opinion that we should start shipping, auto-linking, and requiring clang_rt.builtins in clang-cl.

However, it's a bit of a project to make this work out of the box, since clang's runtime libraries are not on the linker search path. We'd need to update our msbuild integration bits and some documentation. But it's time to do that work already.

So, if I understand correctly, you're suggesting that the int128 builtins should be provided on Windows, and this workaround shouldn't be necessary once that's done? In that case, unless @mstorsjo disagrees, I think we're better holding off with this patch.

Yes, I'm fine holding off this patch for now - it's not needed for the rest of the series on mingw targets (that do use either libgcc or compiler-rt builtins) anyway.

[mstorsjo]

Abandoning this one for now, see https://reviews.llvm.org/D91139#2429595 for the supposed path forward for MSVC configurations. For mingw configurations, this patch isn't needed and everything else needed for std::filesystem is available.

libcxx/include/__config

 #  define _NOEXCEPT_(x)
 #endif
 
 #ifdef _LIBCPP_HAS_NO_UNICODE_CHARS
 typedef unsigned short char16_t;
 typedef unsigned int   char32_t;
 #endif  // _LIBCPP_HAS_NO_UNICODE_CHARS
 
-#ifndef __SIZEOF_INT128__
+#if !defined(__SIZEOF_INT128__) || defined(_MSC_VER)
 #define _LIBCPP_HAS_NO_INT128
 #endif
 
 #ifdef _LIBCPP_CXX03_LANG
 # define static_assert(...) _Static_assert(__VA_ARGS__)
 # define decltype(...) __decltype(__VA_ARGS__)
 #endif  // _LIBCPP_CXX03_LANG