Can somebody land it before LLVM 8 is branched? Patch author does not have commit access.

@jlpeyton OP doesn't have commit access.

Sorry @martell I totally forgot about it.
I'll test D33638 later today.

Some time ago I both enabled __float128 and defined macro but using it (__float128) cased segfaults. So I reduced it to HasFloat128 and haven't upstreamed it due to broken tests. It's good to see things improved.

@EricWF I think basic usage should be fine as soon as libc++abi gets linked properly. I suppose it haven't changed much since https://reviews.llvm.org/P7981
Back then replacing libc++abi with libsupc++ with few more hacks created almost-working libc++.

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

Looks fine for MinGW on Windows.

Ping

Thank you @rnk
Could you check https://reviews.llvm.org/D29772 ? Looks like there was problem with commit

Ping

Ping

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

Thank you.

Thank you.

Ping.

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

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

I suppose those 4 lines were your concern: https://github.com/llvm-mirror/llvm/blob/3ca564103abdd0c70f28f270873a2e535c245a6f/CMakeLists.txt#L231

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

It might be not relevant but it broke llvm-config --libs --link-shared when LLVM is built with:

-DLLVM_BUILD_LLVM_DYLIB=ON \
-DLLVM_LINK_LLVM_DYLIB=OFF \

That's valid concern, I'll try tomorrow to find out how it works.

Fixed intend

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.

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

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.

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.

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

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

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

Removed adding GCC includes for all mingw hosts.

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

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

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