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

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

CMake Error at projects/compiler-rt/cmake/config-ix.cmake:125 (message):
Cannot compile for i686

CMakeError.log attached, seems like #include checks are failing? This is
x86 openSUSE.

On Fri, Jul 17, 2015 at 9:14 AM, 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150717/481c9d6c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CMakeError.log.zip
Type: application/zip
Size: 6498 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150717/481c9d6c/attachment.zip>

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

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

Seems on OpenSUSE x86, it's called i586, not i686 :-(

+Alexey: do you think we can handle this in the compiler-rt cmake
files somehow? Maybe try targeting both i686 and i586 unless that
would break something else?

On Fri, Jul 17, 2015 at 1:31 AM, Nikola Smiljanic <popizdeh at gmail.com>
wrote:
> CMake Error at projects/compiler-rt/cmake/config-ix.cmake:125 (message):
> Cannot compile for i686
>
> CMakeError.log attached, seems like #include checks are failing? This is
x86
> openSUSE.
>
> On Fri, Jul 17, 2015 at 9:14 AM, 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
>
>