llvm dev - Sep 2014 - [LLVMdev] [cfe-dev] 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 require downloading MSVC.
(I'm dubious about the value of this one...)

2) Cross-compiling a Windows clang.exe (and other tools) from a Linux (or
other host) box.

Are there others? (And thanks to Reid for explaining these to me!)


I'm somewhat dubious about #1, but if we address #2 it will address any
concerns with #1 anyways.

I would like to propose that we finish implementing libc++ sufficiently to
host Clang on Windows using native Windows APIs to implement things. Then
we document very clearly what is required to download the basic Windows SDK
and cross compile Clang (and any other tools) for Windows using just libc++
and the SDK. No need for MSVC bits, etc. Would this be acceptable?

If not, would it be acceptable to use libc++ on top of mingw (so just
avoiding libstdc++)? I *really* don't want to spend lots of time going
there because it seems like a low-value platform, but we can.

Anyways, I want to tease out anything else required here because if this is
all we need, I think we can make it a reality and get to a much saner
platform.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140923/abfd3eca/attachment.html>

I would love to see libc++ working on Windows. In any case, I personally use
MinGW with pthreads, as that supports std::thread etc. Yes, it uses
libwinpthread, but that shouldn’t really be an issue.

--
Johannes S. Mueller-Roemer, MSc
Wiss. Mitarbeiter - Interactive Engineering Technologies (IET)

Fraunhofer-Institut für Graphische Datenverarbeitung IGD
Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
Tel +49 6151 155-606  |  Fax +49 6151 155-139
johannes.mueller-roemer at igd.fraunhofer.de  |  www.igd.fraunhofer.de

From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
Behalf Of Chandler Carruth
Sent: Wednesday, September 24, 2014 03:02
To: LLVM Developers Mailing 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 require downloading MSVC.
(I'm dubious about the value of this one...)

2) Cross-compiling a Windows clang.exe (and other tools) from a Linux (or other
host) box.

Are there others? (And thanks to Reid for explaining these to me!)


I'm somewhat dubious about #1, but if we address #2 it will address any
concerns with #1 anyways.

I would like to propose that we finish implementing libc++ sufficiently to host
Clang on Windows using native Windows APIs to implement things. Then we document
very clearly what is required to download the basic Windows SDK and cross
compile Clang (and any other tools) for Windows using just libc++ and the SDK.
No need for MSVC bits, etc. Would this be acceptable?

If not, would it be acceptable to use libc++ on top of mingw (so just avoiding
libstdc++)? I *really* don't want to spend lots of time going there because
it seems like a low-value platform, but we can.

Anyways, I want to tease out anything else required here because if this is all
we need, I think we can make it a reality and get to a much saner platform.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140924/4db8ffa5/attachment.html>

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 atomics do not work for clang+mingw pthreads unless
you replace libstdc++ with libcxx compiled by clang. Even there may be
troubles with mingw-compiled libraries.

libc++ could be built with mingw-w64. I had worked for a while with
mingw-w64 distribution with the C++ includes and libstdc++ replaced by the
libcxx files and dll respectively. It mostly works but there were many
issues in tests. I'm not sure what is the value of this configuration
unless it is start of road to independent clang-based 'gnu flavor'
windows
toolchain.


2014-09-24 9:06 GMT+03:00 Mueller-Roemer, Johannes Sebastian <
Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de>:
>  I would love to see libc++ working on Windows. In any case, I personally
> use MinGW with pthreads, as that supports std::thread etc. Yes, it uses
> libwinpthread, but that shouldn't really be an issue.
>
>
>
> --
>
> Johannes S. Mueller-Roemer, MSc
>
> Wiss. Mitarbeiter - Interactive Engineering Technologies (IET)
>
>
>
> Fraunhofer-Institut für Graphische Datenverarbeitung IGD
>
> Fraunhoferstr. 5  |  64283 Darmstadt  |  Germany
>
> Tel +49 6151 155-606  |  Fax +49 6151 155-139
>
> johannes.mueller-roemer at igd.fraunhofer.de  |  www.igd.fraunhofer.de
>
>
>
> *From:* llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at
cs.uiuc.edu] *On
> Behalf Of *Chandler Carruth
> *Sent:* Wednesday, September 24, 2014 03:02
> *To:* LLVM Developers Mailing 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 require downloading
MSVC.
> (I'm dubious about the value of this one...)
>
>
>
> 2) Cross-compiling a Windows clang.exe (and other tools) from a Linux (or
> other host) box.
>
>
>
> Are there others? (And thanks to Reid for explaining these to me!)
>
>
>
>
>
> I'm somewhat dubious about #1, but if we address #2 it will address any
> concerns with #1 anyways.
>
>
>
> I would like to propose that we finish implementing libc++ sufficiently to
> host Clang on Windows using native Windows APIs to implement things. Then
> we document very clearly what is required to download the basic Windows SDK
> and cross compile Clang (and any other tools) for Windows using just libc++
> and the SDK. No need for MSVC bits, etc. Would this be acceptable?
>
>
>
> If not, would it be acceptable to use libc++ on top of mingw (so just
> avoiding libstdc++)? I *really* don't want to spend lots of time going
> there because it seems like a low-value platform, but we can.
>
>
>
> Anyways, I want to tease out anything else required here because if this
> is all we need, I think we can make it a reality and get to a much saner
> platform.
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140924/58f8850b/attachment.html>

On 09/23/2014 09:02 PM, Chandler Carruth wrote:
> 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 other tools) from a Linux 
> (or other host) box.
>
> Are there others? (And thanks to Reid for explaining these to me!)
>
>
> I'm somewhat dubious about #1, but if we address #2 it will address 
> any concerns with #1 anyways.
>
> I would like to propose that we finish implementing libc++ 
> sufficiently to host Clang on Windows using native Windows APIs to 
> implement things. Then we document very clearly what is required to 
> download the basic Windows SDK and cross compile Clang (and any other 
> tools) for Windows using just libc++ and the SDK. No need for MSVC 
> bits, etc. Would this be acceptable?
>
> If not, would it be acceptable to use libc++ on top of mingw (so just 
> avoiding libstdc++)? I *really* don't want to spend lots of time going 
> there because it seems like a low-value platform, but we can.
>
> Anyways, I want to tease out anything else required here because if 
> this is all we need, I think we can make it a reality and get to a 
> much saner platform.
>
>
To address #1 in a somehow unorthodox manner: musl libc is expected 
become available on NT at the end of 2014, or very early in 2015. Once 
available, portable[*] projects that successfully build against musl on 
linux (which occasionally requires a few patches, mostly due to a 
project working around bugs in popular libc's in strange and mysterious 
ways) should successfully build and execute on NT without any 
source-level modifications.[**]  Below is additional technical and 
general information about the project.

* portable means that the project _does not_ use esoteric PRCTL codes 
and their liking.  The midipix system layer does provide common 
facilities such as /proc, /dev/random, /dev/tty, /dev/pty, etc., so 
using them in a program or library should not create for a problem.

** a well-written portable project should only need to add appropriate 
references to the midipix targets (x86_64-nt64-midipix, 
i686-nt32-midipix) to its build system.  In addition, gui projects might 
need to divorce WIN32 from GDI.  In other words, projects that want to 
use musl libc in conjunction with GDI will need to ensure that their 
#ifdef's do not conflate the system api with the gui framework of interest.

additional technical and general information
-----------------------------------------------------------
The principals of the project that are probably the most relevant to 
clang/llvm are:

1. "portability from below": make the libc available on NT by
providing
its prerequisites (the system call layer, the tty facility, /proc, etc.) 
rather than changing it.  This means that save a few 
architecture-specific files, the libc source for NT and Linux are 
identical, and accordingly free of #ifdef hackery.

2. provide a tightly integrated development framework consisting of a 
libc, a compiler (gcc, clang), and a user-space sub-system (the terminal 
emulator).

3. allow executables to be distributed with zero external dependencies 
(copy your application and the terminal emulator to a folder, along with 
any other libraries or data files that your application might need, and 
you are all set).

4. provide ultimate flexibility with respect to the GUI framework being 
used (to answer a popular question: a terminal emulator does not 
necessarily mean an open terminal window).

Once the above goals have been met, it would be possible to have a 
native clang/llvm development environment on NT that could be used both 
natively and for cross-compilation .  At the same time, it is important 
to realize that as far as mingw(-w64) goes, cross-compilation itself 
will _not_ (and cannot) solve the current mingw shortcomings with 
respect to libc++, or any of the issues related to its dependencies (see 
Chandler's #1).

As far as existing code bases are concerned, the projects that could 
benefit from the midipix framework the most are cross-platform projects 
that prefer a linux/posix api (and libc) over the WIN32 one.  Projects 
that are purely written for WIN32 could still benefit from the 
development environment, however in order to benefit from the libc (or 
any other feature) at run-time, some effort and refactoring will have to 
be in place.

Last but not least: although the midipix project is currently reaching 
its advanced development phase prior to an alpha release, and while it 
is planned to be released with an OSI-compatible license, the vast 
majority of the code is not yet publicly available.

Regards,
zg

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140924/56957aab/attachment.html>

Chandler Carruth <chandlerc at gmail.com> writes:
> 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:
I suppose that you are talking about MinGW (www.mingw.org) all along
and not about MinGW-w64 (www.mingw-w64.org) which supports the features
you are missing.
> 1) Sane host toolchain on Windows that doesn't require downloading
MSVC.
> (I'm dubious about the value of this one...)
Oh, well. You are talking about "everything that is not MSVC++". Ok.
> 2) Cross-compiling a Windows clang.exe (and other tools) from a Linux (or
> other host) box.
I have no idea how cross-compiling from other OS can solve shortcomings
on the *runtime* libraries of a toolchain.

[snip]
> I *really* don't want to spend lots of time going
> there because it seems like a low-value platform, but we can.
Thanks, I knew that you consider MinGW* "low-value" all along.
MinGW-w64
is well ahead of MSVC++ on C++ language and library support, and it is
very likely that it will remain that way, but you take every chance to
bad-mouth it to promote MSVC++ support on LLVM/Clang.

[snip]

* ?scar Fuentes <ofv at wanadoo.es> [2014-09-24 14:35:17
+0200]:
> MinGW(-w64) is not about compiling "portable" Linux software on
Windows,
> it is about compiling Windows API/CRT software on Windows, just like the
> MSVC++ toolchain.
the problem with mingw is that it does not implement the posix api and
thus code is littered with ifdefs or abstraction layers (which are
usually broken), llvm has its own share of ugly and broken ifdefs

most of the problems come from the limitations of the windows c runtime
> IIUC what you propose is another Cygwin that imposes specific
> requirements on how software must be and requires "rebuilding the
> world". No thanks.
the problem with cygwin is that it has global settings and the cygwin
environment might be different on each target machine, it is not a
reliable posix api and the cygwin dll cannot be easily bundled with
an application

but for example if it can be solved that no ifdefs are needed in the
code and there are no dependencies on special global settings
(so applications can assume a reasonable and consistent environment
across all targets) then that could be useful

(and as far as i understand porting musl to the nt kernel makes this
possible: write code for the posix api and run it everywhere, at
least statically linked executables would work that way, cygwin cannot
do that)

On 09/24/2014 08:35 AM, Óscar Fuentes wrote:
> "writeonce at midipix.org"
> <writeonce at midipix.org> writes:
>
>> To address #1 in a somehow unorthodox manner: musl libc is expected
>> become available on NT at the end of 2014, or very early in 2015. Once
>> available, portable[*] projects that successfully build against musl
>> on linux (which occasionally requires a few patches, mostly due to a
>> project working around bugs in popular libc's in strange and
>> mysterious ways) should successfully build and execute on NT without
>> any source-level modifications.[**]  Below is additional technical and
>> general information about the project.
> MinGW(-w64) is not about compiling "portable" Linux software on
Windows,
> it is about compiling Windows API/CRT software on Windows, just like the
> MSVC++ toolchain.
>
> IIUC what you propose is another Cygwin that imposes specific
> requirements on how software must be and requires "rebuilding the
> world". No thanks.
One important point you seem to be missing is the ability to 
cross-compile API/CRT software on Windows with a clang.exe which does 
not depend on msvcrt.exe.  From a technical perspective (and also with 
respect to many of its goals), the project differs from Cygwin in 
virtually every possible way (some key differences, as well as the 
distinction between mingw as a target and a libc++ _for_ mingw, can be 
found in my original message).

Hi Oscar,

The question is should llvm start using <thread> and <mutex> when
mingw+win32 threads does not support these.

What is the reason to use mingw+win32 threads instead of mingw+pthreads
which does support the above?

Yaron


2014-09-24 15:47 GMT+03:00 Óscar Fuentes <ofv at wanadoo.es>:
> Chandler Carruth <chandlerc at gmail.com> writes:
>
> > 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:
>
> I suppose that you are talking about MinGW (www.mingw.org) all along
> and not about MinGW-w64 (www.mingw-w64.org) which supports the features
> you are missing.
>
> > 1) Sane host toolchain on Windows that doesn't require downloading
MSVC.
> > (I'm dubious about the value of this one...)
>
> Oh, well. You are talking about "everything that is not MSVC++".
Ok.
>
> > 2) Cross-compiling a Windows clang.exe (and other tools) from a Linux
(or
> > other host) box.
>
> I have no idea how cross-compiling from other OS can solve shortcomings
> on the *runtime* libraries of a toolchain.
>
> [snip]
>
> > I *really* don't want to spend lots of time going
> > there because it seems like a low-value platform, but we can.
>
> Thanks, I knew that you consider MinGW* "low-value" all along.
MinGW-w64
> is well ahead of MSVC++ on C++ language and library support, and it is
> very likely that it will remain that way, but you take every chance to
> bad-mouth it to promote MSVC++ support on LLVM/Clang.
>
> [snip]
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140924/089c679b/attachment.html>

Szabolcs Nagy <nsz at port70.net> writes:
> * ?scar Fuentes <ofv at wanadoo.es> [2014-09-24 14:35:17 +0200]:
>> MinGW(-w64) is not about compiling "portable" Linux software
on Windows,
>> it is about compiling Windows API/CRT software on Windows, just like
the
>> MSVC++ toolchain.
>
> the problem with mingw is that it does not implement the posix
Why should MinGW support POSIX? It is a Windows toolchain. Is it a
problem that MSVC++ does not support POSIX too?
> api and
> thus code is littered with ifdefs or abstraction layers (which are
> usually broken), llvm has its own share of ugly and broken ifdefs
A library is portable when it runs on top of the target APIs, not when
it requires to install emulation layers that force the library user to
migrate his software to that emulation layer.

[snip]

"writeonce at midipix.org"
<writeonce at midipix.org> writes:
> One important point you seem to be missing is the ability to
> cross-compile API/CRT software on Windows with a clang.exe which does
> not depend on msvcrt.exe.
Why we would want to do that? (Moreover, considering that LLVM/Clang is
expected to work with MSVC++ which, obviously, depends on msvcrt as
MinGW does.)
>  From a technical perspective (and also with
> respect to many of its goals), the project differs from Cygwin in
> virtually every possible way (some key differences, as well as the
> distinction between mingw as a target and a libc++ _for_ mingw, can be
> found in my original message).
Let's see. Suppossing a LLVM/libClang that uses that libc on Windows, my
software that links to LLVM/libClang must use libc too, right?

Hi,

C++11 <thread> and <mutex> are the issues. Chandler (as others)
would like
to start using <thread> and <mutex> in llvm instead of working
around them.
Since mingw.org and mingw-w64-win32 (threads) do not provide these they
would not be able to compile llvm/clang. However there is no reason to stop
supporting mingw-w64-posix which is modern gcc based and does support
<thread> and <mutex>.

Yaron


2014-09-24 17:21 GMT+03:00 Óscar Fuentes <ofv at wanadoo.es>:
> Yaron Keren <yaron.keren at gmail.com>
> writes:
>
> Hello Yaron,
>
> > The question is should llvm start using <thread> and
<mutex> when
> > mingw+win32 threads does not support these.
> >
> > What is the reason to use mingw+win32 threads instead of
mingw+pthreads
> > which does support the above?
>
> My understanding is that Chandler is talking about the difficulties of
> supporting MinGW because its dependence on winpthreads (wich does not
> provide a functional <thread> etc). It seems that Chandler is not
aware
> of the existence of mingw-w64+pthreads, because both mentioned use cases
> (not depending on MSVC++ and cross-compiling from other OS) are
> perfectly ok with mingw-w64+pthreads.
>
> So I see Chandler's question as a proposal for ditching MinGW(-w64)
> support, sorry if that interpretation was wrong.
>
> We have discussed MinGW support on the past and the consensus what that
> the right thing is to switch to MinGW-w64. If we refine the requirement
> as MinGW-w64+pthreads, that looks reasonable to me.
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140924/f5bb5e11/attachment.html>

Yaron Keren <yaron.keren at gmail.com> writes:
> C++11 <thread> and <mutex> are the issues. Chandler (as others)
would like
> to start using <thread> and <mutex> in llvm instead of working
around them.
> Since mingw.org and mingw-w64-win32 (threads) do not provide these they
> would not be able to compile llvm/clang. However there is no reason to stop
> supporting mingw-w64-posix which is modern gcc based and does support
> <thread> and <mutex>.
Exactly, mingw-w64-posix fits the bill, so let's switch to it. We must
update the docs (I can do that), update the bots... and that's it,
right?

Apparently in a quest for brevity I left too much ambiguous. Some
clarifying points:

1) I had tried to make it clear with the subject, but this *only* applies
to MinGW toolchains shipping without C++11 <thread> and <mutex>
support.
That means (from the limited information available in their documentation)
that mingw-w64 is fine, and even mingw when using thread-posix is fine.

2) When I listed my use cases, I meant the use cases for the *specific*
narrow set of non-C++11 <thread> providing toolchains. There are many good
and valid uses cases for MinGW in general, I just didn't see the need to
enumerate them. But for whatever reasons, some folks are avoiding the more
modern MinGW toolchains, and I think we need to understand why.


On Wed, Sep 24, 2014 at 5:47 AM, Óscar Fuentes <ofv at wanadoo.es> wrote:
> Chandler Carruth <chandlerc at gmail.com> writes:
> > 2) Cross-compiling a Windows clang.exe (and other tools) from a Linux
(or
> > other host) box.
>
> I have no idea how cross-compiling from other OS can solve shortcomings
> on the *runtime* libraries of a toolchain.
>
? The use case is "why mingw + threads-win32"; we just need some
alternative strategy for addressing this use case. If mingw-w64 were a
viable alternative, I have to assume that people would already be using it
(it's been around and working well for ages). So I'm trying to find yet
another alternative way to address the use case.

>
> [snip]
>
> > I *really* don't want to spend lots of time going
> > there because it seems like a low-value platform, but we can.
>
> Thanks, I knew that you consider MinGW* "low-value" all along.

Not at all! What I don't think has high value is trying to add libc++
support to a variant of mingw which seems stalled and not going anywhere.
But that is just one variant! There are a ton of high-value mingw-based
systems, such as mingw-w64. But none of those *need* libc++ because they
have a reasonable modern and high quality C++11 standard library already. =]
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140924/70ed03e2/attachment.html>

On Wed, Sep 24, 2014 at 10:37 AM, Óscar Fuentes <ofv at wanadoo.es> wrote:
> The best thing for understanding their reasons is to ask them to speak
> up.
>
I asked them directly, and this thread is a chance for them to speak up
again. I *think* I've addressed the concerns of those I've spoken to
directly, but there may be other folks or other concerns or I may have
messed it up. =]

> My experience on the MinGW/MinGW-w64 communities is that those who
> choose MinGW is because of ignorance about MinGW-w64 and because there
> are lots of documents on the 'net that references MinGW. MinGW is, to
> all practical effects, a zombie project and there is no reason to prefer
> it over MinGW-w64 nowadays.
>
:: shrug ::

I'm not such a user, and so I don't want to speculate as to what
motivates
them.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140924/5fc7bb6a/attachment.html>

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 libpthreads' implementation of mutex.  I had checked the
source, and indeed, it looked not very efficient (
http://sourceforge.net/p/mingw-w64/bugs/344).  It would be nice to get a
second opinion, though, maybe I missed something.

Vadim


On Wed, Sep 24, 2014 at 10:55 AM, Chandler Carruth <chandlerc at
google.com>
wrote:
>
> On Wed, Sep 24, 2014 at 10:37 AM, Óscar Fuentes <ofv at wanadoo.es>
wrote:
>
>> The best thing for understanding their reasons is to ask them to speak
>> up.
>>
>
> I asked them directly, and this thread is a chance for them to speak up
> again. I *think* I've addressed the concerns of those I've spoken
to
> directly, but there may be other folks or other concerns or I may have
> messed it up. =]
>
>
>> My experience on the MinGW/MinGW-w64 communities is that those who
>> choose MinGW is because of ignorance about MinGW-w64 and because there
>> are lots of documents on the 'net that references MinGW. MinGW is,
to
>> all practical effects, a zombie project and there is no reason to
prefer
>> it over MinGW-w64 nowadays.
>>
>
> :: shrug ::
>
> I'm not such a user, and so I don't want to speculate as to what
motivates
> them.
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140924/df878b17/attachment.html>