[libcxx] [ci] Add CI configurations for MinGW

[mstorsjo]

Summary

Mention support for MinGW in the docs. Rename the existing windows
CI jobs to Clang-cl, as both Clang-cl and MinGW are equally much
"Windows", just different toolchain environments.

[mstorsjo]

Rebase on latest main, where there hopefully shouldn't be any more failures.

[ldionne]

libcxx/utils/ci/buildkite-pipeline.yml

509–510

I would prefer Clang-cl or something like that. For me, MSVC refers to the real MSVC compiler, not the Clang emulation.

libcxx/utils/ci/run-buildbot

630

We don't run the libc++abi tests?

647

It seems to me that the tests should have a dependency on libunwind if we are linking them against the just-built libunwind, no? Ideally we'd fix that in a separate patch before landing this.

[mstorsjo]

libcxx/utils/ci/buildkite-pipeline.yml

509–510

Ok, fair enough.

libcxx/utils/ci/run-buildbot

630

No, those don't work on Windows/MinGW yet, afaik.

647

I guess that could be handled with a cmake rule like this:

if (LIBCXXABI_USE_LLVM_UNWINDER)
  list(APPEND LIBCXX_TEST_DEPS unwind)
endif()

[mstorsjo]

libcxx/utils/ci/buildkite-pipeline.yml

509–510

Btw, one reason why I first chose to avoid naming it clang-cl, is that when running tests, we actually don’t run the clang-cl compiler fronted, but call the gcc style driver with -target *-windows-msvc. But I guess clang-cl still is close enough, and more concise than “clang in msvc mode”.

[mstorsjo]

Removed the explicit step of building libunwind, relying on D113467 instead. Renamed the old targets from "MSVC" to "Clang-cl".

[mstorsjo]

@ldionne Any further comments on this one, now that the manual build step for libunwind was removed?

[mstorsjo]

Rerun CI on top of current main.

[mstorsjo]

Sigh, one new test that has been added since this was run in CI last time breaks in this config, so I’ll have to figure out what’s up with that one before this can land…

[ldionne]

FWIW I'd be fine if you XFAILed the single test so we can figure it out later, to avoid delaying this further and possibly introducing more similar issues.

[mstorsjo]

Retry on top of latest main, now with an added XFAIL.

The root cause of the new issue is a combination of known issues with __exclude_from_explicit_instantiation__ in combination with dllimport, together with the fact that we run tests in C++2b mode while the library itself only was built in C++20 mode. (If the library too was built in C++2b mode, the issue wouldn't appear.)

[ldionne]

(If the library too was built in C++2b mode, the issue wouldn't appear.)

Oh really, do you know why?

[mstorsjo]

In D112215#3137336, @ldionne wrote:

(If the library too was built in C++2b mode, the issue wouldn't appear.)

Oh really, do you know why?

As __exclude_from_explicit_instantiation__ doesn't work as intended when dllimport/export is involved, it turns out that all the methods marked with that attribute actually do end up exported by the shared library. So the library built in C++20 mode lacks the method (as the method is only visible in C++2b mode), the test code in C++2b mode sees the new method and uses it (but expects an extern definition in the libc++ DLL due to the explicit template instantiation, as it doesn't honor __exclude_from_explicit_instantiation__).

If the library had been built in C++2b mode, the method would have existed in the library and been found there (even though the intent of the attribute was to use a local instantiation).

[ldionne]

In D112215#3137401, @mstorsjo wrote:

In D112215#3137336, @ldionne wrote:

(If the library too was built in C++2b mode, the issue wouldn't appear.)

Oh really, do you know why?

As __exclude_from_explicit_instantiation__ doesn't work as intended when dllimport/export is involved, it turns out that all the methods marked with that attribute actually do end up exported by the shared library. So the library built in C++20 mode lacks the method (as the method is only visible in C++2b mode), the test code in C++2b mode sees the new method and uses it (but expects an extern definition in the libc++ DLL due to the explicit template instantiation, as it doesn't honor __exclude_from_explicit_instantiation__).

If the library had been built in C++2b mode, the method would have existed in the library and been found there (even though the intent of the attribute was to use a local instantiation).

Got it, thanks. Yeah the real thing we need to do is fix the damn bug with __exclude_from_explicit_instantiation__.

libcxx/cmake/caches/MinGW.cmake

+set(LIBCXX_ENABLE_EXPERIMENTAL_LIBRARY OFF CACHE BOOL "")
+set(LIBCXX_HAS_WIN32_THREAD_API ON CACHE BOOL "")
+
+set(LIBCXX_CXX_ABI libcxxabi CACHE STRING "")
+set(LIBCXXABI_USE_LLVM_UNWINDER ON CACHE BOOL "")
+
+set(LIBCXXABI_ENABLE_SHARED OFF CACHE BOOL "")
+set(LIBCXX_ENABLE_STATIC_ABI_LIBRARY ON CACHE BOOL "")
+
+set(LIBCXX_USE_COMPILER_RT ON CACHE BOOL "")
+set(LIBCXXABI_USE_COMPILER_RT ON CACHE BOOL "")
+set(LIBUNWIND_USE_COMPILER_RT ON CACHE BOOL "")
+
+set(LIBCXX_TARGET_INFO "libcxx.test.target_info.MingwLocalTI" CACHE STRING "")
+
+# Without these flags, 'long double' (which is 80 bit on x86 mingw, but
+# 64 bit in MSVC) isn't handled correctly in printf.
+set(CMAKE_C_FLAGS "-D__USE_MINGW_ANSI_STDIO=1" CACHE STRING "")
+set(CMAKE_CXX_FLAGS "-D__USE_MINGW_ANSI_STDIO=1" CACHE STRING "")
+set(LIBCXX_TEST_COMPILER_FLAGS "-D__USE_MINGW_ANSI_STDIO=1" CACHE STRING "")

libcxx/docs/index.rst

 Libc++ also supports common platforms and architectures:
 
 =============== ========================= ============================
 Target platform Target architecture       Notes
 =============== ========================= ============================
 macOS 10.9+     i386, x86_64, arm64       Building the shared library itself requires targetting macOS 10.11+
 FreeBSD 10+     i386, x86_64, arm
 Linux           i386, x86_64, arm, arm64
-Windows         x86_64
+Windows         x86_64                    Both MSVC and MinGW style environments
 AIX             powerpc, powerpc64
 =============== ========================= ============================
 
 Generally speaking, libc++ should work on any platform that provides a fairly complete
 C Standard Library. It is also possible to turn off parts of the library for use on
 systems that provide incomplete support.
 
 However, libc++ aims to provide a high-quality implementation of the C++ Standard

libcxx/test/std/input.output/iostream.format/output.streams/ostream.formatted/ostream.inserters.arithmetic/pointer.volatile.pass.cpp

 //===----------------------------------------------------------------------===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.
 // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 //
 //===----------------------------------------------------------------------===//
 
 // <ostream>
 
 // UNSUPPORTED: c++03, c++11, c++14, c++17, c++20
 
+// This test fails on MinGW DLL configurations, due to
+// __exclude_from_explicit_instantiation__ not behaving as it should in
+// combination with dllimport (https://llvm.org/PR41018), in combination
+// with running tests in c++2b mode while building the library in c++20 mode.
+// (If the library was built in c++2b mode, this test would succeed.)
+// XFAIL: target={{.+}}-windows-gnu && windows-dll
+
 // template <class charT, class traits = char_traits<charT> >
 //   class basic_ostream;
 
 // basic_ostream& operator<<(const volatile void* val);
 
 #include <ostream>
 #include <cassert>
 

libcxx/utils/ci/buildkite-pipeline.yml

agents:
       os: "linux"
     retry:
       automatic:
         - exit_status: -1  # Agent was lost
           limit: 2
     timeout_in_minutes: 120
 
   # Tests on non-Unix platforms
-  - label: "Windows (DLL)"
-    command: "bash libcxx/utils/ci/run-buildbot windows-dll"
+  - label: "Clang-cl (DLL)"
+    command: "bash libcxx/utils/ci/run-buildbot clang-cl-dll"
     artifact_paths:
       - "**/test-results.xml"
     agents:
       queue: "windows"
     retry:
       automatic:
         - exit_status: -1  # Agent was lost
           limit: 2
     timeout_in_minutes: 120
 
-  - label: "Windows (Static)"
-    command: "bash libcxx/utils/ci/run-buildbot windows-static"
+  - label: "Clang-cl (Static)"
+    command: "bash libcxx/utils/ci/run-buildbot clang-cl-static"
+    artifact_paths:
+      - "**/test-results.xml"
+    agents:
+      queue: "windows"
+    retry:
+      automatic:
+        - exit_status: -1  # Agent was lost
+          limit: 2
+    timeout_in_minutes: 120
+
+  - label: "MinGW (DLL)"
+    command: "bash libcxx/utils/ci/run-buildbot mingw-dll"
+    artifact_paths:
+      - "**/test-results.xml"
+    agents:
+      queue: "windows"
+    retry:
+      automatic:
+        - exit_status: -1  # Agent was lost
+          limit: 2
+    timeout_in_minutes: 120
+
+  - label: "MinGW (Static)"
+    command: "bash libcxx/utils/ci/run-buildbot mingw-static"
     artifact_paths:
       - "**/test-results.xml"
     agents:
       queue: "windows"
     retry:
       automatic:
         - exit_status: -1  # Agent was lost
           limit: 2

libcxx/utils/ci/run-buildbot

 ;;
 armv7-noexceptions)
     clean
     generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/Armv7Thumb-noexceptions.cmake" \
                    -DLIBCXX_TEST_CONFIG="llvm-libc++-shared.cfg.in" \
                    -DLIBUNWIND_TEST_CONFIG="llvm-libunwind-shared.cfg.in"
     check-runtimes
 ;;
-windows-dll)
+clang-cl-dll)
     clean
     # TODO: Currently, building with the experimental library breaks running
     # tests (the test linking look for the c++experimental library with the
     # wrong name, and the statically linked c++experimental can't be linked
     # correctly when libc++ visibility attributes indicate dllimport linkage
     # anyway), thus just disable the experimental library. Remove this
     # setting when cmake and the test driver does the right thing automatically.
     generate-cmake-libcxx-win -DLIBCXX_ENABLE_EXPERIMENTAL_LIBRARY=OFF
     echo "+++ Running the libc++ tests"
     ${NINJA} -vC "${BUILD_DIR}" check-cxx
 ;;
-windows-static)
+clang-cl-static)
     clean
     generate-cmake-libcxx-win -DLIBCXX_ENABLE_SHARED=OFF
     echo "+++ Running the libc++ tests"
     ${NINJA} -vC "${BUILD_DIR}" check-cxx
 ;;
+mingw-dll)
+    clean
+    # Explicitly specify the compiler with a triple prefix. The CI
+    # environment has got two installations of Clang; the default one
+    # defaults to MSVC mode, while there's an installation of llvm-mingw
+    # further back in PATH. By calling the compiler with an explicit
+    # triple prefix, we use the one that is bundled with a mingw sysroot.
+    generate-cmake \
+          -DCMAKE_C_COMPILER=x86_64-w64-mingw32-clang \
+          -DCMAKE_CXX_COMPILER=x86_64-w64-mingw32-clang++ \
+          -C "${MONOREPO_ROOT}/libcxx/cmake/caches/MinGW.cmake"
+    echo "+++ Running the libc++ tests"
+    ${NINJA} -vC "${BUILD_DIR}" check-cxx
+;;
+mingw-static)
+    clean
+    generate-cmake \
+          -DCMAKE_C_COMPILER=x86_64-w64-mingw32-clang \
+          -DCMAKE_CXX_COMPILER=x86_64-w64-mingw32-clang++ \
+          -C "${MONOREPO_ROOT}/libcxx/cmake/caches/MinGW.cmake" \
+          -DLIBCXX_ENABLE_SHARED=OFF \
+          -DLIBUNWIND_ENABLE_SHARED=OFF
+    echo "+++ Running the libc++ tests"
+    ${NINJA} -vC "${BUILD_DIR}" check-cxx
+;;
 aix)
     export CC=ibm-clang
     export CXX=ibm-clang++_r
     clean
     generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/AIX.cmake" \
                    -DLIBCXX_TEST_CONFIG="ibm-libc++-shared.cfg.in" \
                    -DLIBCXXABI_TEST_CONFIG="ibm-libc++abi-shared.cfg.in" \
                    -DLLVM_ENABLE_RUNTIMES="libcxx;libcxxabi"
     # TODO: use check-runtimes once libunwind builds cleanly on AIX.
     ${NINJA} -vC "${BUILD_DIR}" install-cxx install-cxxabi
     ${NINJA} -vC "${BUILD_DIR}" check-cxx check-cxxabi
 ;;
 #################################################################