search for: win32threads

...is less that I remember seeing last year (something got optimized?), but still... Vadim On Fri, Sep 26, 2014 at 3:29 AM, Yaron Keren <yaron.keren at gmail.com> wrote: > Yes, of course. > > I refer to the significant slowdown of Rust compiler when compiled with > -pthreads vs -win32threads flavor. > If Rust can be compiled without <mutex> and <thread> on win32threads, why > should it slow down on pthreads? > Isn't the only difference betwen the win32threads and pthreads is the > addition of pthreads, <mutex> and <thread>? > > Yaron > &...

...way, does the -win32 version have any feature that > -pthreads vesion do not have? > > Yaron > > > 2014-09-25 9:52 GMT+03:00 Vadim Chugunov <vadimcn at gmail.com>: > >> 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 fla...

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 to...

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

...ing List; clang-dev Developers; > lldb-dev at cs.uiuc.edu; Chris Bieneman; Reid Kleckner; David Majnemer; Alex > Rosenberg; Zachary Turner > *Subject:* [LLVMdev] RFC: LLVM should require a working C++11 <thread>, > <mutex>, and <atomic> > > > > 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 r...

On Wed, Jul 15, 2015 at 10:45 AM, Russell Wallace <russell.wallace at gmail.com > wrote: > Basic test results on Windows 7, visual studio 2013 (64 bit): > > Build clang with visual studio - okay > > Build clang with itself - okay > > Build Python - okay > > Build Ruby - fails on conftest.c, but 3.6 also failed so this is not a > regression bug > > Build

On Thu, Jul 16, 2015 at 8:08 AM, Nico Weber <thakis at chromium.org> wrote: > On Wed, Jul 15, 2015 at 10:45 AM, Russell Wallace < > russell.wallace at gmail.com> wrote: > >> Basic test results on Windows 7, visual studio 2013 (64 bit): >> >> Build clang with visual studio - okay >> >> Build clang with itself - okay >> >> Build Python

On Fri, Jul 24, 2015 at 12:05 PM, Nico Weber <thakis at chromium.org> wrote: > On Thu, Jul 16, 2015 at 8:08 AM, Nico Weber <thakis at chromium.org> wrote: > >> On Wed, Jul 15, 2015 at 10:45 AM, Russell Wallace < >> russell.wallace at gmail.com> wrote: >> >>> Basic test results on Windows 7, visual studio 2013 (64 bit): >>> >>>

...benchmark in SPEC CPU2006 relies on it returning a NaN apparently. * Chandler Carruth has posted an RFC proposing that [LLVM should require a working C++11 thread, mutex, and atomic](http://article.gmane.org/gmane.comp.compilers.llvm.devel/77148) with the intention being that support for MinGW and win32threads is dropped. Switching to MinGW-win64 seems like a feasible path forwards. * Wondering how to use noalias and alias.scope metadata notations? Hal Finkel [has the answer](http://article.gmane.org/gmane.comp.compilers.llvm.devel/77174) for you. * Should the LLVM project standardise on a [commit mess...

Hi all, The 3.7 release branch was created from trunk at r242221 today (around 10:40 pm UTC). Branch policy: - Any doc changes can go in. Updates to the release notes are highly encouraged, and should be committed directly to the branch. - All other patches should be approved by the release manager (me) and the appropriate code owner. To get a change merged, commit it to trunk, and then reply