[PATCH] D11059: [OPENMP] Info in release notes about OpenMP support in clang.

[Hans Wennborg]

hans added a comment.

In http://reviews.llvm.org/D11059#211509, @andreybokhanko wrote:

> In http://reviews.llvm.org/D11059#210215, @hans wrote:
>
> > -fopenmp=libomp?
>
>
> This one works "out of the box" indeed (provided a user has runtime library available). As I see, Alexey updated his patch to reflect this.


Great.

> In http://reviews.llvm.org/D11059#210215, @hans wrote:

> 

> > Where is the user supposed to get the runtime lib from? It's not currently part of the pre-built binaries that ship as part of the release.

> 

> 

> OpenMP runtime sources (along with build instructions) is a part of llvm release since 3.5. As I understand, only core clang + llvm compilers are supplied as pre-built binaries, the rest is in source code only.


compiler-rt, libc++ and other libraries which integrate nicely with the LLVM build are also part of the pre-built binaries, modulo platform support.

I have a patch at http://reviews.llvm.org/D11494 that would facilitate building the run-time as part of the release process and shipping it as a separate download on the release page. I think that would make it easier for users who wish to experiment with Clang's OpenMP support.

In http://reviews.llvm.org/D11059#211558, @jhowarth wrote:

> So is the default of -fopenmp=libgomp going to be left in place just for the 3.7.0 release or for all future 3.7.x maintenance releases?


The maintenance releases only contain bug fixes. I don't think changing this flag would be in scope.

> Frankly this decision to favor a non-functional OpenMP implementation over own own OpenMP library is baffling if the goal it to get widespread testing of this new feature.


Baffling or not, that is still the state on trunk, and I haven't seen any discussion or patches towards changing it. If nothing changes on trunk, there's nothing to consider for merging to 3.7.


http://reviews.llvm.org/D11059