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

[Nikola Smiljanic]

i686-pc-linux-gnu

I can attach more logs if you need them?

On Wed, Jul 22, 2015 at 10:36 AM, Hans Wennborg <hans at chromium.org> wrote:

> But not phase 1? Interesting. What target does clang --version on the
> phase 1 compiler print?
>
> On Tue, Jul 21, 2015 at 3:36 PM, Nikola Smiljanic <popizdeh at gmail.com>
> wrote:
> > 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/97a3c23e/attachment.html>