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

[Hans Wennborg]

Hi Jack,

On Fri, Jul 17, 2015 at 6:46 AM, Jack Howarth
<howarth.mailing.lists at 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 <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