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 _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
