Hi Jack, On Fri, Jul 17, 2015 at 6:46 AM, Jack Howarth <howarth.mailing.li...@gmail.com> wrote: > Hans, > This change is required because Chandler reverted the OpenMP > developers original commit that enabled clang to default to the new > OpenMP with... > > http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20150518/129487.html > > The major complaints with the cmake support for OpenMP have been addressed > in... > > http://lists.cs.uiuc.edu/pipermail/openmp-commits/2015-July/000441.html > http://lists.cs.uiuc.edu/pipermail/openmp-commits/2015-July/000442.html > > as well as in prior commits which addressed the cmake variable naming > convention issues.
Thank you for the links. It's not me you need to convince though. As I said before, the change would have to be committed to trunk first, and then I'm open to consider merging it. Thanks, Hans > On Thu, Jul 16, 2015 at 7:14 PM, Hans Wennborg <h...@chromium.org> wrote: >> Hi Jack, >> >> On Thu, Jul 16, 2015 at 4:03 PM, Jack Howarth >> <howarth.mailing.li...@gmail.com> wrote: >>> Hans, >>> Do we intend to leave -fopenmp defaulted to the no-op libgomp >>> support for 3.7.0 or do the sensible thing by applying... >>> >>> Index: CMakeLists.txt >>> =================================================================== >>> --- CMakeLists.txt (revision 242425) >>> +++ CMakeLists.txt (working copy) >>> @@ -182,7 +182,7 @@ set(GCC_INSTALL_PREFIX "" CACHE PATH "Di >>> set(DEFAULT_SYSROOT "" CACHE PATH >>> "Default <path> to all compiler invocations for --sysroot=<path>." ) >>> >>> -set(CLANG_DEFAULT_OPENMP_RUNTIME "libgomp" CACHE STRING >>> +set(CLANG_DEFAULT_OPENMP_RUNTIME "libomp" CACHE STRING >>> "Default OpenMP runtime used by -fopenmp.") >>> >>> set(CLANG_VENDOR "" CACHE STRING >>> >>> so that the new llvm openmp library (which passes a three stage >>> bootstrap as part of an >>> in-tree build of llvm/cfe/compiler-rt/polly/libc++/openmp on >>> x86_64-apple-darwin). >> >> I'm not fully aware of the implications of this, but if we do want to >> change it, it needs to be done on trunk first. >> >> If you get it through review and committed to trunk, I'm open to merging it. >> >> I assume utils/release/test-release.sh would also need an update so >> the library gets built? >> >> Thanks, >> Hans _______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
