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

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

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

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

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

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

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

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 +++

[PATCH] D29772: Create msbuild only when using MSVC

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

[PATCH] D29772: Create msbuild only when using MSVC

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

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

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

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

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

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

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

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

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

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

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

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

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 === ---

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

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

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

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] D15006: Driver: Better detection of mingw-gcc

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

[PATCH] D29772: Create msbuild only when using MSVC

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

[PATCH] D29772: Create msbuild only when using MSVC

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] D29464: [MinGWToolChain] Don't use GCC headers on Win32

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] D34606: [libcxx] Link MinGW libs for shared build

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

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

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:

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

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 === ---

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

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:

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

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

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

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] D87517: [MinGW] Use lib prefix for libraries

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

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

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

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

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

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

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

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

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/

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

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

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

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

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

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

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

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 >

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

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

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

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

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

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

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

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

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

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

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

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:

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

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

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

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

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

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

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

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

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

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

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

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)

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

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)

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

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

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

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:

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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() &&

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 >