[PATCH] D34606: [libcxx] Link MinGW libs for shared build

[Mateusz Mikuła via Phabricator via cfe-commits]

mati865 created this revision.
Herald added a subscriber: mgorny.

Another small step for libc++ with MinGW-w64.


Repository:
  rL LLVM

https://reviews.llvm.org/D34606

Files:
  lib/CMakeLists.txt


Index: lib/CMakeLists.txt
===
--- lib/CMakeLists.txt
+++ lib/CMakeLists.txt
@@ -126,6 +126,26 @@
   # Required for standards-complaint wide character formatting functions
   # (e.g. `printfw`/`scanfw`)
   add_library_flags(iso_stdio_wide_specifiers)
+elseif(MINGW)
+  if (LIBCXX_USE_COMPILER_RT)
+set(MINGW_RUNTIME ${LIBCXX_BUILTINS_LIBRARY})
+  else ()
+set(MINGW_RUNTIME gcc_s gcc)
+  endif()
+  add_library_flags(mingw32)
+  add_library_flags(${MINGW_RUNTIME})
+  add_library_flags(moldname)
+  add_library_flags(mingwex)
+  add_library_flags(msvcrt)
+  add_library_flags(advapi32)
+  add_library_flags(shell32)
+  add_library_flags(user32)
+  add_library_flags(kernel32)
+  add_library_flags(mingw32)
+  add_library_flags(${MINGW_RUNTIME})
+  add_library_flags(moldname)
+  add_library_flags(mingwex)
+  add_library_flags(msvcrt)
 endif()
 
 if (LIBCXX_OSX_REEXPORT_SYSTEM_ABI_LIBRARY)


Index: lib/CMakeLists.txt
===
--- lib/CMakeLists.txt
+++ lib/CMakeLists.txt
@@ -126,6 +126,26 @@
   # Required for standards-complaint wide character formatting functions
   # (e.g. `printfw`/`scanfw`)
   add_library_flags(iso_stdio_wide_specifiers)
+elseif(MINGW)
+  if (LIBCXX_USE_COMPILER_RT)
+set(MINGW_RUNTIME ${LIBCXX_BUILTINS_LIBRARY})
+  else ()
+set(MINGW_RUNTIME gcc_s gcc)
+  endif()
+  add_library_flags(mingw32)
+  add_library_flags(${MINGW_RUNTIME})
+  add_library_flags(moldname)
+  add_library_flags(mingwex)
+  add_library_flags(msvcrt)
+  add_library_flags(advapi32)
+  add_library_flags(shell32)
+  add_library_flags(user32)
+  add_library_flags(kernel32)
+  add_library_flags(mingw32)
+  add_library_flags(${MINGW_RUNTIME})
+  add_library_flags(moldname)
+  add_library_flags(mingwex)
+  add_library_flags(msvcrt)
 endif()
 
 if (LIBCXX_OSX_REEXPORT_SYSTEM_ABI_LIBRARY)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D80425: Fix LLVM/Clang builds with mingw toolchain

[Mateusz Mikuła via Phabricator via cfe-commits]

mati865 added inline comments.



Comment at: clang/tools/libclang/CMakeLists.txt:71
+  list(APPEND LIBS ${CMAKE_DL_LIBS})
 endif()
 

thieta wrote:
> mstorsjo wrote:
> > If you say this is the same way it's done elsewhere, then sure - although I 
> > have no idea about what the issue is, why I haven't run into it, etc. 
> > Normally you wouldn't have a `libdl` on mingw right? What's the concrete 
> > issue you're running into, and in which conditions would one run into it?
> The problem here is that on my system `find_library()` picks up libdl in 
> `/usr/lib` and then tries to link to it and gives me an error about it. 
> `HAVE_LIBDL` comes from `config-ix.cmake` where it's checked if we are on 
> windows or not: 
> https://github.com/llvm/llvm-project/blob/216833b32befd14079130a3b857906f4e301179c/llvm/cmake/config-ix.cmake#L101
> 
> So this is how other places uses `CMAKE_DL_LIBS` like here: 
> https://github.com/llvm/llvm-project/blob/7aaff8fd2da2812a2b3cbc8a41af29774b10a7d6/llvm/lib/Support/CMakeLists.txt#L13
I also had this issue in MSYS2 but used `-DCMAKE_SYSTEM_IGNORE_PATH=/usr/lib` 
to get around it.
MSYS2 has Cygwin like (so UNIX like) environment in `/usr/` and `/mingw{32,64}` 
for Mingw-w64.



Comment at: llvm/cmake/modules/HandleLLVMOptions.cmake:967
CMAKE_EXE_LINKER_FLAGS CMAKE_SHARED_LINKER_FLAGS)
-  elseif(LINKER_IS_LLD_LINK)
+  elseif(LINKER_IS_LLD_LINK AND NOT MINGW)
 append("/lldltocache:${PROJECT_BINARY_DIR}/lto.cache"

thieta wrote:
> mstorsjo wrote:
> > Do you happen to know why `LINKER_IS_LLD_LINK` gets set in this case? 
> > `ld.lld` (the ELF linker interface, which then the MinGW driver remaps onto 
> > the COFF backend with the `lld-link` interface) certainly doesn't take 
> > `lld-link` style options. I believe (without diving further into it) that 
> > we shouldn't be setting this flag in this combination, but with the option 
> > implemented, we should fit it into the case further above, `elseif((UNIX OR 
> > MINGW) AND LLVM_USE_LINKER STREQUAL "lld")`
> Yeah I bet that variable is set because I pass `LLVM_USE_LINKER=lld` but I 
> haven't digged to deeply. I can rework the if statement here when we have the 
> lld option in there.
> Yeah I bet that variable is set because I pass LLVM_USE_LINKER=lld but I 
> haven't digged to deeply. 

It does use `lld-link` when you use `LLVM_USE_LINKER=lld`.

The problem lies in this line:
```
append("/lldltocache:${PROJECT_BINARY_DIR}/lto.cache"
```
For MinGW that should read:
```
append("-Wl,/lldltocache:${PROJECT_BINARY_DIR}/lto.cache"
```
That's because you are passing this flag to GCC/Clang.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D80425/new/

https://reviews.llvm.org/D80425



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D80425: Fix LLVM/Clang builds with mingw toolchain

[Mateusz Mikuła via Phabricator via cfe-commits]

mati865 added inline comments.



Comment at: llvm/cmake/modules/HandleLLVMOptions.cmake:967
CMAKE_EXE_LINKER_FLAGS CMAKE_SHARED_LINKER_FLAGS)
-  elseif(LINKER_IS_LLD_LINK)
+  elseif(LINKER_IS_LLD_LINK AND NOT MINGW)
 append("/lldltocache:${PROJECT_BINARY_DIR}/lto.cache"

mstorsjo wrote:
> mati865 wrote:
> > thieta wrote:
> > > mstorsjo wrote:
> > > > Do you happen to know why `LINKER_IS_LLD_LINK` gets set in this case? 
> > > > `ld.lld` (the ELF linker interface, which then the MinGW driver remaps 
> > > > onto the COFF backend with the `lld-link` interface) certainly doesn't 
> > > > take `lld-link` style options. I believe (without diving further into 
> > > > it) that we shouldn't be setting this flag in this combination, but 
> > > > with the option implemented, we should fit it into the case further 
> > > > above, `elseif((UNIX OR MINGW) AND LLVM_USE_LINKER STREQUAL "lld")`
> > > Yeah I bet that variable is set because I pass `LLVM_USE_LINKER=lld` but 
> > > I haven't digged to deeply. I can rework the if statement here when we 
> > > have the lld option in there.
> > > Yeah I bet that variable is set because I pass LLVM_USE_LINKER=lld but I 
> > > haven't digged to deeply. 
> > 
> > It does use `lld-link` when you use `LLVM_USE_LINKER=lld`.
> > 
> > The problem lies in this line:
> > ```
> > append("/lldltocache:${PROJECT_BINARY_DIR}/lto.cache"
> > ```
> > For MinGW that should read:
> > ```
> > append("-Wl,/lldltocache:${PROJECT_BINARY_DIR}/lto.cache"
> > ```
> > That's because you are passing this flag to GCC/Clang.
> > For MinGW that should read:
> > 
> > append("-Wl,/lldltocache:${PROJECT_BINARY_DIR}/lto.cache"
> 
> We're adding this option properly in the mingw frontend, so we shouldn't do 
> the hacky way of passing lld-link options via the mingw frontend by passing 
> them as `/option`.
> 
> And the reason `LINKER_IS_LLD_LINK` is set seems to be this:
> 
> ```
> if(CMAKE_LINKER MATCHES "lld-link" OR (WIN32 AND LLVM_USE_LINKER STREQUAL 
> "lld") OR LLVM_ENABLE_LLD)
> ```
> 
> Perhaps that should be changed into
> 
> ```
> if(CMAKE_LINKER MATCHES "lld-link" OR (WIN32 AND LLVM_USE_LINKER STREQUAL 
> "lld" AND NOT MINGW) OR LLVM_ENABLE_LLD)
> ```
> 
> We're adding this option properly in the mingw frontend, so we shouldn't do 
> the hacky way of passing lld-link options via the mingw frontend by passing 
> them as /option.

I was about to add that and one more LTO related option but thought "what if 
LLVM should link with lld-link on MinGW?" and eventually forgot about it.



> And the reason LINKER_IS_LLD_LINK is set seems to be this:
> ```
> if(CMAKE_LINKER MATCHES "lld-link" OR (WIN32 AND LLVM_USE_LINKER STREQUAL 
> "lld") OR LLVM_ENABLE_LLD)
> ```
> Perhaps that should be changed into
> ```
> if(CMAKE_LINKER MATCHES "lld-link" OR (WIN32 AND LLVM_USE_LINKER STREQUAL 
> "lld" AND NOT MINGW) OR LLVM_ENABLE_LLD)
> ```

It won't work if somebody uses `LLVM_ENABLE_LLD=ON` instead of 
`LLVM_USE_LINKER=lld` which is supposed to be equivalent.
That raises question how `LLVM_ENABLE_LLD=ON` does even work on UNIX platforms.

IMO this would be better:
```
if(CMAKE_LINKER MATCHES "lld-link" OR MSVC AND (LLVM_USE_LINKER STREQUAL "lld" 
OR LLVM_ENABLE_LLD))
```


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D80425/new/

https://reviews.llvm.org/D80425



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D80425: Fix LLVM/Clang builds with mingw toolchain

[Mateusz Mikuła via Phabricator via cfe-commits]

mati865 added inline comments.



Comment at: llvm/cmake/modules/HandleLLVMOptions.cmake:967
CMAKE_EXE_LINKER_FLAGS CMAKE_SHARED_LINKER_FLAGS)
-  elseif(LINKER_IS_LLD_LINK)
+  elseif(LINKER_IS_LLD_LINK AND NOT MINGW)
 append("/lldltocache:${PROJECT_BINARY_DIR}/lto.cache"

mstorsjo wrote:
> mati865 wrote:
> > mstorsjo wrote:
> > > mati865 wrote:
> > > > thieta wrote:
> > > > > mstorsjo wrote:
> > > > > > Do you happen to know why `LINKER_IS_LLD_LINK` gets set in this 
> > > > > > case? `ld.lld` (the ELF linker interface, which then the MinGW 
> > > > > > driver remaps onto the COFF backend with the `lld-link` interface) 
> > > > > > certainly doesn't take `lld-link` style options. I believe (without 
> > > > > > diving further into it) that we shouldn't be setting this flag in 
> > > > > > this combination, but with the option implemented, we should fit it 
> > > > > > into the case further above, `elseif((UNIX OR MINGW) AND 
> > > > > > LLVM_USE_LINKER STREQUAL "lld")`
> > > > > Yeah I bet that variable is set because I pass `LLVM_USE_LINKER=lld` 
> > > > > but I haven't digged to deeply. I can rework the if statement here 
> > > > > when we have the lld option in there.
> > > > > Yeah I bet that variable is set because I pass LLVM_USE_LINKER=lld 
> > > > > but I haven't digged to deeply. 
> > > > 
> > > > It does use `lld-link` when you use `LLVM_USE_LINKER=lld`.
> > > > 
> > > > The problem lies in this line:
> > > > ```
> > > > append("/lldltocache:${PROJECT_BINARY_DIR}/lto.cache"
> > > > ```
> > > > For MinGW that should read:
> > > > ```
> > > > append("-Wl,/lldltocache:${PROJECT_BINARY_DIR}/lto.cache"
> > > > ```
> > > > That's because you are passing this flag to GCC/Clang.
> > > > For MinGW that should read:
> > > > 
> > > > append("-Wl,/lldltocache:${PROJECT_BINARY_DIR}/lto.cache"
> > > 
> > > We're adding this option properly in the mingw frontend, so we shouldn't 
> > > do the hacky way of passing lld-link options via the mingw frontend by 
> > > passing them as `/option`.
> > > 
> > > And the reason `LINKER_IS_LLD_LINK` is set seems to be this:
> > > 
> > > ```
> > > if(CMAKE_LINKER MATCHES "lld-link" OR (WIN32 AND LLVM_USE_LINKER STREQUAL 
> > > "lld") OR LLVM_ENABLE_LLD)
> > > ```
> > > 
> > > Perhaps that should be changed into
> > > 
> > > ```
> > > if(CMAKE_LINKER MATCHES "lld-link" OR (WIN32 AND LLVM_USE_LINKER STREQUAL 
> > > "lld" AND NOT MINGW) OR LLVM_ENABLE_LLD)
> > > ```
> > > 
> > > We're adding this option properly in the mingw frontend, so we shouldn't 
> > > do the hacky way of passing lld-link options via the mingw frontend by 
> > > passing them as /option.
> > 
> > I was about to add that and one more LTO related option but thought "what 
> > if LLVM should link with lld-link on MinGW?" and eventually forgot about it.
> > 
> > 
> > 
> > > And the reason LINKER_IS_LLD_LINK is set seems to be this:
> > > ```
> > > if(CMAKE_LINKER MATCHES "lld-link" OR (WIN32 AND LLVM_USE_LINKER STREQUAL 
> > > "lld") OR LLVM_ENABLE_LLD)
> > > ```
> > > Perhaps that should be changed into
> > > ```
> > > if(CMAKE_LINKER MATCHES "lld-link" OR (WIN32 AND LLVM_USE_LINKER STREQUAL 
> > > "lld" AND NOT MINGW) OR LLVM_ENABLE_LLD)
> > > ```
> > 
> > It won't work if somebody uses `LLVM_ENABLE_LLD=ON` instead of 
> > `LLVM_USE_LINKER=lld` which is supposed to be equivalent.
> > That raises question how `LLVM_ENABLE_LLD=ON` does even work on UNIX 
> > platforms.
> > 
> > IMO this would be better:
> > ```
> > if(CMAKE_LINKER MATCHES "lld-link" OR MSVC AND (LLVM_USE_LINKER STREQUAL 
> > "lld" OR LLVM_ENABLE_LLD))
> > ```
> > I was about to add that and one more LTO related option but thought "what 
> > if LLVM should link with lld-link on MinGW?" and eventually forgot about it.
> 
> I don't think that really is a supposedly supported setup - lld-link wouldn't 
> find any libs to link against etc, as the compiler driver is supposed to pass 
> those as `-L` options in mingw/unix style tools.
> 
> > It won't work if somebody uses LLVM_ENABLE_LLD=ON instead of 
> > LLVM_USE_LINKER=lld which is supposed to be equivalent.
> > That raises question how LLVM_ENABLE_LLD=ON does even work on UNIX 
> > platforms.
> 
> Either it doesn't work and nobody actually use it that way, or the effects of 
> `LINKER_IS_LLD_LINK` are mostly harmless.
> 
> > IMO this would be better:
> > 
> > `if(CMAKE_LINKER MATCHES "lld-link" OR MSVC AND (LLVM_USE_LINKER STREQUAL 
> > "lld" OR LLVM_ENABLE_LLD))`
> 
> Yeah, that looks sensible.
> I don't think that really is a supposedly supported setup - lld-link wouldn't 
> find any libs to link against etc, as the compiler driver is supposed to pass 
> those as -L options in mingw/unix style tools.

Well, it worked both ways (`lld-link` and `ld.lld`) with slight changes to 
CMake files when using your toolchain ;)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D80425/new/

https://reviews.llvm.or

[PATCH] D79995: [clang] [MinGW] Fix libunwind extension

[Mateusz Mikuła via Phabricator via cfe-commits]

mati865 added a comment.

@mstorsjo @rnk will away since June


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D79995/new/

https://reviews.llvm.org/D79995



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D79995: [clang] [MinGW] Fix libunwind extension

[Mateusz Mikuła via Phabricator via cfe-commits]

mati865 updated this revision to Diff 267034.
mati865 added a comment.

Added test.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D79995/new/

https://reviews.llvm.org/D79995

Files:
  clang/lib/Driver/ToolChains/CommonArgs.cpp
  clang/test/Driver/compiler-rt-unwind.c


Index: clang/test/Driver/compiler-rt-unwind.c
===
--- clang/test/Driver/compiler-rt-unwind.c
+++ clang/test/Driver/compiler-rt-unwind.c
@@ -48,3 +48,26 @@
 // RUN: --gcc-toolchain="" \
 // RUN: FileCheck --input-file=%t.err 
--check-prefix=RTLIB-GCC-UNWINDLIB-COMPILER_RT %s
 // RTLIB-GCC-UNWINDLIB-COMPILER_RT: "{{[.|\\\n]*}}--rtlib=libgcc requires 
--unwindlib=libgcc"
+//
+// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
+// RUN: --target=x86_64-w64-mingw32 -rtlib=compiler-rt 
--unwindlib=libunwind \
+// RUN: -shared-libgcc \
+// RUN: --gcc-toolchain="" \
+// RUN:   | FileCheck --check-prefix=RTLIB-COMPILER-RT-SHARED-UNWINDLIB-MINGW 
%s
+// RTLIB-COMPILER-RT-SHARED-UNWINDLIB-MINGW: 
"{{.*}}libclang_rt.builtins-x86_64.a"
+// RTLIB-COMPILER-RT-SHARED-UNWINDLIB-MINGW: "{{.*}}l:libunwind.dll.a"
+//
+// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
+// RUN: --target=x86_64-w64-mingw32 -rtlib=compiler-rt 
--unwindlib=libunwind \
+// RUN: -static-libgcc \
+// RUN: --gcc-toolchain="" \
+// RUN:   | FileCheck --check-prefix=RTLIB-COMPILER-RT-STATIC-UNWINDLIB-MINGW 
%s
+// RTLIB-COMPILER-RT-STATIC-UNWINDLIB-MINGW: 
"{{.*}}libclang_rt.builtins-x86_64.a"
+// RTLIB-COMPILER-RT-STATIC-UNWINDLIB-MINGW: "{{.*}}l:libunwind.a"
+//
+// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
+// RUN: --target=x86_64-w64-mingw32 -rtlib=compiler-rt 
--unwindlib=libunwind \
+// RUN: --gcc-toolchain="" \
+// RUN:   | FileCheck --check-prefix=RTLIB-COMPILER-RT-UNWINDLIB-MINGW %s
+// RTLIB-COMPILER-RT-UNWINDLIB-MINGW: "{{.*}}libclang_rt.builtins-x86_64.a"
+// RTLIB-COMPILER-RT-UNWINDLIB-MINGW: "{{.*}}lunwind"
Index: clang/lib/Driver/ToolChains/CommonArgs.cpp
===
--- clang/lib/Driver/ToolChains/CommonArgs.cpp
+++ clang/lib/Driver/ToolChains/CommonArgs.cpp
@@ -1234,7 +1234,14 @@
   case ToolChain::UNW_CompilerRT:
 if (LGT == LibGccType::StaticLibGcc)
   CmdArgs.push_back("-l:libunwind.a");
-else
+else if (TC.getTriple().isOSCygMing()) {
+  if (LGT == LibGccType::SharedLibGcc)
+CmdArgs.push_back("-l:libunwind.dll.a");
+  else
+// Let the linker choose between libunwind.dll.a and libunwind.a
+// depending on what's available, and depending on the -static flag
+CmdArgs.push_back("-lunwind");
+} else
   CmdArgs.push_back("-l:libunwind.so");
 break;
   }


Index: clang/test/Driver/compiler-rt-unwind.c
===
--- clang/test/Driver/compiler-rt-unwind.c
+++ clang/test/Driver/compiler-rt-unwind.c
@@ -48,3 +48,26 @@
 // RUN: --gcc-toolchain="" \
 // RUN: FileCheck --input-file=%t.err --check-prefix=RTLIB-GCC-UNWINDLIB-COMPILER_RT %s
 // RTLIB-GCC-UNWINDLIB-COMPILER_RT: "{{[.|\\\n]*}}--rtlib=libgcc requires --unwindlib=libgcc"
+//
+// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
+// RUN: --target=x86_64-w64-mingw32 -rtlib=compiler-rt --unwindlib=libunwind \
+// RUN: -shared-libgcc \
+// RUN: --gcc-toolchain="" \
+// RUN:   | FileCheck --check-prefix=RTLIB-COMPILER-RT-SHARED-UNWINDLIB-MINGW %s
+// RTLIB-COMPILER-RT-SHARED-UNWINDLIB-MINGW: "{{.*}}libclang_rt.builtins-x86_64.a"
+// RTLIB-COMPILER-RT-SHARED-UNWINDLIB-MINGW: "{{.*}}l:libunwind.dll.a"
+//
+// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
+// RUN: --target=x86_64-w64-mingw32 -rtlib=compiler-rt --unwindlib=libunwind \
+// RUN: -static-libgcc \
+// RUN: --gcc-toolchain="" \
+// RUN:   | FileCheck --check-prefix=RTLIB-COMPILER-RT-STATIC-UNWINDLIB-MINGW %s
+// RTLIB-COMPILER-RT-STATIC-UNWINDLIB-MINGW: "{{.*}}libclang_rt.builtins-x86_64.a"
+// RTLIB-COMPILER-RT-STATIC-UNWINDLIB-MINGW: "{{.*}}l:libunwind.a"
+//
+// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
+// RUN: --target=x86_64-w64-mingw32 -rtlib=compiler-rt --unwindlib=libunwind \
+// RUN: --gcc-toolchain="" \
+// RUN:   | FileCheck --check-prefix=RTLIB-COMPILER-RT-UNWINDLIB-MINGW %s
+// RTLIB-COMPILER-RT-UNWINDLIB-MINGW: "{{.*}}libclang_rt.builtins-x86_64.a"
+// RTLIB-COMPILER-RT-UNWINDLIB-MINGW: "{{.*}}lunwind"
Index: clang/lib/Driver/ToolChains/CommonArgs.cpp
===
--- clang/lib/Driver/ToolChains/CommonArgs.cpp
+++ clang/lib/Driver/ToolChains/CommonArgs.cpp
@@ -1234,7 +1234,14 @@
   case ToolChain::UNW_CompilerRT:
 if (LGT == LibGccType::StaticLibGcc)
   CmdArgs.push_back("-l:libunwind.a");
-else
+else if (TC.getTriple().isOSCygMing()) {
+  if (LGT == LibGccType::SharedLibGcc)
+CmdA

[PATCH] D79995: [clang] [MinGW] Fix libunwind extension

[Mateusz Mikuła via Phabricator via cfe-commits]

mati865 updated this revision to Diff 267036.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D79995/new/

https://reviews.llvm.org/D79995

Files:
  clang/lib/Driver/ToolChains/CommonArgs.cpp
  clang/test/Driver/compiler-rt-unwind.c


Index: clang/test/Driver/compiler-rt-unwind.c
===
--- clang/test/Driver/compiler-rt-unwind.c
+++ clang/test/Driver/compiler-rt-unwind.c
@@ -48,3 +48,26 @@
 // RUN: --gcc-toolchain="" \
 // RUN: FileCheck --input-file=%t.err 
--check-prefix=RTLIB-GCC-UNWINDLIB-COMPILER_RT %s
 // RTLIB-GCC-UNWINDLIB-COMPILER_RT: "{{[.|\\\n]*}}--rtlib=libgcc requires 
--unwindlib=libgcc"
+//
+// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
+// RUN: --target=x86_64-w64-mingw32 -rtlib=compiler-rt 
--unwindlib=libunwind \
+// RUN: -shared-libgcc \
+// RUN: --gcc-toolchain="" \
+// RUN:   | FileCheck 
--check-prefix=MINGW-RTLIB-COMPILER-RT-SHARED-UNWINDLIB-COMPILER-RT %s
+// MINGW-RTLIB-COMPILER-RT-SHARED-UNWINDLIB-COMPILER-RT: 
"{{.*}}libclang_rt.builtins-x86_64.a"
+// MINGW-RTLIB-COMPILER-RT-SHARED-UNWINDLIB-COMPILER-RT: 
"{{.*}}l:libunwind.dll.a"
+//
+// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
+// RUN: --target=x86_64-w64-mingw32 -rtlib=compiler-rt 
--unwindlib=libunwind \
+// RUN: -static-libgcc \
+// RUN: --gcc-toolchain="" \
+// RUN:   | FileCheck 
--check-prefix=MINGW-RTLIB-COMPILER-RT-STATIC-UNWINDLIB-COMPILER-RT %s
+// MINGW-RTLIB-COMPILER-RT-STATIC-UNWINDLIB-COMPILER-RT: 
"{{.*}}libclang_rt.builtins-x86_64.a"
+// MINGW-RTLIB-COMPILER-RT-STATIC-UNWINDLIB-COMPILER-RT: "{{.*}}l:libunwind.a"
+//
+// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
+// RUN: --target=x86_64-w64-mingw32 -rtlib=compiler-rt 
--unwindlib=libunwind \
+// RUN: --gcc-toolchain="" \
+// RUN:   | FileCheck 
--check-prefix=MINGW-RTLIB-COMPILER-RT-UNWINDLIB-COMPILER-RT %s
+// MINGW-RTLIB-COMPILER-RT-UNWINDLIB-COMPILER-RT: 
"{{.*}}libclang_rt.builtins-x86_64.a"
+// MINGW-RTLIB-COMPILER-RT-UNWINDLIB-COMPILER-RT: "{{.*}}lunwind"
Index: clang/lib/Driver/ToolChains/CommonArgs.cpp
===
--- clang/lib/Driver/ToolChains/CommonArgs.cpp
+++ clang/lib/Driver/ToolChains/CommonArgs.cpp
@@ -1234,7 +1234,14 @@
   case ToolChain::UNW_CompilerRT:
 if (LGT == LibGccType::StaticLibGcc)
   CmdArgs.push_back("-l:libunwind.a");
-else
+else if (TC.getTriple().isOSCygMing()) {
+  if (LGT == LibGccType::SharedLibGcc)
+CmdArgs.push_back("-l:libunwind.dll.a");
+  else
+// Let the linker choose between libunwind.dll.a and libunwind.a
+// depending on what's available, and depending on the -static flag
+CmdArgs.push_back("-lunwind");
+} else
   CmdArgs.push_back("-l:libunwind.so");
 break;
   }


Index: clang/test/Driver/compiler-rt-unwind.c
===
--- clang/test/Driver/compiler-rt-unwind.c
+++ clang/test/Driver/compiler-rt-unwind.c
@@ -48,3 +48,26 @@
 // RUN: --gcc-toolchain="" \
 // RUN: FileCheck --input-file=%t.err --check-prefix=RTLIB-GCC-UNWINDLIB-COMPILER_RT %s
 // RTLIB-GCC-UNWINDLIB-COMPILER_RT: "{{[.|\\\n]*}}--rtlib=libgcc requires --unwindlib=libgcc"
+//
+// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
+// RUN: --target=x86_64-w64-mingw32 -rtlib=compiler-rt --unwindlib=libunwind \
+// RUN: -shared-libgcc \
+// RUN: --gcc-toolchain="" \
+// RUN:   | FileCheck --check-prefix=MINGW-RTLIB-COMPILER-RT-SHARED-UNWINDLIB-COMPILER-RT %s
+// MINGW-RTLIB-COMPILER-RT-SHARED-UNWINDLIB-COMPILER-RT: "{{.*}}libclang_rt.builtins-x86_64.a"
+// MINGW-RTLIB-COMPILER-RT-SHARED-UNWINDLIB-COMPILER-RT: "{{.*}}l:libunwind.dll.a"
+//
+// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
+// RUN: --target=x86_64-w64-mingw32 -rtlib=compiler-rt --unwindlib=libunwind \
+// RUN: -static-libgcc \
+// RUN: --gcc-toolchain="" \
+// RUN:   | FileCheck --check-prefix=MINGW-RTLIB-COMPILER-RT-STATIC-UNWINDLIB-COMPILER-RT %s
+// MINGW-RTLIB-COMPILER-RT-STATIC-UNWINDLIB-COMPILER-RT: "{{.*}}libclang_rt.builtins-x86_64.a"
+// MINGW-RTLIB-COMPILER-RT-STATIC-UNWINDLIB-COMPILER-RT: "{{.*}}l:libunwind.a"
+//
+// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
+// RUN: --target=x86_64-w64-mingw32 -rtlib=compiler-rt --unwindlib=libunwind \
+// RUN: --gcc-toolchain="" \
+// RUN:   | FileCheck --check-prefix=MINGW-RTLIB-COMPILER-RT-UNWINDLIB-COMPILER-RT %s
+// MINGW-RTLIB-COMPILER-RT-UNWINDLIB-COMPILER-RT: "{{.*}}libclang_rt.builtins-x86_64.a"
+// MINGW-RTLIB-COMPILER-RT-UNWINDLIB-COMPILER-RT: "{{.*}}lunwind"
Index: clang/lib/Driver/ToolChains/CommonArgs.cpp
===
--- clang/lib/Driver/ToolChains/CommonArgs.cpp
+++ clang/lib/Driver/ToolChains/CommonArgs.cpp
@@ -1234,7 +1234,14 @@
   case ToolChain::UNW_CompilerRT:
 if (LGT == Lib

[PATCH] D79995: [clang] [MinGW] Fix libunwind extension

[Mateusz Mikuła via Phabricator via cfe-commits]

mati865 added a comment.

No worries.
Mateusz Mikuła 


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D79995/new/

https://reviews.llvm.org/D79995



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D80880: [clang] [MinGW] Link kernel32 once after the last instance of msvcrt

[Mateusz Mikuła via Phabricator via cfe-commits]

mati865 added a comment.

Wouldn't it better fit in `AddLibGCC`?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D80880/new/

https://reviews.llvm.org/D80880



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D80880: [clang] [MinGW] Link kernel32 once after the last instance of msvcrt

[Mateusz Mikuła via Phabricator via cfe-commits]

mati865 accepted this revision.
mati865 added a comment.
This revision is now accepted and ready to land.

I don't know why `AddLibGCC` has to be called twice but that doesn't really 
matter for this diff.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D80880/new/

https://reviews.llvm.org/D80880



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D80880: [clang] [MinGW] Link kernel32 once after the last instance of msvcrt

[Mateusz Mikuła via Phabricator via cfe-commits]

mati865 added a comment.

Thanks, sounds good.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D80880/new/

https://reviews.llvm.org/D80880



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D80876: [clang] Default to windows response files when running on windows

[Mateusz Mikuła via Phabricator via cfe-commits]

mati865 added a comment.

I don't have strong opinion here as I don't know this topic well (things just 
worked so far).
That said if Clang stops working as a drop-in replacement for GCC with commonly 
used build systems, MSYS2 will have to carry one more patch to bring back old 
behaviour.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D80876/new/

https://reviews.llvm.org/D80876



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D79995: [clang] [MinGW] Fix libunwind extension

[Mateusz Mikuła via Phabricator via cfe-commits]

mati865 updated this revision to Diff 264292.
mati865 added a comment.

Applied review comment and formatted.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D79995/new/

https://reviews.llvm.org/D79995

Files:
  clang/lib/Driver/ToolChains/CommonArgs.cpp


Index: clang/lib/Driver/ToolChains/CommonArgs.cpp
===
--- clang/lib/Driver/ToolChains/CommonArgs.cpp
+++ clang/lib/Driver/ToolChains/CommonArgs.cpp
@@ -1234,7 +1234,14 @@
   case ToolChain::UNW_CompilerRT:
 if (LGT == LibGccType::StaticLibGcc)
   CmdArgs.push_back("-l:libunwind.a");
-else
+else if (TC.getTriple().isOSCygMing()) {
+  if (LGT == LibGccType::SharedLibGcc)
+CmdArgs.push_back("-l:libunwind.dll.a");
+  else
+// Let the linker choose between libunwind.dll.a and libunwind.a
+// depending on what's available, and depending on the -static flag
+CmdArgs.push_back("-lunwind");
+} else
   CmdArgs.push_back("-l:libunwind.so");
 break;
   }


Index: clang/lib/Driver/ToolChains/CommonArgs.cpp
===
--- clang/lib/Driver/ToolChains/CommonArgs.cpp
+++ clang/lib/Driver/ToolChains/CommonArgs.cpp
@@ -1234,7 +1234,14 @@
   case ToolChain::UNW_CompilerRT:
 if (LGT == LibGccType::StaticLibGcc)
   CmdArgs.push_back("-l:libunwind.a");
-else
+else if (TC.getTriple().isOSCygMing()) {
+  if (LGT == LibGccType::SharedLibGcc)
+CmdArgs.push_back("-l:libunwind.dll.a");
+  else
+// Let the linker choose between libunwind.dll.a and libunwind.a
+// depending on what's available, and depending on the -static flag
+CmdArgs.push_back("-lunwind");
+} else
   CmdArgs.push_back("-l:libunwind.so");
 break;
   }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D119326: [clang] [MinGW] Default to DWARF 4

[Mateusz Mikuła via Phabricator via cfe-commits]

mati865 accepted this revision.
mati865 added a comment.
This revision is now accepted and ready to land.

LGTM


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D119326/new/

https://reviews.llvm.org/D119326

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D87517: [MinGW] Use lib prefix for libraries

[Mateusz Mikuła via Phabricator via cfe-commits]

mati865 created this revision.
mati865 added a reviewer: LLVM.
mati865 added projects: LLVM, clang, LLDB.
Herald added subscribers: llvm-commits, lldb-commits, cfe-commits, 
JDevlieghere, mgorny.
mati865 requested review of this revision.

In MinGW world, UNIX like `lib` prefix is preferred. This patch adjusts CMake 
files to do that.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D87517

Files:
  clang/tools/libclang/CMakeLists.txt
  lldb/source/API/CMakeLists.txt
  llvm/cmake/modules/AddLLVM.cmake


Index: llvm/cmake/modules/AddLLVM.cmake
===
--- llvm/cmake/modules/AddLLVM.cmake
+++ llvm/cmake/modules/AddLLVM.cmake
@@ -567,7 +567,7 @@
   endif()
 
   if(ARG_SHARED)
-if(WIN32)
+if(MSVC)
   set_target_properties(${name} PROPERTIES
 PREFIX ""
 )
Index: lldb/source/API/CMakeLists.txt
===
--- lldb/source/API/CMakeLists.txt
+++ lldb/source/API/CMakeLists.txt
@@ -182,10 +182,10 @@
   set_target_properties(liblldb_exports PROPERTIES FOLDER "lldb misc")
 endif()
 
-if ( CMAKE_SYSTEM_NAME MATCHES "Windows" )
+if (MSVC)
   # Only MSVC has the ABI compatibility problem and avoids using 
FindPythonLibs,
   # so only it needs to explicitly link against ${Python3_LIBRARIES}
-  if (MSVC AND LLDB_ENABLE_PYTHON)
+  if (LLDB_ENABLE_PYTHON)
 target_link_libraries(liblldb PRIVATE ${Python3_LIBRARIES})
   endif()
 else()
Index: clang/tools/libclang/CMakeLists.txt
===
--- clang/tools/libclang/CMakeLists.txt
+++ clang/tools/libclang/CMakeLists.txt
@@ -101,7 +101,7 @@
   unset(ENABLE_STATIC)
 endif()
 
-if(WIN32)
+if(MSVC)
   set(output_name "libclang")
 else()
   set(output_name "clang")
@@ -205,4 +205,3 @@
COMPONENT
  libclang-python-bindings)
 endif()
-


Index: llvm/cmake/modules/AddLLVM.cmake
===
--- llvm/cmake/modules/AddLLVM.cmake
+++ llvm/cmake/modules/AddLLVM.cmake
@@ -567,7 +567,7 @@
   endif()
 
   if(ARG_SHARED)
-if(WIN32)
+if(MSVC)
   set_target_properties(${name} PROPERTIES
 PREFIX ""
 )
Index: lldb/source/API/CMakeLists.txt
===
--- lldb/source/API/CMakeLists.txt
+++ lldb/source/API/CMakeLists.txt
@@ -182,10 +182,10 @@
   set_target_properties(liblldb_exports PROPERTIES FOLDER "lldb misc")
 endif()
 
-if ( CMAKE_SYSTEM_NAME MATCHES "Windows" )
+if (MSVC)
   # Only MSVC has the ABI compatibility problem and avoids using FindPythonLibs,
   # so only it needs to explicitly link against ${Python3_LIBRARIES}
-  if (MSVC AND LLDB_ENABLE_PYTHON)
+  if (LLDB_ENABLE_PYTHON)
 target_link_libraries(liblldb PRIVATE ${Python3_LIBRARIES})
   endif()
 else()
Index: clang/tools/libclang/CMakeLists.txt
===
--- clang/tools/libclang/CMakeLists.txt
+++ clang/tools/libclang/CMakeLists.txt
@@ -101,7 +101,7 @@
   unset(ENABLE_STATIC)
 endif()
 
-if(WIN32)
+if(MSVC)
   set(output_name "libclang")
 else()
   set(output_name "clang")
@@ -205,4 +205,3 @@
COMPONENT
  libclang-python-bindings)
 endif()
-
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D87517: [MinGW] Use lib prefix for libraries

[Mateusz Mikuła via Phabricator via cfe-commits]

mati865 updated this revision to Diff 291224.
mati865 added a comment.

Also adjusted llvm-config.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D87517/new/

https://reviews.llvm.org/D87517

Files:
  clang/tools/libclang/CMakeLists.txt
  lldb/source/API/CMakeLists.txt
  llvm/cmake/modules/AddLLVM.cmake
  llvm/tools/llvm-config/llvm-config.cpp


Index: llvm/tools/llvm-config/llvm-config.cpp
===
--- llvm/tools/llvm-config/llvm-config.cpp
+++ llvm/tools/llvm-config/llvm-config.cpp
@@ -381,6 +381,7 @@
 SharedExt = "dll";
 SharedVersionedExt = LLVM_DYLIB_VERSION ".dll";
 if (HostTriple.isOSCygMing()) {
+  SharedPrefix = "lib";
   StaticExt = "a";
   StaticPrefix = "lib";
 } else {
Index: llvm/cmake/modules/AddLLVM.cmake
===
--- llvm/cmake/modules/AddLLVM.cmake
+++ llvm/cmake/modules/AddLLVM.cmake
@@ -567,7 +567,7 @@
   endif()
 
   if(ARG_SHARED)
-if(WIN32)
+if(MSVC)
   set_target_properties(${name} PROPERTIES
 PREFIX ""
 )
Index: lldb/source/API/CMakeLists.txt
===
--- lldb/source/API/CMakeLists.txt
+++ lldb/source/API/CMakeLists.txt
@@ -182,10 +182,10 @@
   set_target_properties(liblldb_exports PROPERTIES FOLDER "lldb misc")
 endif()
 
-if ( CMAKE_SYSTEM_NAME MATCHES "Windows" )
+if (MSVC)
   # Only MSVC has the ABI compatibility problem and avoids using 
FindPythonLibs,
   # so only it needs to explicitly link against ${Python3_LIBRARIES}
-  if (MSVC AND LLDB_ENABLE_PYTHON)
+  if (LLDB_ENABLE_PYTHON)
 target_link_libraries(liblldb PRIVATE ${Python3_LIBRARIES})
   endif()
 else()
Index: clang/tools/libclang/CMakeLists.txt
===
--- clang/tools/libclang/CMakeLists.txt
+++ clang/tools/libclang/CMakeLists.txt
@@ -101,7 +101,7 @@
   unset(ENABLE_STATIC)
 endif()
 
-if(WIN32)
+if(MSVC)
   set(output_name "libclang")
 else()
   set(output_name "clang")


Index: llvm/tools/llvm-config/llvm-config.cpp
===
--- llvm/tools/llvm-config/llvm-config.cpp
+++ llvm/tools/llvm-config/llvm-config.cpp
@@ -381,6 +381,7 @@
 SharedExt = "dll";
 SharedVersionedExt = LLVM_DYLIB_VERSION ".dll";
 if (HostTriple.isOSCygMing()) {
+  SharedPrefix = "lib";
   StaticExt = "a";
   StaticPrefix = "lib";
 } else {
Index: llvm/cmake/modules/AddLLVM.cmake
===
--- llvm/cmake/modules/AddLLVM.cmake
+++ llvm/cmake/modules/AddLLVM.cmake
@@ -567,7 +567,7 @@
   endif()
 
   if(ARG_SHARED)
-if(WIN32)
+if(MSVC)
   set_target_properties(${name} PROPERTIES
 PREFIX ""
 )
Index: lldb/source/API/CMakeLists.txt
===
--- lldb/source/API/CMakeLists.txt
+++ lldb/source/API/CMakeLists.txt
@@ -182,10 +182,10 @@
   set_target_properties(liblldb_exports PROPERTIES FOLDER "lldb misc")
 endif()
 
-if ( CMAKE_SYSTEM_NAME MATCHES "Windows" )
+if (MSVC)
   # Only MSVC has the ABI compatibility problem and avoids using FindPythonLibs,
   # so only it needs to explicitly link against ${Python3_LIBRARIES}
-  if (MSVC AND LLDB_ENABLE_PYTHON)
+  if (LLDB_ENABLE_PYTHON)
 target_link_libraries(liblldb PRIVATE ${Python3_LIBRARIES})
   endif()
 else()
Index: clang/tools/libclang/CMakeLists.txt
===
--- clang/tools/libclang/CMakeLists.txt
+++ clang/tools/libclang/CMakeLists.txt
@@ -101,7 +101,7 @@
   unset(ENABLE_STATIC)
 endif()
 
-if(WIN32)
+if(MSVC)
   set(output_name "libclang")
 else()
   set(output_name "clang")
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D87539: [MinGW][libclang] Allow simultaneous shared and static lib

[Mateusz Mikuła via Phabricator via cfe-commits]

mati865 created this revision.
mati865 added a reviewer: clang.
mati865 added a project: clang.
Herald added subscribers: cfe-commits, mgorny.
mati865 requested review of this revision.

It builds fine for MinGW on Windows.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D87539

Files:
  clang/tools/libclang/CMakeLists.txt


Index: clang/tools/libclang/CMakeLists.txt
===
--- clang/tools/libclang/CMakeLists.txt
+++ clang/tools/libclang/CMakeLists.txt
@@ -97,7 +97,7 @@
   set(ENABLE_STATIC STATIC)
 endif()
 
-if (WIN32 AND ENABLE_SHARED AND ENABLE_STATIC)
+if (MSVC AND ENABLE_SHARED AND ENABLE_STATIC)
   unset(ENABLE_STATIC)
 endif()
 


Index: clang/tools/libclang/CMakeLists.txt
===
--- clang/tools/libclang/CMakeLists.txt
+++ clang/tools/libclang/CMakeLists.txt
@@ -97,7 +97,7 @@
   set(ENABLE_STATIC STATIC)
 endif()
 
-if (WIN32 AND ENABLE_SHARED AND ENABLE_STATIC)
+if (MSVC AND ENABLE_SHARED AND ENABLE_STATIC)
   unset(ENABLE_STATIC)
 endif()
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D87547: [MinGW][clang-shlib] Build by default on MinGW

[Mateusz Mikuła via Phabricator via cfe-commits]

mati865 created this revision.
mati865 added a reviewer: clang.
mati865 added a project: clang.
Herald added subscribers: cfe-commits, mgorny.
mati865 requested review of this revision.

It builds without errors and makes possible to use `CLANG_LINK_CLANG_DYLIB=1`


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D87547

Files:
  clang/tools/CMakeLists.txt


Index: clang/tools/CMakeLists.txt
===
--- clang/tools/CMakeLists.txt
+++ clang/tools/CMakeLists.txt
@@ -15,7 +15,7 @@
 
 add_clang_subdirectory(clang-rename)
 add_clang_subdirectory(clang-refactor)
-if(UNIX)
+if(UNIX OR MINGW)
   add_clang_subdirectory(clang-shlib)
 endif()
 


Index: clang/tools/CMakeLists.txt
===
--- clang/tools/CMakeLists.txt
+++ clang/tools/CMakeLists.txt
@@ -15,7 +15,7 @@
 
 add_clang_subdirectory(clang-rename)
 add_clang_subdirectory(clang-refactor)
-if(UNIX)
+if(UNIX OR MINGW)
   add_clang_subdirectory(clang-shlib)
 endif()
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D87517: [MinGW] Use lib prefix for libraries

[Mateusz Mikuła via Phabricator via cfe-commits]

mati865 added a comment.

I haven't tried ` BUILD_SHARED_LIBS=TRUE` TBH.

Effects visible at first glance:

  bin/LLVM.dll  -> bin/libLLVM.dll
  bin/LTO.dll -> bin/libLTO.dll
  lib/liblibclang.a  -> lib/libclang.a
  lib/liblibclang.dll.a  -> lib/libclang.a
  lib/libliblldb.dll.a-> lib/liblldb.dll.a

I'll create 2 clean build directories and diff them for more precise info.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D87517/new/

https://reviews.llvm.org/D87517

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D87517: [MinGW] Use lib prefix for libraries

[Mateusz Mikuła via Phabricator via cfe-commits]

mati865 added a comment.

`-DLLVM_ENABLE_PROJECTS="clang;lldb" -DLLVM_BUILD_LLVM_DYLIB=1` with only this 
patch applied (`<` is before, `>` is after):

  $ diff <(cd ../build && find ./ | sort) <(cd ../build2/ && find ./ | sort)
  38a39,41
  > ./bin/libLLVM.dll
  > ./bin/libLTO.dll
  > ./bin/libRemarks.dll
  51d53
  < ./bin/LLVM.dll
  119d120
  < ./bin/LTO.dll
  123d123
  < ./bin/Remarks.dll
  1460a1461
  > ./lib/libclang.dll.a
  1500,1501c1501
  < ./lib/liblibclang.dll.a
  < ./lib/libliblldb.dll.a
  ---
  > ./lib/liblldb.dll.a

`-DLLVM_ENABLE_PROJECTS="clang;lldb" -DBUILD_SHARED_LIBS=1`:

  $ diff <(cd ../build3 && find ./ | sort) <(cd ../build4/ && find ./ | sort)
  18,22d17
  < ./bin/clangAnalysis.dll
  < ./bin/clangARCMigrate.dll
  < ./bin/clangAST.dll
  < ./bin/clangASTMatchers.dll
  < ./bin/clangBasic.dll
  25d19
  < ./bin/clangCodeGen.dll
  27,28d20
  < ./bin/clangCrossTU.dll
  < ./bin/clangDependencyScanning.dll
  30,33d21
  < ./bin/clangDirectoryWatcher.dll
  < ./bin/clangDriver.dll
  < ./bin/clangDynamicASTMatchers.dll
  < ./bin/clangEdit.dll
  35d22
  < ./bin/clangFormat.dll
  37,40d23
  < ./bin/clangFrontend.dll
  < ./bin/clangFrontendTool.dll
  < ./bin/clangHandleCXX.dll
  < ./bin/clangHandleLLVM.dll
  42,44d24
  < ./bin/clangIndex.dll
  < ./bin/clangIndexSerialization.dll
  < ./bin/clangLex.dll
  47d26
  < ./bin/clangParse.dll
  50,51d28
  < ./bin/clangRewrite.dll
  < ./bin/clangRewriteFrontend.dll
  53,57d29
  < ./bin/clangSema.dll
  < ./bin/clangSerialization.dll
  < ./bin/clangStaticAnalyzerCheckers.dll
  < ./bin/clangStaticAnalyzerCore.dll
  < ./bin/clangStaticAnalyzerFrontend.dll
  59,66d30
  < ./bin/clangTesting.dll
  < ./bin/clangTooling.dll
  < ./bin/clangToolingASTDiff.dll
  < ./bin/clangToolingCore.dll
  < ./bin/clangToolingInclusions.dll
  < ./bin/clangToolingRefactoring.dll
  < ./bin/clangToolingSyntax.dll
  < ./bin/clangTransformer.dll
  71,72d34
  < ./bin/gtest.dll
  < ./bin/gtest_main.dll
  77a40,77
  > ./bin/libclangAnalysis.dll
  > ./bin/libclangARCMigrate.dll
  > ./bin/libclangAST.dll
  > ./bin/libclangASTMatchers.dll
  > ./bin/libclangBasic.dll
  > ./bin/libclangCodeGen.dll
  > ./bin/libclangCrossTU.dll
  > ./bin/libclangDependencyScanning.dll
  > ./bin/libclangDirectoryWatcher.dll
  > ./bin/libclangDriver.dll
  > ./bin/libclangDynamicASTMatchers.dll
  > ./bin/libclangEdit.dll
  > ./bin/libclangFormat.dll
  > ./bin/libclangFrontend.dll
  > ./bin/libclangFrontendTool.dll
  > ./bin/libclangHandleCXX.dll
  > ./bin/libclangHandleLLVM.dll
  > ./bin/libclangIndex.dll
  > ./bin/libclangIndexSerialization.dll
  > ./bin/libclangLex.dll
  > ./bin/libclangParse.dll
  > ./bin/libclangRewrite.dll
  > ./bin/libclangRewriteFrontend.dll
  > ./bin/libclangSema.dll
  > ./bin/libclangSerialization.dll
  > ./bin/libclangStaticAnalyzerCheckers.dll
  > ./bin/libclangStaticAnalyzerCore.dll
  > ./bin/libclangStaticAnalyzerFrontend.dll
  > ./bin/libclangTesting.dll
  > ./bin/libclangTooling.dll
  > ./bin/libclangToolingASTDiff.dll
  > ./bin/libclangToolingCore.dll
  > ./bin/libclangToolingInclusions.dll
  > ./bin/libclangToolingRefactoring.dll
  > ./bin/libclangToolingSyntax.dll
  > ./bin/libclangTransformer.dll
  > ./bin/libgtest.dll
  > ./bin/libgtest_main.dll
  78a79,233
  > ./bin/libLLVMAArch64AsmParser.dll
  > ./bin/libLLVMAArch64CodeGen.dll
  > ./bin/libLLVMAArch64Desc.dll
  > ./bin/libLLVMAArch64Disassembler.dll
  > ./bin/libLLVMAArch64Info.dll
  > ./bin/libLLVMAArch64Utils.dll
  > ./bin/libLLVMAggressiveInstCombine.dll
  > ./bin/libLLVMAMDGPUAsmParser.dll
  > ./bin/libLLVMAMDGPUCodeGen.dll
  > ./bin/libLLVMAMDGPUDesc.dll
  > ./bin/libLLVMAMDGPUDisassembler.dll
  > ./bin/libLLVMAMDGPUInfo.dll
  > ./bin/libLLVMAMDGPUUtils.dll
  > ./bin/libLLVMAnalysis.dll
  > ./bin/libLLVMARMAsmParser.dll
  > ./bin/libLLVMARMCodeGen.dll
  > ./bin/libLLVMARMDesc.dll
  > ./bin/libLLVMARMDisassembler.dll
  > ./bin/libLLVMARMInfo.dll
  > ./bin/libLLVMARMUtils.dll
  > ./bin/libLLVMAsmParser.dll
  > ./bin/libLLVMAsmPrinter.dll
  > ./bin/libLLVMAVRAsmParser.dll
  > ./bin/libLLVMAVRCodeGen.dll
  > ./bin/libLLVMAVRDesc.dll
  > ./bin/libLLVMAVRDisassembler.dll
  > ./bin/libLLVMAVRInfo.dll
  > ./bin/libLLVMBinaryFormat.dll
  > ./bin/libLLVMBitReader.dll
  > ./bin/libLLVMBitstreamReader.dll
  > ./bin/libLLVMBitWriter.dll
  > ./bin/libLLVMBPFAsmParser.dll
  > ./bin/libLLVMBPFCodeGen.dll
  > ./bin/libLLVMBPFDesc.dll
  > ./bin/libLLVMBPFDisassembler.dll
  > ./bin/libLLVMBPFInfo.dll
  > ./bin/libLLVMCFGuard.dll
  > ./bin/libLLVMCodeGen.dll
  > ./bin/libLLVMCore.dll
  > ./bin/libLLVMCoroutines.dll
  > ./bin/libLLVMCoverage.dll
  > ./bin/libLLVMDebugInfoCodeView.dll
  > ./bin/libLLVMDebugInfoDWARF.dll
  > ./bin/libLLVMDebugInfoGSYM.dll
  > ./bin/libLLVMDebugInfoMSF.dll
  > ./bin/libLLVMDebugInfoPDB.dll
  > ./bin/libLLVMDemangle.dll
  > ./bin/libLLVMDlltoolDriver.dll
  > ./bin/libLLVMDWARFLinker.dll
  > ./bin/libLLVMExecutionEngine.dll
  > ./bin/libLLVMExtensions.dll
  > ./bin/libLLVMFileCheck.dll
  > ./bin/libLLVMFrontendOpenA

[PATCH] D87539: [MinGW][libclang] Allow simultaneous shared and static lib

[Mateusz Mikuła via Phabricator via cfe-commits]

mati865 added a comment.

We had this patch at MSYS2 for years and I'm not aware of any issues with the 
static library.
I think the library looks fine:

  $ nm lib/liblibclang.a | grep __imp_
   U __imp___acrt_iob_func
   U __imp___acrt_iob_func
   U __imp_GetModuleFileNameA
   U __imp_VirtualQuery
   U __imp___acrt_iob_func
   U __imp___acrt_iob_func
   U __imp___acrt_iob_func


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D87539/new/

https://reviews.llvm.org/D87539

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D87539: [MinGW][libclang] Allow simultaneous shared and static lib

[Mateusz Mikuła via Phabricator via cfe-commits]

mati865 added a comment.

`bin/llvm-readobj --coff-directives lib/liblibclang.dll.a | grep -i export` 
shows nothing.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D87539/new/

https://reviews.llvm.org/D87539

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D87539: [MinGW][libclang] Allow simultaneous shared and static lib

[Mateusz Mikuła via Phabricator via cfe-commits]

mati865 added a comment.

Sorry, pasted wrong command. I was curious if import library has it (since 
static one did not) but in the end neither import nor static library shows any 
`export`.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D87539/new/

https://reviews.llvm.org/D87539

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D87539: [MinGW][libclang] Allow simultaneous shared and static lib

[Mateusz Mikuła via Phabricator via cfe-commits]

mati865 added a comment.

Thanks.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D87539/new/

https://reviews.llvm.org/D87539

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D88005: [clang] [MinGW] Add an implicit .exe suffix even when crosscompiling

[Mateusz Mikuła via Phabricator via cfe-commits]

mati865 added a comment.

LGTM
Confirmed that GCC 9 still adds `.exe`.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88005/new/

https://reviews.llvm.org/D88005

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D86091: [cmake] Fix build of attribute plugin example on Windows

[Mateusz Mikuła via Phabricator via cfe-commits]

mati865 added subscribers: hans, mati865.
mati865 added a comment.

@hans sorry for not spotting it earlier but is it possible to still backport it 
to LLVM 11?
It's totally OK if it's too late. I can easily keep it as a patch in MSYS2 
repository.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D86091/new/

https://reviews.llvm.org/D86091

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D79219: [CMake] Simplify CMake handling for zlib

[Mateusz Mikuła via Phabricator via cfe-commits]

mati865 added a comment.

@phosek in MSYS2 (targeting x86_64-w64-windows-gnu) Zlib works properly for 
LLVM 10 but with master I'm now seeing:

  -- Constructing LLVMBuild project information
  -- DEBUG zlib_library=D:/msys64/mingw64/lib/libz.dll.a
  CMake Error at lib/Support/CMakeLists.txt:9 (string):
string sub-command REGEX, mode REPLACE: regex "^(lib|)" matched an empty
string.
  Call Stack (most recent call first):
lib/Support/CMakeLists.txt:226 (get_system_libname)

`-- DEBUG zlib_library=D:/msys64/mingw64/lib/libz.dll.a` was printed by my 
change to help debugging it.
FYI `zlib_library` is set here: 
https://github.com/llvm/llvm-project/blob/8e06bf6b3a2e8d25e56cd52dca0cf3ff1b37b5d1/llvm/lib/Support/CMakeLists.txt#L218


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D79219/new/

https://reviews.llvm.org/D79219

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D79219: [CMake] Simplify CMake handling for zlib

[Mateusz Mikuła via Phabricator via cfe-commits]

mati865 added a comment.

@phosek

> Looks like that's an issue introduced by D86134 
>  or D86245 .

Indeed, I apologize for bothering you. Should I move the discussion to one of 
patches created by  @haampie?

Continuing the discussion with `if( CMAKE_FIND_LIBRARY_PREFIXES )` and `if( 
CMAKE_FIND_LIBRARY_SUFFIXES )` from https://reviews.llvm.org/D86245 changed to 
false `llvm-config --system-libs` prints `-llibz.dll.a` so we need those 
replaces to bring back correct `-lz` value.

> Can you print the value of ${CMAKE_FIND_LIBRARY_PREFIXES} and 
> ${CMAKE_FIND_LIBRARY_SUFFIXES} in your build?

  -- CMAKE_FIND_LIBRARY_PREFIXES=lib;
  -- CMAKE_FIND_LIBRARY_SUFFIXES=.dll.a;.a;.lib

Which matches 
https://gitlab.kitware.com/cmake/cmake/-/blob/269d1a86249ea037a2884133daffc8c44a38d926/Modules/Platform/Windows-GNU.cmake


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D79219/new/

https://reviews.llvm.org/D79219

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D87547: [MinGW][clang-shlib] Build by default on MinGW

[Mateusz Mikuła via Phabricator via cfe-commits]

mati865 added a comment.

@ASDenysPetrov what CMake options do you use?
I'm unable to reproduce this error with Clang+LLD and GCC+Binutils from MSYS2.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D87547/new/

https://reviews.llvm.org/D87547

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D87547: [MinGW][clang-shlib] Build by default on MinGW

[Mateusz Mikuła via Phabricator via cfe-commits]

mati865 added a comment.

> How many exports does your DLL end up with - is it close to the 64k limit, or 
> far from it? Is there maybe some other library that is linked in, that 
> increases the number of exported symbols (=all), or does this DLL only export 
> explicitly intended symbols with dllexport?

60995 with `cmake -G Ninja -DCMAKE_BUILD_TYPE=Release 
-DCMAKE_SYSTEM_IGNORE_PATH=/usr/lib -DLLVM_ENABLE_PROJECTS="clang;lld" 
../llvm-project/llvm` so it's very close.
Another build where I don't have exact command line but it uses Clang+LLD and 
`LLVM_LINK_LLVM_DYLIB:BOOL=ON` has only 35125 exports.

I'll try to dig a bit soonish (maybe enable clang-shlib only if LLVM is linked 
dynamically?) but you can revert it in meantime.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D87547/new/

https://reviews.llvm.org/D87547

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D87547: [MinGW][clang-shlib] Build by default on MinGW

[Mateusz Mikuła via Phabricator via cfe-commits]

mati865 added a comment.

Reproduced by adding `-DLLVM_ENABLE_ASSERTIONS=ON`.

With `-DLLVM_ENABLE_ASSERTIONS=ON -DLLVM_BUILD_LLVM_DYLIB=ON 
-DLLVM_LINK_LLVM_DYLIB=ON` libLLVM.dll also fails to link.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D87547/new/

https://reviews.llvm.org/D87547

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D87547: [MinGW][clang-shlib] Build by default on MinGW

[Mateusz Mikuła via Phabricator via cfe-commits]

mati865 added a comment.

With `-DLLVM_ENABLE_ASSERTIONS=ON -DCMAKE_C_COMPILER=clang 
-DCMAKE_CXX_COMPILER=clang++ -DCMAKE_RANLIB_COMPILER=llvm-ranlib 
-DCMAKE_AR_COMPILER=llvm-ar -DCMAKE_LINKER=ld.lld -DLLVM_ENABLE_LLD=ON` 
libclang-cpp.dll has 65535 exports, seems it got truncated?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D87547/new/

https://reviews.llvm.org/D87547

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D87547: [MinGW][clang-shlib] Build by default on MinGW

[Mateusz Mikuła via Phabricator via cfe-commits]

mati865 added a comment.

> Older versions of lld didn't error out if exceeding the limit, this is fixed 
> in D86701 , unfortunately after the 11 
> branch.

Thanks, I'll backport it for MSYS2 LLVM 11 package.

> With -DLLVM_ENABLE_ASSERTIONS=ON -DCMAKE_C_COMPILER=clang 
> -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_RANLIB_COMPILER=llvm-ranlib 
> -DCMAKE_AR_COMPILER=llvm-ar -DCMAKE_LINKER=ld.lld -DLLVM_ENABLE_LLD=ON 
> libclang-cpp.dll has 65535 exports, seems it got truncated?

After adding `-DLLVM_BUILD_LLVM_DYLIB=ON` libclang-cpp.dll has 37660 exports, 
libLLVM.dll gets truncated.
Considering my previous findings linking libclang-cpp.dll to libLLVM.dll seems 
to reduce amount of exports to safer 30k-40k range.

Possible solutions:

- revert this diff so I carry downstream MSYS2 patch (easy)
- gate building of libclang-cpp.dll for MinGW on `LLVM_BUILD_LLVM_DYLIB=ON` 
(easy)
- export less symbols from libclang-cpp.dll (probably hard or very hard)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D87547/new/

https://reviews.llvm.org/D87547

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D87547: [MinGW][clang-shlib] Build by default on MinGW

[Mateusz Mikuła via Phabricator via cfe-commits]

mati865 added a comment.

> Or maybe even make it into a cmake option?

I've considered it as default to true for unix and false for others but I'm not 
sure if complicating Clang build options like that is worth it.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D87547/new/

https://reviews.llvm.org/D87547

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D89225: [MinGW][clang-shlib] Build only when LLVM_LINK_LLVM_DYLIB is enabled

[Mateusz Mikuła via Phabricator via cfe-commits]

mati865 created this revision.
mati865 added a reviewer: mstorsjo.
mati865 added a project: clang.
Herald added subscribers: cfe-commits, mgorny.
mati865 requested review of this revision.

Otherwise it's easy to hit 2^16 DLL exports limit.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D89225

Files:
  clang/tools/CMakeLists.txt


Index: clang/tools/CMakeLists.txt
===
--- clang/tools/CMakeLists.txt
+++ clang/tools/CMakeLists.txt
@@ -15,7 +15,9 @@
 
 add_clang_subdirectory(clang-rename)
 add_clang_subdirectory(clang-refactor)
-if(UNIX OR MINGW)
+# For MinGW we only enable shared library if LLVM_LINK_LLVM_DYLIB=ON.
+# Without that option resulting library is too close to 2^16 DLL exports limit.
+if(UNIX OR (MINGW AND LLVM_LINK_LLVM_DYLIB))
   add_clang_subdirectory(clang-shlib)
 endif()
 


Index: clang/tools/CMakeLists.txt
===
--- clang/tools/CMakeLists.txt
+++ clang/tools/CMakeLists.txt
@@ -15,7 +15,9 @@
 
 add_clang_subdirectory(clang-rename)
 add_clang_subdirectory(clang-refactor)
-if(UNIX OR MINGW)
+# For MinGW we only enable shared library if LLVM_LINK_LLVM_DYLIB=ON.
+# Without that option resulting library is too close to 2^16 DLL exports limit.
+if(UNIX OR (MINGW AND LLVM_LINK_LLVM_DYLIB))
   add_clang_subdirectory(clang-shlib)
 endif()
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D87547: [MinGW][clang-shlib] Build by default on MinGW

[Mateusz Mikuła via Phabricator via cfe-commits]

mati865 abandoned this revision.
mati865 added a comment.

Opened https://reviews.llvm.org/D89225


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D87547/new/

https://reviews.llvm.org/D87547

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D102970: [clang] [MinGW] Don't mark emutls variables as DSO local

[Mateusz Mikuła via Phabricator via cfe-commits]

mati865 accepted this revision.
mati865 added a comment.
This revision is now accepted and ready to land.

Wow, I haven't expected that.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D102970/new/

https://reviews.llvm.org/D102970

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D102873: [clang] [MinGW] Fix gcc version detection/picking

[Mateusz Mikuła via Phabricator via cfe-commits]

mati865 added a comment.

Ah, so that explains why everyone sends LGTM text.
I'll try to remember it next time.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D102873/new/

https://reviews.llvm.org/D102873

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D107261: [clang] [MinGW] Let the last of -mconsole/-mwindows have effect

[Mateusz Mikuła via Phabricator via cfe-commits]

mati865 accepted this revision.
mati865 added a comment.
This revision is now accepted and ready to land.

LGTM


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D107261/new/

https://reviews.llvm.org/D107261

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D98023: [clang] Don't make the g++ driver imply an explicitly shared libunwind

[Mateusz Mikuła via Phabricator via cfe-commits]

mati865 added a comment.

It's clear overlook from D79995 , that part is 
perfectly reasonable to me.

I'm a bit worried about this code though:

  bool AsNeeded = LGT == LibGccType::UnspecifiedLibGcc &&
  !TC.getTriple().isAndroid() && !TC.getTriple().isOSCygMing();

https://github.com/llvm/llvm-project/blob/0b274ed499603d30694c0b995252ab014609acf9/clang/lib/Driver/ToolChains/CommonArgs.cpp#L1413
IIUC this change would flip it from `false` to `true` for Linux targets, which 
also sounds fine on it's own but goes beyond this diff description and seems to 
lack any test.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98023/new/

https://reviews.llvm.org/D98023

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D141206: [clang] [MinGW] Avoid adding /include and /lib when cross compiling

[Mateusz Mikuła via Phabricator via cfe-commits]

mati865 added a comment.

I had thought we do that already so this change looks reasonable for me.
Just one thought, do we support multilib toolchains? I think in that case Clang 
would have to add `/include` despite different triple.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D141206/new/

https://reviews.llvm.org/D141206

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D141206: [clang] [MinGW] Avoid adding /include and /lib when cross compiling

[Mateusz Mikuła via Phabricator via cfe-commits]

mati865 added a comment.

In D141206#4034451 , @mstorsjo wrote:

> In D141206#4034159 , @mati865 wrote:
>
>> I had thought we do that already so this change looks reasonable for me.
>> Just one thought, do we support multilib toolchains? I think in that case 
>> Clang would have to add `/include` despite different triple.
>
> This patch actually does that already, see the parameter `RequireArchMatch` 
> which is set to true for the `/lib` case and false for `/include`.

Ah, I have messed up those 2.
I haven't seen multilib mingw-w64 distribution either but just wanted to be 
cautious here to not accidentally regress if there is somebody doing that.
Then I cannot think of any issues this patch could cause.

BTW Looking at Arch Linux 32-bit libs are placed in `/32` but 
this is off-topic.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D141206/new/

https://reviews.llvm.org/D141206

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D141206: [clang] [MinGW] Avoid adding /include and /lib when cross compiling

[Mateusz Mikuła via Phabricator via cfe-commits]

mati865 added a comment.

In D141206#4043375 , @mstorsjo wrote:

> Updated with some testcases. This does test that the include directory is 
> omitted when cross compiling, but those kinds of tests, which set up a 
> simulated toolchain environment with symlinks, don't run on actual Windows - 
> so it's not quite as easy to test the case that we actually do keep the 
> unprefixed include directory on Windows. As this matches the current testing 
> coverage status quo, I hope this is ok...

Personally I don't mind that, it's unlikely to ever get 100% coverage because 
of known limitations.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D141206/new/

https://reviews.llvm.org/D141206

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D141206: [clang] [MinGW] Avoid adding /include and /lib when cross compiling

[Mateusz Mikuła via Phabricator via cfe-commits]

mati865 added a comment.

I cannot speak much about LLVM tests but the code looks good for me.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D141206/new/

https://reviews.llvm.org/D141206

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D61670: [RFC] [MinGW] Allow opting out from .refptr stubs

[Mateusz Mikuła via Phabricator via cfe-commits]

mati865 added a comment.

> If we make the flag imply linker options, then it becomes much clearer to 
> spot the error, if you enabled this but the code base still would need 
> autoimports somewhere. (This has happened - see 
> https://code.videolan.org/videolan/dav1d/-/merge_requests/1303#note_301859, 
> https://code.videolan.org/videolan/dav1d/-/merge_requests/1349 and 
> https://code.videolan.org/videolan/dav1d/-/merge_requests/1361.) If we make 
> the flag only affect code generation, it becomes a more clear match for 
> projects using -mcmodel=small with GCC today.

LLVM already differs quite a bit from GNU in more "visible" parts like TLS so 
I'm don't see compelling reason to degrade user's experience just to be more 
compatible.
`-fno-autoimport` sounds fine for me.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D61670/new/

https://reviews.llvm.org/D61670

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D158411: [clang] [MinGW] Pass LTO options to the linker

[Mateusz Mikuła via Phabricator via cfe-commits]

mati865 accepted this revision.
mati865 added a comment.
This revision is now accepted and ready to land.

LGTM


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D158411/new/

https://reviews.llvm.org/D158411

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D138692: [clang] [MinGW] Improve/extend the gcc/sysroot detection logic

[Mateusz Mikuła via Phabricator via cfe-commits]

mati865 accepted this revision.
mati865 added a comment.
This revision is now accepted and ready to land.

LGTM


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D138692/new/

https://reviews.llvm.org/D138692

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D138693: [clang] [MinGW] Improve detection of libstdc++ headers on Fedora

[Mateusz Mikuła via Phabricator via cfe-commits]

mati865 accepted this revision.
mati865 added a comment.
This revision is now accepted and ready to land.

LGTM


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D138693/new/

https://reviews.llvm.org/D138693

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D15006: Driver: Better detection of mingw-gcc

[Mateusz Mikuła via Phabricator via cfe-commits]

mati865 accepted this revision.
mati865 added a comment.
This revision is now accepted and ready to land.

Looks fine for MinGW on Windows.


Repository:
  rL LLVM

https://reviews.llvm.org/D15006



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D29464: [MinGWToolChain] Don't use GCC headers on Win32

[Mateusz Mikuła via Phabricator via cfe-commits]

mati865 created this revision.
mati865 added a project: clang-c.

Header guards in GCC limits.h were stopping Clang from going up one more level 
to the system limits.h


https://reviews.llvm.org/D29464

Files:
  lib/Driver/MinGWToolChain.cpp


Index: lib/Driver/MinGWToolChain.cpp
===
--- lib/Driver/MinGWToolChain.cpp
+++ lib/Driver/MinGWToolChain.cpp
@@ -208,6 +208,7 @@
   if (DriverArgs.hasArg(options::OPT_nostdlibinc))
 return;
 
+#ifndef LLVM_ON_WIN32
   if (GetRuntimeLibType(DriverArgs) == ToolChain::RLT_Libgcc) {
 llvm::SmallString<1024> IncludeDir(GccLibDir);
 llvm::sys::path::append(IncludeDir, "include");
@@ -218,6 +219,7 @@
  Base + Arch + "/sys-root/mingw/include");
 addSystemInclude(DriverArgs, CC1Args, IncludeDir.c_str());
   }
+#endif
   addSystemInclude(DriverArgs, CC1Args,
Base + Arch + llvm::sys::path::get_separator() + "include");
   addSystemInclude(DriverArgs, CC1Args, Base + "include");


Index: lib/Driver/MinGWToolChain.cpp
===
--- lib/Driver/MinGWToolChain.cpp
+++ lib/Driver/MinGWToolChain.cpp
@@ -208,6 +208,7 @@
   if (DriverArgs.hasArg(options::OPT_nostdlibinc))
 return;
 
+#ifndef LLVM_ON_WIN32
   if (GetRuntimeLibType(DriverArgs) == ToolChain::RLT_Libgcc) {
 llvm::SmallString<1024> IncludeDir(GccLibDir);
 llvm::sys::path::append(IncludeDir, "include");
@@ -218,6 +219,7 @@
  Base + Arch + "/sys-root/mingw/include");
 addSystemInclude(DriverArgs, CC1Args, IncludeDir.c_str());
   }
+#endif
   addSystemInclude(DriverArgs, CC1Args,
Base + Arch + llvm::sys::path::get_separator() + "include");
   addSystemInclude(DriverArgs, CC1Args, Base + "include");
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D29464: [MinGWToolChain] Don't use GCC headers on Win32

[Mateusz Mikuła via Phabricator via cfe-commits]

mati865 added a comment.

I don't know about Linux but on Windows this code was causing issue:

  #include 
  int main() { char buf[PATH_MAX]; }

Include order:

- Before patch: Clang limits.h (lib\\clang\\3.9.1\\include) -> GCC limits.h 
(lib\\gcc\\x86_64-w64-mingw32\\6.3.0\\include-fixed) here whole header is 
skipped due to the guards -> Clang limits.h



- After patch: Clang limits.h (lib\\clang\\3.9.1\\include) -> mingw-w64 
limits.h -> Clang limits.h

Before patch mingw-w64 limits.h weren't included so it was big problem.


https://reviews.llvm.org/D29464



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D29464: [MinGWToolChain] Don't use GCC headers on Win32

[Mateusz Mikuła via Phabricator via cfe-commits]

mati865 added a comment.

Adding

  // c:\mingw32\lib\gcc\i686-w64-mingw32\4.9.1\include
  // c:\mingw32\lib\gcc\i686-w64-mingw32\4.9.1\include-fixed

for Clang is wrong on Windows because including limits.h will not show an error 
and won't really include mingw-w64 limits.h
Output of code from my earlier comment without patch:

  error: use of undeclared identifier 'PATH_MAX'
  int main() { char buf[PATH_MAX]; }

I haven't used cross compiled Clang on Linux so I added #ifndef LLVM_ON_WIN32 
guard for this code.
With this guard Clang on Windows uses include paths like native Clang on Linux

Include directories on public paste: https://reviews.llvm.org/P7968


https://reviews.llvm.org/D29464



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D29464: [MinGWToolChain] Don't use GCC headers on Win32

[Mateusz Mikuła via Phabricator via cfe-commits]

mati865 added a comment.

I know why mingw-w64 limits.h weren't used (check first comment).
At first I was using this hack:

  diff -urN clang.orig/3.9.0/include/limits.h clang/3.9.0/include/limits.h
  --- clang.orig/3.9.0/include/limits.h 2016-09-26 22:29:13.496441000 +0200
  +++ clang/3.9.0/include/limits.h  2016-09-26 22:29:34.189625100 +0200
  @@ -28,7 +28,7 @@
   /* The system's limits.h may, in turn, try to #include_next GCC's limits.h.
  Avert this #include_next madness. */
   #if defined __GNUC__ && !defined _GCC_LIMITS_H_
  -#define _GCC_LIMITS_H_
  +#define _LIMITS_H___
   #endif
   
   /* System headers include a number of constants from POSIX in .

It was working (for limiths.h at least) but disabling usage of GCC includes 
made it behaving more like on Linux.
And since quadmath.h doesn't work on Linux with Clang I don't see issue.


https://reviews.llvm.org/D29464



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D29464: [MinGWToolChain] Don't use GCC headers on Win32

[Mateusz Mikuła via Phabricator via cfe-commits]

mati865 updated this revision to Diff 87827.
mati865 added a comment.

Removed adding GCC includes for all mingw hosts.


https://reviews.llvm.org/D29464

Files:
  lib/Driver/MinGWToolChain.cpp
  test/Driver/mingw.cpp

Index: test/Driver/mingw.cpp
===
--- test/Driver/mingw.cpp
+++ test/Driver/mingw.cpp
@@ -7,53 +7,41 @@
 // CHECK_MINGW_ORG_TREE: "{{.*}}/Inputs/mingw_mingw_org_tree/mingw{{/|}}lib{{/|}}gcc{{/|}}mingw32{{/|}}4.8.1{{/|}}include{{/|}}c++"
 // CHECK_MINGW_ORG_TREE: "{{.*}}/Inputs/mingw_mingw_org_tree/mingw{{/|}}lib{{/|}}gcc{{/|}}mingw32{{/|}}4.8.1{{/|}}include{{/|}}c++{{/|}}mingw32"
 // CHECK_MINGW_ORG_TREE: "{{.*}}{{/|}}Inputs/mingw_mingw_org_tree/mingw{{/|}}lib{{/|}}gcc{{/|}}mingw32{{/|}}4.8.1{{/|}}include{{/|}}c++{{/|}}backward"
-// CHECK_MINGW_ORG_TREE: "{{.*}}/Inputs/mingw_mingw_org_tree/mingw{{/|}}lib{{/|}}gcc{{/|}}mingw32{{/|}}4.8.1{{/|}}include"
-// CHECK_MINGW_ORG_TREE: "{{.*}}/Inputs/mingw_mingw_org_tree/mingw{{/|}}lib{{/|}}gcc{{/|}}mingw32{{/|}}4.8.1{{/|}}include-fixed"
 // CHECK_MINGW_ORG_TREE: "{{.*}}/Inputs/mingw_mingw_org_tree/mingw{{/|}}mingw32{{/|}}include"
 // CHECK_MINGW_ORG_TREE: {{.*}}/Inputs/mingw_mingw_org_tree/mingw{{/|}}include
 
 
 // RUN: %clang -target i686-pc-windows-gnu -rtlib=platform -stdlib=libstdc++ -c -### --sysroot=%S/Inputs/mingw_mingw_builds_tree/mingw32 %s 2>&1 | FileCheck -check-prefix=CHECK_MINGW_BUILDS_TREE %s
 // CHECK_MINGW_BUILDS_TREE: "{{.*}}/Inputs/mingw_mingw_builds_tree/mingw32{{/|}}i686-w64-mingw32{{/|}}include{{/|}}c++"
 // CHECK_MINGW_BUILDS_TREE: "{{.*}}/Inputs/mingw_mingw_builds_tree/mingw32{{/|}}i686-w64-mingw32{{/|}}include{{/|}}c++{{/|}}i686-w64-mingw32"
 // CHECK_MINGW_BUILDS_TREE: "{{.*}}/Inputs/mingw_mingw_builds_tree/mingw32{{/|}}i686-w64-mingw32{{/|}}include{{/|}}c++{{/|}}backward"
-// CHECK_MINGW_BUILDS_TREE: "{{.*}}/Inputs/mingw_mingw_builds_tree/mingw32{{/|}}lib{{/|}}gcc{{/|}}i686-w64-mingw32{{/|}}4.9.1{{/|}}include"
-// CHECK_MINGW_BUILDS_TREE: "{{.*}}/Inputs/mingw_mingw_builds_tree/mingw32{{/|}}lib{{/|}}gcc{{/|}}i686-w64-mingw32{{/|}}4.9.1{{/|}}include-fixed"
 // CHECK_MINGW_BUILDS_TREE: "{{.*}}/Inputs/mingw_mingw_builds_tree/mingw32{{/|}}i686-w64-mingw32{{/|}}include"
 
 
 // RUN: %clang -target i686-pc-windows-gnu -rtlib=platform -stdlib=libstdc++ -c -### --sysroot=%S/Inputs/mingw_msys2_tree/msys64/mingw32 %s 2>&1 | FileCheck -check-prefix=CHECK_MINGW_MSYS_TREE %s
 // CHECK_MINGW_MSYS_TREE: "{{.*}}/Inputs/mingw_msys2_tree/msys64{{/|}}mingw32{{/|}}include{{/|}}c++{{/|}}4.9.2"
 // CHECK_MINGW_MSYS_TREE: "{{.*}}/Inputs/mingw_msys2_tree/msys64/mingw32{{/|}}include{{/|}}c++{{/|}}4.9.2{{/|}}i686-w64-mingw32"
 // CHECK_MINGW_MSYS_TREE: "{{.*}}/Inputs/mingw_msys2_tree/msys64/mingw32{{/|}}include{{/|}}c++{{/|}}4.9.2{{/|}}backward"
-// CHECK_MINGW_MSYS_TREE:  "{{.*}}/Inputs/mingw_msys2_tree/msys64/mingw32{{/|}}lib{{/|}}gcc{{/|}}i686-w64-mingw32{{/|}}4.9.2{{/|}}include"
-// CHECK_MINGW_MSYS_TREE:  "{{.*}}/Inputs/mingw_msys2_tree/msys64/mingw32{{/|}}lib{{/|}}gcc{{/|}}i686-w64-mingw32{{/|}}4.9.2{{/|}}include-fixed"
 // CHECK_MINGW_MSYS_TREE: "{{.*}}/Inputs/mingw_msys2_tree/msys64/mingw32{{/|}}i686-w64-mingw32{{/|}}include"
 // CHECK_MINGW_MSYS_TREE: "{{.*}}/Inputs/mingw_msys2_tree/msys64/mingw32{{/|}}include"
 
 
 // RUN: %clang -target x86_64-pc-windows-gnu -rtlib=platform -stdlib=libstdc++ -c -### --sysroot=%S/Inputs/mingw_opensuse_tree/usr %s 2>&1 | FileCheck -check-prefix=CHECK_MINGW_OPENSUSE_TREE %s
 // CHECK_MINGW_OPENSUSE_TREE: "{{.*}}/Inputs/mingw_opensuse_tree/usr{{/|}}lib64{{/|}}gcc{{/|}}x86_64-w64-mingw32{{/|}}5.1.0{{/|}}include{{/|}}c++"
 // CHECK_MINGW_OPENSUSE_TREE: "{{.*}}/Inputs/mingw_opensuse_tree/usr{{/|}}lib64{{/|}}gcc{{/|}}x86_64-w64-mingw32{{/|}}5.1.0{{/|}}include{{/|}}c++{{/|}}x86_64-w64-mingw32"
 // CHECK_MINGW_OPENSUSE_TREE: "{{.*}}/Inputs/mingw_opensuse_tree/usr{{/|}}lib64{{/|}}gcc{{/|}}x86_64-w64-mingw32{{/|}}5.1.0{{/|}}include{{/|}}c++{{/|}}backward"
-// CHECK_MINGW_OPENSUSE_TREE: "{{.*}}/Inputs/mingw_opensuse_tree/usr{{/|}}lib64{{/|}}gcc{{/|}}x86_64-w64-mingw32{{/|}}5.1.0{{/|}}include"
 // CHECK_MINGW_OPENSUSE_TREE: "{{.*}}/Inputs/mingw_opensuse_tree/usr{{/|}}x86_64-w64-mingw32/sys-root/mingw/include"
-// CHECK_MINGW_OPENSUSE_TREE: "{{.*}}/Inputs/mingw_opensuse_tree/usr{{/|}}lib64{{/|}}gcc{{/|}}x86_64-w64-mingw32{{/|}}5.1.0{{/|}}include-fixed"
 
 
 // RUN: %clang -target i686-pc-windows-gnu -rtlib=platform -stdlib=libstdc++ -c -### --sysroot=%S/Inputs/mingw_arch_tree/usr %s 2>&1 | FileCheck -check-prefix=CH

[PATCH] D29772: Create msbuild only when using MSVC

[Mateusz Mikuła via Phabricator via cfe-commits]

mati865 created this revision.
mati865 added a project: clang-c.
Herald added a subscriber: mgorny.

https://reviews.llvm.org/D29772

Files:
  tools/driver/CMakeLists.txt


Index: tools/driver/CMakeLists.txt
===
--- tools/driver/CMakeLists.txt
+++ tools/driver/CMakeLists.txt
@@ -61,7 +61,7 @@
 if(NOT CLANG_LINKS_TO_CREATE)
   set(CLANG_LINKS_TO_CREATE clang++ clang-cl clang-cpp)
 
-  if (WIN32)
+  if (MSVC)
 list(APPEND CLANG_LINKS_TO_CREATE ../msbuild-bin/cl)
   endif()
 endif()


Index: tools/driver/CMakeLists.txt
===
--- tools/driver/CMakeLists.txt
+++ tools/driver/CMakeLists.txt
@@ -61,7 +61,7 @@
 if(NOT CLANG_LINKS_TO_CREATE)
   set(CLANG_LINKS_TO_CREATE clang++ clang-cl clang-cpp)
 
-  if (WIN32)
+  if (MSVC)
 list(APPEND CLANG_LINKS_TO_CREATE ../msbuild-bin/cl)
   endif()
 endif()
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D29464: [MinGWToolChain] Don't use GCC headers on Win32

[Mateusz Mikuła via Phabricator via cfe-commits]

mati865 marked an inline comment as done.
mati865 added a comment.

@yaron.keren those includes are not available in native Linux Clang:

  float128_ex.cc:2:10: fatal error: 'quadmath.h' file not found
  #include 
   ^

And at least 2 of GCC includes clash with Clang includes:

- limits.h - explained above, guards are preventing including of mingw-w64 
limits.h
- ia32intrin.h - compilation errors, not investigated further as this patch 
fixed it

If those changes are not wanted this Diff can be closed and it will be used as 
local patch for MSYS2 Clang.


https://reviews.llvm.org/D29464



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D29464: [MinGWToolChain] Don't use GCC headers on Win32

[Mateusz Mikuła via Phabricator via cfe-commits]

mati865 added a comment.

omp.h on Linux is supported by OpenMP package 
https://www.archlinux.org/packages/extra/x86_64/openmp/files/
I haven't tried to build it on win32 yet but since my examination session at 
college is over I'll try it in following days.

I'm not sure but openacc.h probably doesn't work on Linux with Clang


https://reviews.llvm.org/D29464



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D34606: [libcxx] Link MinGW libs for shared build

[Mateusz Mikuła via Phabricator via cfe-commits]

mati865 added a comment.

Sorry @martell I totally forgot about it.
I'll test https://reviews.llvm.org/D33638 later today.


Repository:
  rL LLVM

https://reviews.llvm.org/D34606



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D29464: [MinGWToolChain] Don't use GCC headers on Win32

[Mateusz Mikuła via Phabricator via cfe-commits]

mati865 added a comment.

My GPU has died in the meantime but openmp project doesn't seem buildable with 
mingw-w64 based compilers.
So the case is still open.


https://reviews.llvm.org/D29464



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D29464: [MinGWToolChain] Don't use GCC headers on Win32

[Mateusz Mikuła via Phabricator via cfe-commits]

mati865 added a comment.

@yaron.keren, @rnk I would like to see OpenMP support by MinGW Clang but using 
GCC "internal" headers is just wrong.

> For example, the most popular (37089 download this week) 
> https://sourceforge.net/projects/mingw-w64 distribuion for Windows had 
> elected to place the includes omp.h, quadmath.h, openacc.h at 
> c:\mingw32\lib\gcc\i686-w64-mingw32\5.4.0\include\

It wasn't mingw-w64 decision but rather GCC. Linux examples:

- Arch Linux: `/usr/lib/gcc/x86_64-pc-linux-gnu/6.3.1/include/`
- Ubuntu 14.04: `/usr/lib/gcc/x86_64-linux-gnu/4.8/include`
- Ubuntu 17.04: `/usr/lib/gcc/x86_64-linux-gnu/6/include`

None of those directories are searched by Clang on Linux host.

> Removing the include dir will make clang less useful for mingw users using 
> these includes, since they will not be found anymore.

I highly doubt it:

Summary:

1. quadmath.h:
  - Linux:not working, quadmath. not found
  - MinGW with GCC headers:  not working, __float128 isn't supported
  - MinGW without GCC headers: not working, quadmath. not found and __float128 
isn't supported
2. omp.h:
  - Linux:working via 
http://openmp.llvm.org/
  - MinGW with GCC headers:  not working, compilation error
  - MinGW without GCC headers: not working, http://openmp.llvm.org/ is not 
buildable
3. openacc.h:
  - Linux:not working, openacc.h not found
  - MinGW with GCC headers:  not working, not tested
  - MinGW without GCC headers: not working, openacc.h not found

Details:
**quadmath.h** is useless without __float128

Clang with enabled __float128 via patch:

  $ clang++ float128_ex.cc -std=gnu++11
  
  $ ./a
  Segmentation fault

Clang with unpatched __float128:

  $ clang++ float128_ex.cc -std=gnu++11
  
  
D:\projekty\msys2\clang\msys64\mingw64\lib\gcc\x86_64-w64-mingw32\6.3.0\include\quadmath.h:43:26:
 error: __float128 is not supported on this target
  extern __float128 acosq (__float128) __quadmath_throw;

GCC:

  $ g++ float128_ex.cc -lquadmath -std=gnu++11
  
  $ ./a
  r=0
  exp_d=255250

**omp.h** crashes, example 
https://computing.llnl.gov/tutorials/openMP/samples/C/omp_hello.c :

  $ g++ omp.cc -fopenmp
  
  $ ./a
  Hello World from thread = 0
  Hello World from thread = 1
  Number of threads = 2
  
  $ clang++ omp.cc -fopenmp
  D:\projekty\msys2\clang\msys64\tmp\omp-87d437.o:(.text+0x35): undefined 
reference to `__imp___kmpc_fork_call'
  clang++.exe: error: linker command failed with exit code 1 (use -v to see 
invocation)

**openacc.h** isn't available even on Linux (openacc.h not found) and I cannot 
test it with MinGW


https://reviews.llvm.org/D29464



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D29464: [MinGWToolChain] Don't use GCC headers on Win32

[Mateusz Mikuła via Phabricator via cfe-commits]

mati865 added a comment.

Final decision is left for @rnk and @asl but I'm still against using GCC 
"internal" headers in the way they aren't supposed to be used. And have MinGW 
Clang behaving like Linux Clang.

> developer would have to fix the missing headers bug one day

Solving general Clang issue with win32 only fix doesn't seem right.

> he will have to re-fix limits.h the right way and undo this "fix".

It will be better to have proper fix than this hackish workaround in limits.h

> There is a problems with limits.h, fix limits.h. Don't make all headers that 
> happens to be in the same directory as limits.h disappear.

There are more issues hidden unless someone tries to compile specific code 
(ia32intrin.h for an example, I no longer have example however).


https://reviews.llvm.org/D29464



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D29464: [MinGWToolChain] Don't use GCC headers on Win32

[Mateusz Mikuła via Phabricator via cfe-commits]

mati865 added a comment.

If there are no further objections it can be committed by somebody.


https://reviews.llvm.org/D29464



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D29772: Create msbuild only when using MSVC

[Mateusz Mikuła via Phabricator via cfe-commits]

mati865 added a reviewer: rnk.
mati865 added a comment.

https://reviews.llvm.org/D29952 depends on this.


https://reviews.llvm.org/D29772



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D29772: Create msbuild only when using MSVC

[Mateusz Mikuła via Phabricator via cfe-commits]

mati865 added a comment.

Commit it please when you aren't busy.
Thanks in advance.


https://reviews.llvm.org/D29772



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D29464: [MinGWToolChain] Don't use GCC headers on Win32

[Mateusz Mikuła via Phabricator via cfe-commits]

mati865 added a comment.

Ping.


https://reviews.llvm.org/D29464



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D29464: [MinGWToolChain] Don't use GCC headers on Win32

[Mateusz Mikuła via Phabricator via cfe-commits]

mati865 added a comment.

Thank you.


Repository:
  rL LLVM

https://reviews.llvm.org/D29464



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D29772: Create msbuild only when using MSVC

[Mateusz Mikuła via Phabricator via cfe-commits]

mati865 added a comment.

Thank you.


https://reviews.llvm.org/D29772



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D29772: Create msbuild only when using MSVC

[Mateusz Mikuła via Phabricator via cfe-commits]

mati865 added a subscriber: asl.
mati865 added a comment.

@asl it is still not commited.
Something went wrong?


Repository:
  rL LLVM

https://reviews.llvm.org/D29772



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D33082: Fix Libc++ build with MinGW64

[Mateusz Mikuła via Phabricator via cfe-commits]

mati865 accepted this revision.
mati865 added a comment.
This revision is now accepted and ready to land.

I don't know if it is MSYS2 specific or general MinGW issue but liblibc++.a is 
created. Could you check your build?
Here is line to blame: 
https://github.com/llvm-mirror/libcxx/blob/master/lib/CMakeLists.txt#L246


https://reviews.llvm.org/D33082



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits