[LLVMdev] [3.7 Release] RC1 has been tagged, Testing Phase I begins (original) (raw)

Jack Howarth howarth.mailing.lists at gmail.com
Fri Jul 17 06:46:50 PDT 2015


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. Otherwise, the release notes for 3.7.0 will have to explain why we don't trust our own fully functional OpenMP 3.1 support to the point that we choose to default to non-functional libgomp support. Note that the -fopenmp currently implies -fopenmp=libgomp which doesn't generate any code for OpenMP support is thus simple serial execution. Jack

On Thu, Jul 16, 2015 at 7:14 PM, Hans Wennborg <hans at chromium.org> wrote:

Hi Jack,

On Thu, Jul 16, 2015 at 4:03 PM, Jack Howarth <howarth.mailing.lists at 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(GCCINSTALLPREFIX "" CACHE PATH "Di set(DEFAULTSYSROOT "" CACHE PATH "Default to all compiler invocations for --sysroot=." ) -set(CLANGDEFAULTOPENMPRUNTIME "libgomp" CACHE STRING +set(CLANGDEFAULTOPENMPRUNTIME "libomp" CACHE STRING "Default OpenMP runtime used by -fopenmp.") set(CLANGVENDOR "" 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 x8664-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



More information about the llvm-dev mailing list