[LLVMdev] [3.7 Release] RC1 has been tagged, Testing Phase I begins (original) (raw)

Nikola Smiljanic popizdeh at gmail.com
Wed Jul 22 01:41:27 PDT 2015

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 gethosttriple() 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(GCCINSTALLPREFIX "" CACHE PATH "Di >>> >> > set(DEFAULTSYSROOT "" CACHE PATH >>> >> > "Default to all compiler invocations for >>> >> > --sysroot=." ) >>> >> > >>> >> > -set(CLANGDEFAULTOPENMPRUNTIME "libgomp" CACHE STRING >>> >> > +set(CLANGDEFAULTOPENMPRUNTIME "libomp" CACHE STRING >>> >> > "Default OpenMP runtime used by -fopenmp.") >>> >> > >>> >> > set(CLANGVENDOR "" 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 >>> >> > x8664-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>

More information about the llvm-dev mailing list