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