similar to: [LLVMdev] Cygwin bootstrap is incompatible with <mutex> (and most other threading C++11 libraries)

AKA: MinGW + win32threads is holding LLVM (and all of its subprojects) back. We need to stop supporting this host platform. I'm aware of essentially 2 reasonably important use cases for supporting MinGW + win32threads: 1) Sane host toolchain on Windows that doesn't require downloading MSVC. (I'm dubious about the value of this one...) 2) Cross-compiling a Windows clang.exe (and

+chandlerc, aaronballman, in case there are additional carryovers and/or issues from the review thread which I've left out. I have a patch up for review[1, 2] that attempts to replace LLVM's mutex implementation with std::mutex and std::recursive_mutex. While the patch seems to work, there are questions surrounding whether or not the approach used is correct. I'll try to summarize

Sorry, I mean only disable this for THREADS-WIN32, not threads-posix. On Fri, Jun 20, 2014 at 11:14 AM, Zachary Turner <zturner at google.com> wrote: > #2 is better if we can detect threads-win32 vs threads-posix on MinGW, and > only disable this for threads-posix. We can check for > _GLIBCXX_HAS_GTHREADS, but that seems somewhat hackish, so I wonder if > there's a better

Hi, After a discussion with David, Id like to propose a rework of the Windows target triples. The current set of Windows triples are somewhat less uniform than their Linux counterparts. With multiple ABIs and environments on Windows, they are also slightly awkward. Obviously, certain ones might be nice to keep around for compatibility (e.g. the mingw triple). Just to ensure that everyone has

Hi Yaron, Not sure I understand your question. Wasn't <mutex> one of the more important C++11 features that LLVM would like to use? On Thu, Sep 25, 2014 at 1:24 AM, Yaron Keren <yaron.keren at gmail.com> wrote: > Vadim, > > Thanks for the feedback on the -win32. A dependency on a small DLL with > BSD license does not sound too bad, but performance regression is

I am looking at starting a project to make a toy language that is targeted purely at 64bit windows. I have never used llvm or anything like it i am just trying to learn new things. However there are several problems, as far as i have seen, with compiling llvm in 64bit on windows. So i was wondering if i compile a 32bit version of llvm and use that can my resulting compiler output 64bit binaries?

Hi, I think I can at least answer why the Rust project prefers to use mingw-w64-win32threads: 1. It does not inject dependency on libwinpthread.dll, which is nice. 2. Those who tried building LLVM with mingw-w64-pthreads, had reported significant slowdown of the resulting Rust compiler (as compared to one linked to LLVM compiled with the win32threads flavor). Profiling seemed to point towards

When LLVM's configure finds a usable <pthread.h>, it prefers to use that rather than the home-grown stuff. However if LLVM is configured with --disable-pthreads, both mingw flavors produce the same results. BTW, I've tried to quantify the slowdown: a quick test indicates that LLVM build that uses pthreads is about 10% slower than the one which doesn't. This is less that I

Hi, I'm getting a returning build failure when building a linux->windows crosscompiler out of LLVM/Clang. Attached is config.log and below is the output of "make VERBOSE=1" llvm[2]: Linking Release executable FileCheck (without symbols) g++ -I/home/ruben/mingw-w64/toolchain/linux64mingw64/llvm-clang/include

It sounds like this version of libstdc++ doesn't support std::recursive_mutex from C++11. This is really unfortunate, because we were hoping that moving to C++11 would allow us to use standard, portable threading primitives. Does this version of MinGW have any C++11 threading support? Is it just recursive_mutex that is missing, or do we have to avoid std::mutex, std::call_once, etc? lld

I did try the cygwin mingw-x86_64 but i couldn't get llvm to compile, but i did try and compile clang and compiler_rt as well, may have to try again soon. On windows i'm not interesting in i686 or any 32 bit compiling just 64 bit alone but i don't need a jit anyways for my language. If i use the cygwin environment to build llvm do i have to use cmake or can i use the standard

Hi, I was just browsing my LNT performance builder and it seems within the last month we managed to increase compile time from 37 to 47 seconds for the bullet benchmark: http://llvm.org/perf/db_default/v4/nts/graph?plot.0=34.274.3&highlight_run=29054 A similar pattern can be seen for MallocBench/gs/gs where we go from 5.3 to 7.4 seconds.

OK, sounds like we're screwed. There's two options: 1. Revert and give up on C++11 threading libraries for now. 2. Do what Eric suggests. Move all the mutex usage under #ifdef LLVM_ENABLE_THREADS, and disable LLVM_ENABLE_THREADS by default on MinGW. MinGW plus LLVM_ENABLE_THREADS would become unsupported. Do people have objections to 2? I don't really like it either. On Fri, Jun

2011/10/18 Albert Graef <Dr.Graef at t-online.de>: > On 10/17/2011 04:44 PM, Duncan Sands wrote: >> PS: A more convincing (IMO) argument against dragonegg is that it doesn't >> work on windows.  That's because the gcc plugin architecture doesn't work >> on windows.  Takumi has been thinking about this and has been enable to >> get dragonegg to work on

Indeed, mingw and pthreads have C++11 atomics, so building clang (with atomics) should be possible even in cross compilation. I have no idea what is the win from *not* using winpthreads, it is one small DLL file with BSD license. For context (does not matter to mingw as host for buiilding clang but matters for clang running with mingw environment), clang TLS implementation is not same as mingw so

Hello, NAKAMURA Takumi As you said, I check out the head from svn trunk. I build the source code as the following steps: $./configure --enable-shared $ make After 1 hour, the building procedure is stopped and appear the following error message: c:/strawberry/c/bin/../lib/gcc/i686-w64-mingw32/4.4.3/../../../../i686-w64-mingw 32/bin/ld.exe:

On 24 Sep 2014, at 05:59, Mueller-Roemer, Johannes Sebastian <Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de> wrote: > <atomic> should work both in win32 and pthread versions of MinGW. <mutex> and <thread> are only supported in the pthread version though. <atomic> is trivial, as most of the support is provided by the compiler. As of Vista, Windows comes

Good evening, Yuan Excuse me, I gave up Debug build earlier due to my poor hosts. I will improve able to build Debug ;) You may build with --enable-optimized=yes (or, make ENABLE_OPTIMIZED=1) btw, DLL builder has implemented since Aug. It might be easier to port DLL stuff to 2.6 :) Do you try? ...Takumi 2010年9月2日 17:16:25 UTC+9 yuan zheng <tsinghuayuan86 at gmail.com>: > Hello,

I was building llvm2.9 using MinGW64 on windows, msys was 32 bit so I specified --host option for a cross compiling. Following are my configure options: ../llvm2.9/configure --prefix=/home/AutoESL/llvm-obj --host=x86_64-w64-mingw32 --disable-multilib The error: make[1]: Entering directory `/home/AutoESL/llvm-obj/lib/VMCore' make[1]: ***

Ruben, Your failure must be due to --disable-pthreads. lib/Support/Unix/Mutex.inc does not have "acquire()". (Shall we fix it?) It might be a bug, though, --disable-pthreads would not make sense to your configuration. --enable-pthreads affects host platform. Note, LLVM and Clang have multi-target architecture. --target is understood as "default target". (EE/JIT should take