The CMakeLists.txt change cited is in top-level of the clang sources and not in the llvm top-level.

The proposed patches here to change the default behavior of -fopenmp from -fopenmp=libgomp to -fopenmp=libomp seem to only handle the configure-based build. The following change required to switch over the crake-based build to default -fopenmp to libomp is missing.

One other issue. It appears that the tolerances used in runtime/test/api/omp_get_wtime.c are too tight for OS X 10.11. With or without SIP enabled, I get a return code between 2 to 6 on that test. Opening it up to...

There is one issue with rL248211. On darwin, the check-libomp test suite run depends on DYLD_LIBRARY_PATH being passed along through make. This isn't true in El Capitan due to the System Integrity Protection pruning of DYLD_LIBRARY_PATH.

Can we get a back port of Commit rL248211 to the openmp 3.7 release branch for the 3.7.1 release? It applies cleanly here over openmp 3.7.0 and shows perfect results...

Also, if we are going to leave the default for CLANG_DEFAULT_OPENMP_RUNTIME set to libgomp, wouldn't it be better to at least modify cfe-3.7.0.src/CMakeLists.txt so that the user could pass -DCLANG_DEFAULT_OPENMP_RUNTIME=libomp to override that default in their own builds of 3.7.0 rather than forcing them to invoke -fopenmp=libomp? Currently we lock them into this unless they manually edit the CMakeLists.txt.

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? 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.

For comparison, the results from the ctest of OpenMP3.1_Validation test suite using the current -fopenmp=libgomp default in 3.7.0 branch are very poor as expected since clang doesn't emit any OpenMP code generation for the libgomp case...

The completeness of the OpenMP 3.1 support in 3.7.0 branch can be seen on x86_64-apple-darwin by using it to run the ctest of OpenMP3.1_Validation test suite from http://web.cs.uh.edu/~hpctools/openmp...

Commit rL242298 still needs to be applied to the openmp 3.7.0 branch as well.

If this misses the branching of 3.7.0, it should be committed to both trunk and 3.7.0 branch.

I can confirm that the ID 29582 version of the proposed patch eliminates the regression on x86_64-apple-darwin14.

The 29443 version of the patch causes the following regression on x86_64-apple-darwin14...

runtime/CMakeLists.txt in 29380 doesn't apply cleanly to current openmp svn...

So are we close to completion with the review process or is there more bikeshedding to be done?

The r241832 and r241833 commits seem to have spoiled the context for applying the proposed cmake overhaul patch.

No problem here applying...

FYI, I have built current openmp trunk with the the third permutation of the cmake overhaul applied as part of an in-tree llvm/clang/compiler-rt/libc++/polly cmake build using a 3-stage bootstrap with stage2/stage3 comparison of binaries on x86_64-apple-darwin13/14/15. The only minor nit I found was that three files should differences between stage2/stage3 due to the timestamps added by

-- stage2/projects/openmp/runtime/src/kmp_i18n_default.inc	2015-07-04 17:04:13.000000000 -0400
+++ stage3/projects/openmp/runtime/src/kmp_i18n_default.inc	2015-07-04 17:28:37.000000000 -0400
@@ -1,5 +1,5 @@
 // Do not edit this file! //
-// The file was generated from en_US.txt by message-converter.pl on Sat Jul  4 17:04:13 2015. //
+// The file was generated from en_US.txt by message-converter.pl on Sat Jul  4 17:28:37 2015. //

Also note that -fopenmp=libomp clang doesn't emit the necessary linkage path to find libomp when llvm/clang/compiler-rt/openmp is built with -DCMAKE_INSTALL_PREFIX set to a buried directory like /opt/local/llvm-3.7.

I am not having any luck with this proposed patch. Building current llvm/clang/openmp/compiler-rt trunk with it produces a compiler that always defaults to emitting -lgomp for -fopenmp even if cmake is explicitly passed -DENABLE_CLANG_OPENMP=ON.

This change caused a 24% performance regression in the SciMark2's Sparse matmult benchmark on Bloomfield processors and 12% on Harpertown processors with "-O3 -march=native" generating identical assembly in both cases. This issue is filed at http://llvm.org/bugs/show_bug.cgi?id=22589 and appears to be due to the increased register pressure introduced by the newly exposed optimizations causing spills. This issue is processor-specific and the regression is minimal on other processors like Haswell due to their additional registers (at least for this specific test case).