[LLVMdev] [3.7 Release] RC1 has been tagged, Testing Phase I begins

[Jack Howarth]

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(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