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

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

The problem is we "guess" that the host architecture is i686, and fail
when
we find out that we can't target it (__i686__ is not defined).
This guess originates from get_host_triple() call
in cmake/modules/GetHostTriple.cmake.
Probably, it makes sense to fix that to return i568 on openSUSE, and then
test for i586 in the same way we already test for i386/i686.


On Fri, Jul 17, 2015 at 11:23 AM, Hans Wennborg <hans at chromium.org>
wrote:
> 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
> >
> >
>


-- 
Alexey Samsonov
vonosmas at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150721/ac0b9854/attachment.html>

Building phase 2 fails on i686 Fedora 22

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

CMakeError.log attached

On Wed, Jul 22, 2015 at 8:20 AM, Alexey Samsonov <vonosmas at gmail.com>
wrote:
> The problem is we "guess" that the host architecture is i686, and
fail
> when we find out that we can't target it (__i686__ is not defined).
> This guess originates from get_host_triple() call
> in cmake/modules/GetHostTriple.cmake.
> Probably, it makes sense to fix that to return i568 on openSUSE, and then
> test for i586 in the same way we already test for i386/i686.
>
>
> On Fri, Jul 17, 2015 at 11:23 AM, Hans Wennborg <hans at
chromium.org> wrote:
>
>> 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
>> >
>> >
>>
>
>
>
> --
> Alexey Samsonov
> vonosmas at gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150722/b0d7760c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CMakeError.log.zip
Type: application/zip
Size: 5321 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150722/b0d7760c/attachment.zip>