Add support for building with ClangCL on Windows

[saghul]

No description provided.

[saghul]

clang-cl : error : unknown argument ignored in clang-cl: '-funsigned-char' [-Werror,-Wunknown-argument] [D:\a\quickjs\quickjs\build\qjs.vcxproj]
clang-cl : error : unknown argument ignored in clang-cl: '-g' [-Werror,-Wunknown-argument] [D:\a\quickjs\quickjs\build\qjs.vcxproj]

I need to add flag checking probably...

[bnoordhuis]

CMakeLists.txt should probably exclude ClangCL on this line:

if(CMAKE_C_COMPILER_ID MATCHES "AppleClang|Clang")

[saghul]

I just had a few minutes to test earlier 😅

I think a better way is to check if the compiler supports a given flag so it works without explicit compiler checks, I'll give that a try...

[saghul]

Ok, we need the performance.now() Windows implementation then. I'll lift it off libuv :-)

[saghul]

@bnoordhuis Can I have an extra brain here? :-) Currently this is failing with:

 lld-link : error : undefined symbol: __udivti3 [D:\a\quickjs\quickjs\build\qjsc.vcxproj]
  >>> referenced by D:\a\quickjs\quickjs\libbf.c:1319
  >>>               qjs.lib(libbf.obj):(mp_divnorm)
  >>> referenced by D:\a\quickjs\quickjs\libbf.c:5776
  >>>               qjs.lib(libbf.obj):(mp_div1_dec)
  >>> referenced by D:\a\quickjs\quickjs\libbf.c:1220
  >>>               qjs.lib(libbf.obj):(udiv1norm_init)
  >>> referenced 7 more times

Which AFAIS is because the int128 functions are in clang-rt and not in MS's crt. I guess we need to embed that? A cursory look suggests it got fixed in Clang 17.X but that doesn't seem available here... Any ideas?

[bnoordhuis]

You probably only need to reimplement divdq and muldq and I think you can do that with _udiv128 and _umul128 from <immintrin.h> - edit: x86_64 only but IMO no 32 bits support is okay

[saghul]

I'm going to need a passport to travel so far away from my comfort zone 😅

I'll give it a try!

[bnoordhuis]

I had a look and I don't think my suggestion is going to work - libbf.h also references int128_t and uint128_t - but what you can probably do is forcing LIMB_BITS to 32, i.e.:

diff --git a/libbf.h b/libbf.h
index dacc2a6..a11016d 100644
--- a/libbf.h
+++ b/libbf.h
@@ -27,7 +27,7 @@
 #include <stddef.h>
 #include <stdint.h>
 
-#if INTPTR_MAX >= INT64_MAX
+#if INTPTR_MAX >= INT64_MAX && !defined(_WIN32)
 #define LIMB_LOG2_BITS 6
 #else
 #define LIMB_LOG2_BITS 5

[saghul]

Thanks for taking a look! 🙏

[saghul]

Fucking A Ben!

I think the test can be related to !defined(_MSC_VER) since compiling with MinGW GCC is ok, only ClangCL seems to be the problem.

In addition, I'll check if the direct dispatch change is necessary. It gives a warning about gnu style labels but if it works I guess we don't need to change it.

[bnoordhuis]

I think the test can be related to !defined(_MSC_VER) since compiling with MinGW GCC is ok, only ClangCL seems to be the problem.

I'm not 100% sure but I can see that breaking when:

1. compiling libquickjs.a with mingw, then
2. trying to consume it with clang-cl

...because compiler-rt doesn't provide the builtins mingw emits.

[saghul]

@bnoordhuis I think this one is ready! The rabbithole was deeper than I thought! 😅

[bnoordhuis]

👍