RFC: LLVM should require a working C++11 <thread>, <mutex>, and <atomic>

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
34 messages Options
12
Reply | Threaded
Open this post in threaded view
|

RFC: LLVM should require a working C++11 <thread>, <mutex>, and <atomic>

Chandler Carruth
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
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: RFC: LLVM should require a working C++11 <thread>, <mutex>, and <atomic>

Mueller-Roemer, Johannes Sebastian

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

[hidden email]  |  www.igd.fraunhofer.de

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Chandler Carruth
Sent: Wednesday, September 24, 2014 03:02
To: LLVM Developers Mailing List; clang-dev Developers; [hidden email]; 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
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: RFC: LLVM should require a working C++11 <thread>, <mutex>, and <atomic>

Yaron Keren
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 <[hidden email]>:

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

[hidden email]  |  www.igd.fraunhofer.de

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Chandler Carruth
Sent: Wednesday, September 24, 2014 03:02
To: LLVM Developers Mailing List; clang-dev Developers; [hidden email]; 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
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: RFC: LLVM should require a working C++11 <thread>, <mutex>, and <atomic>

Mueller-Roemer, Johannes Sebastian

<atomic> should work both in win32 and pthread versions of MinGW. <mutex> and <thread> are only supported in the pthread version though.

 

--

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

[hidden email]  |  www.igd.fraunhofer.de

 

From: Yaron Keren [mailto:[hidden email]]
Sent: Wednesday, September 24, 2014 11:56
To: Mueller-Roemer, Johannes Sebastian
Cc: Chandler Carruth; LLVM Developers Mailing List; clang-dev Developers; [hidden email]; Chris Bieneman; Reid Kleckner; David Majnemer; Alex Rosenberg; Zachary Turner
Subject: Re: [LLVMdev] RFC: LLVM should require a working C++11 <thread>, <mutex>, and <atomic>

 

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 <[hidden email]>:

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

[hidden email]  |  www.igd.fraunhofer.de

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Chandler Carruth
Sent: Wednesday, September 24, 2014 03:02
To: LLVM Developers Mailing List; clang-dev Developers; [hidden email]; 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
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

 


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] RFC: LLVM should require a working C++11 <thread>, <mutex>, and <atomic>

writeonce@midipix.org
In reply to this post by Chandler Carruth
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


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: RFC: LLVM should require a working C++11 <thread>, <mutex>, and <atomic>

Óscar Fuentes
In reply to this post by Chandler Carruth
Chandler Carruth <[hidden email]> 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
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] RFC: LLVM should require a working C++11 <thread>, <mutex>, and <atomic>

Szabolcs Nagy
In reply to this post by writeonce@midipix.org
* ?scar Fuentes <[hidden email]> [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)
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] RFC: LLVM should require a working C++11 <thread>, <mutex>, and <atomic>

writeonce@midipix.org
In reply to this post by writeonce@midipix.org
On 09/24/2014 08:35 AM, Óscar Fuentes wrote:

> "[hidden email]"
> <[hidden email]> 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).

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: RFC: LLVM should require a working C++11 <thread>, <mutex>, and <atomic>

Yaron Keren
In reply to this post by Óscar Fuentes
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 <[hidden email]>:
Chandler Carruth <[hidden email]> 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
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: RFC: LLVM should require a working C++11 <thread>, <mutex>, and <atomic>

Óscar Fuentes
In reply to this post by Szabolcs Nagy
Szabolcs Nagy <[hidden email]> writes:

> * ?scar Fuentes <[hidden email]> [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]

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: RFC: LLVM should require a working C++11 <thread>, <mutex>, and <atomic>

Óscar Fuentes
In reply to this post by writeonce@midipix.org
"[hidden email]"
<[hidden email]> 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?

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: RFC: LLVM should require a working C++11 <thread>, <mutex>, and <atomic>

Mueller-Roemer, Johannes Sebastian
In reply to this post by Yaron Keren

You don’t have to distribute libwinpthread.dll with your application. Considering that libwinpthread is approx. 50 KiB, that’s not much of a reason. “Classic” MinGW doesn’t have it AFAIK, but who uses that instead of MinGW-w64 nowadays?

 

--

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

[hidden email]  |  www.igd.fraunhofer.de

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Yaron Keren
Sent: Wednesday, September 24, 2014 15:32
To: Óscar Fuentes
Cc: [hidden email]; [hidden email] Developers; LLVM Developers Mailing List
Subject: Re: [LLVMdev] RFC: LLVM should require a working C++11 <thread>, <mutex>, and <atomic>

 

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 <[hidden email]>:

Chandler Carruth <[hidden email]> 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
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

 


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] RFC: LLVM should require a working C++11 <thread>, <mutex>, and <atomic>

Yaron Keren
In reply to this post by Yaron Keren
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 <[hidden email]>:
Yaron Keren <[hidden email]>
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
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [cfe-dev] RFC: LLVM should require a working C++11 <thread>, <mutex>, and <atomic>

Óscar Fuentes
Yaron Keren <[hidden email]> 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?

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: RFC: LLVM should require a working C++11 <thread>, <mutex>, and <atomic>

David Chisnall-5
In reply to this post by Mueller-Roemer, Johannes Sebastian
On 24 Sep 2014, at 05:59, Mueller-Roemer, Johannes Sebastian <[hidden email]> 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 with some quite sane primitives for implementing <mutex> and <thread>, so it would only be 1-2 days of work for someone to write the implementation for libc++.

I'd suggest that the total effort that has gone into this thread so far is close to the amount of effort required to add the missing support...

David


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: RFC: LLVM should require a working C++11 <thread>, <mutex>, and <atomic>

Óscar Fuentes
David Chisnall <[hidden email]> writes:

> <atomic> is trivial, as most of the support is provided by the
> compiler. As of Vista, Windows comes with some quite sane primitives
> for implementing <mutex> and <thread>, so it would only be 1-2 days of
> work for someone to write the implementation for libc++.

Forcing Clang to depend on libc++ makes things quite complicated for the
end user. For the Windows case, building Clang without cross-compiling
could be impossible, if it requires that libc++ must be compiled by
Clang.

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: RFC: LLVM should require a working C++11 <thread>, <mutex>, and <atomic>

Anton Korobeynikov-2
In reply to this post by David Chisnall-5
Also, can't we simply provide some dummy <mutex> / <thread> on mingw
systems and warn loudly about single-threaded stuff?

This was a precedent actually - when LLVM started to use atomics,
everyone w/o them ended with non-reentrant LLVM and everything was ok.

On Wed, Sep 24, 2014 at 7:00 PM, David Chisnall
<[hidden email]> wrote:

> On 24 Sep 2014, at 05:59, Mueller-Roemer, Johannes Sebastian <[hidden email]> 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 with some quite sane primitives for implementing <mutex> and <thread>, so it would only be 1-2 days of work for someone to write the implementation for libc++.
>
> I'd suggest that the total effort that has gone into this thread so far is close to the amount of effort required to add the missing support...
>
> David
>
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



--
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: RFC: LLVM should require a working C++11 <thread>, <mutex>, and <atomic>

Jonathan Roelofs


On 9/24/14 10:20 AM, Anton Korobeynikov wrote:
> Also, can't we simply provide some dummy <mutex> / <thread> on mingw
> systems and warn loudly about single-threaded stuff?
<mutex> shouldn't be too painful to have a single-threaded shim for. <thread>
and <future> on the other hand seemed like a bit of a nightmare when I looked at
them for the LIBCPP_HAS_NO_THREADS work. It might be good for someone else to
look into it and give their opinion.


Cheers,

Jon

>
> This was a precedent actually - when LLVM started to use atomics,
> everyone w/o them ended with non-reentrant LLVM and everything was ok.
>
> On Wed, Sep 24, 2014 at 7:00 PM, David Chisnall
> <[hidden email]> wrote:
>> On 24 Sep 2014, at 05:59, Mueller-Roemer, Johannes Sebastian <[hidden email]> 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 with some quite sane primitives for implementing <mutex> and <thread>, so it would only be 1-2 days of work for someone to write the implementation for libc++.
>>
>> I'd suggest that the total effort that has gone into this thread so far is close to the amount of effort required to add the missing support...
>>
>> David
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> [hidden email]         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>

--
Jon Roelofs
[hidden email]
CodeSourcery / Mentor Embedded
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: RFC: LLVM should require a working C++11 <thread>, <mutex>, and <atomic>

Chandler Carruth-2
In reply to this post by Óscar Fuentes
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 <[hidden email]> wrote:
Chandler Carruth <[hidden email]> 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. =]

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: RFC: LLVM should require a working C++11 <thread>, <mutex>, and <atomic>

Chandler Carruth-2
In reply to this post by Óscar Fuentes

On Wed, Sep 24, 2014 at 8:48 AM, Óscar Fuentes <[hidden email]> wrote:
David Chisnall <[hidden email]> writes:

> <atomic> is trivial, as most of the support is provided by the
> compiler. As of Vista, Windows comes with some quite sane primitives
> for implementing <mutex> and <thread>, so it would only be 1-2 days of
> work for someone to write the implementation for libc++.

Forcing Clang to depend on libc++ makes things quite complicated for the
end user. For the Windows case, building Clang without cross-compiling
could be impossible, if it requires that libc++ must be compiled by
Clang.

The only way Clang would depend on libc++ is if you weren't able or willing to use one of the other host toolchains to cross to windows. Both mingw-w64 and the threads-posix stuff which supports C++11 <thread> would work fine as well.

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
12