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

Dear testers,

3.7.0-rc1 was just tagged; please start your testing engines :-)

Upload binaries to the sftp and report your results to this thread.

I'm sorry for the delay between branching and tagging. The changes to
the release script took a little longer than I hoped.

Thanks for helping with the release, and do let me know of any issues,
questions, etc.

The tracking bug for release blockers is PR24126.

Cheers,
Hans

On 17 Jul 2015, at 00:31, Hans Wennborg <hans at chromium.org>
wrote:
> 
> Dear testers,
> 
> 3.7.0-rc1 was just tagged; please start your testing engines :-)
> 
> Upload binaries to the sftp and report your results to this thread.
> 
> I'm sorry for the delay between branching and tagging. The changes to
> the release script took a little longer than I hoped.
> 
> Thanks for helping with the release, and do let me know of any issues,
> questions, etc.
> 
> The tracking bug for release blockers is PR24126.
Is it OK to do an autoconf build?  The CMake build tries to build various
components which do not yet work on FreeBSD, e.g. libcxxabi does not compile at
all, libcompiler-rt has a bunch of test failures, etc.  Alternatively, can I
disable these components in the CMake build locally?

-Dimitry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: Message signed with OpenPGP using GPGMail
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150717/6366af45/attachment.sig>

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).
                   Jack

On Thu, Jul 16, 2015 at 6:31 PM, Hans Wennborg <hans at chromium.org>
wrote:
> Dear testers,
>
> 3.7.0-rc1 was just tagged; please start your testing engines :-)
>
> Upload binaries to the sftp and report your results to this thread.
>
> I'm sorry for the delay between branching and tagging. The changes to
> the release script took a little longer than I hoped.
>
> Thanks for helping with the release, and do let me know of any issues,
> questions, etc.
>
> The tracking bug for release blockers is PR24126.
>
> Cheers,
> Hans
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

On Thu, Jul 16, 2015 at 3:47 PM, Dimitry Andric <dimitry at andric.com>
wrote:
> On 17 Jul 2015, at 00:31, Hans Wennborg <hans at chromium.org> wrote:
>>
>> Dear testers,
>>
>> 3.7.0-rc1 was just tagged; please start your testing engines :-)
>>
>> Upload binaries to the sftp and report your results to this thread.
>>
>> I'm sorry for the delay between branching and tagging. The changes
to
>> the release script took a little longer than I hoped.
>>
>> Thanks for helping with the release, and do let me know of any issues,
>> questions, etc.
>>
>> The tracking bug for release blockers is PR24126.
>
> Is it OK to do an autoconf build?  The CMake build tries to build various
components which do not yet work on FreeBSD, e.g. libcxxabi does not compile at
all, libcompiler-rt has a bunch of test failures, etc.  Alternatively, can I
disable these components in the CMake build locally?
Yes, go ahead and use the autoconf build.

Can you send a patch to test-release.sh that makes this default for
FreeBSD? It's already the default for Darwin.

Thanks,
Hans

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

We're missing libunwind from the list of projects in 3.7.

The current way libcxxabi builds depends on libunwin (looking for
libunwind.h), so we need to tag libunwind, check it out in the script
and build it together.

For now, I'll disable libcxx from my build, but it would be good to
have it on later, so we can test it with the rest, too.

cheers,
--renato

On 16 July 2015 at 23:31, Hans Wennborg <hans at chromium.org>
wrote:
> Dear testers,
>
> 3.7.0-rc1 was just tagged; please start your testing engines :-)
>
> Upload binaries to the sftp and report your results to this thread.
>
> I'm sorry for the delay between branching and tagging. The changes to
> the release script took a little longer than I hoped.
>
> Thanks for helping with the release, and do let me know of any issues,
> questions, etc.
>
> The tracking bug for release blockers is PR24126.
>
> Cheers,
> Hans

Hi Renato,

On Fri, Jul 17, 2015 at 6:42 AM, Renato Golin <renato.golin at linaro.org>
wrote:
> We're missing libunwind from the list of projects in 3.7.
>
> The current way libcxxabi builds depends on libunwin (looking for
> libunwind.h), so we need to tag libunwind, check it out in the script
> and build it together.
>
> For now, I'll disable libcxx from my build, but it would be good to
> have it on later, so we can test it with the rest, too.
I've created the branch and rc1 tag for libunwind, and included it in
the scripts in r242543. Let me know how it works out.

Thanks,
Hans

> On 16 July 2015 at 23:31, Hans Wennborg <hans at chromium.org> wrote:
>> Dear testers,
>>
>> 3.7.0-rc1 was just tagged; please start your testing engines :-)
>>
>> Upload binaries to the sftp and report your results to this thread.
>>
>> I'm sorry for the delay between branching and tagging. The changes
to
>> the release script took a little longer than I hoped.
>>
>> Thanks for helping with the release, and do let me know of any issues,
>> questions, etc.
>>
>> The tracking bug for release blockers is PR24126.
>>
>> Cheers,
>> Hans

On 16 July 2015 at 23:31, Hans Wennborg <hans at chromium.org>
wrote:
> 3.7.0-rc1 was just tagged; please start your testing engines :-)
>
> Upload binaries to the sftp and report your results to this thread.
ARMv7 with Compiler-RT up. There were unexpected passes on the
sanitizer, but that's ok.

I'm running tests and benchmarks now, but people can already try it
out if they want.

AArch64 will come early next week.

cheers,
--renato

Hi Hans, 
      Test Result Report:  Ubuntu 15.04 AMD64 3.7.0-RC1 release . Everything
works fine without any problem.
      
       SFTP Upload: Not done yet. Since do not have the SFTP access information.


Kun Ling
  

------------------ Original ------------------
From:  "Hans Wennborg"<hans at chromium.org>;
Date:  Thu, Jul 16, 2015 02:31 PM
To:  "llvmdev"<llvmdev at cs.uiuc.edu>;
"cfe-dev"<cfe-dev at cs.uiuc.edu>;
"lldb-dev"<lldb-dev at cs.uiuc.edu>;
Cc:  "Ben Pope"<benpope81 at gmail.com>; "Pavel
Labath"<labath at google.com>; "Nikola
Smiljanić"<popizdeh at gmail.com>;
Subject:  [LLVMdev] [3.7 Release] RC1 has been tagged, Testing Phase I begins

 
Dear testers,

3.7.0-rc1 was just tagged; please start your testing engines :-)

Upload binaries to the sftp and report your results to this thread.

I'm sorry for the delay between branching and tagging. The changes to
the release script took a little longer than I hoped.

Thanks for helping with the release, and do let me know of any issues,
questions, etc.

The tracking bug for release blockers is PR24126.

Cheers,
Hans
_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150719/004905c7/attachment.html>

On Friday, July 17, 2015 06:31 AM, Hans Wennborg wrote:
> Dear testers,
>
> 3.7.0-rc1 was just tagged; please start your testing engines :-)
>
> Upload binaries to the sftp and report your results to this thread.
>
> I'm sorry for the delay between branching and tagging. The changes to
> the release script took a little longer than I hoped.
>
> Thanks for helping with the release, and do let me know of any issues,
> questions, etc.
On Ubuntu 14.04 x64 (with cmake) I get these failures at Phase3 and no 
tarball:

Failing Tests (18):
     AddressSanitizer-x86_64-linux :: TestCases/Posix/readv.cc
     MemorySanitizer :: Linux/tcgetattr.cc
     MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.gethostent
     MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.gethostent_r
     MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getmntent
     MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getmntent_r
     MemorySanitizer-Unit :: 
Msan-x86_64-with-call-Test/MemorySanitizer.gethostent
     MemorySanitizer-Unit :: 
Msan-x86_64-with-call-Test/MemorySanitizer.gethostent_r
     MemorySanitizer-Unit :: 
Msan-x86_64-with-call-Test/MemorySanitizer.getmntent
     MemorySanitizer-Unit :: 
Msan-x86_64-with-call-Test/MemorySanitizer.getmntent_r
     SanitizerCommon-asan :: Linux/getpass.cc
     SanitizerCommon-asan :: Posix/decorate_proc_maps.cc
     SanitizerCommon-lsan :: Linux/getpass.cc
     SanitizerCommon-msan :: Linux/getpass.cc
     SanitizerCommon-msan :: Linux/signal_segv_handler.cc
     SanitizerCommon-msan :: Posix/decorate_proc_maps.cc
     SanitizerCommon-tsan :: Linux/getpass.cc
     SanitizerCommon-tsan :: Posix/decorate_proc_maps.cc

   Expected Passes    : 24006
   Expected Failures  : 131
   Unsupported Tests  : 377
   Unexpected Failures: 18


Ben

On 19 July 2015 at 09:36, Ben Pope <benpope81 at gmail.com>
wrote:
> On Ubuntu 14.04 x64 (with cmake) I get these failures at Phase3 and no
> tarball:
The tarball is an issue Hans is aware of. We're fixing it.
> Failing Tests (18):
>     AddressSanitizer-x86_64-linux :: TestCases/Posix/readv.cc
Did you use to build compiler-rt on the previous (autoconf) releases?

If not, this might explain why you're only seeing these errors now.

cheers,
--renato

Hi Hans,

I uploaded

    c55199c92877ed068b2f7d1ece6b0bb4f121a63a 
clang+llvm-3.7.0-rc1-x86_64-apple-darwin.tar.xz

to SFTP. Testing was OK except for differences between phase 2 and 3 which I
consider being not harmful (or even: usual). No problem with the build script
here, but OS X also does not use RPATH.

Cheers,
Sebastian
> On 17.07.2015, at 00:31, Hans Wennborg <hans at chromium.org> wrote:
> 
> Dear testers,
> 
> 3.7.0-rc1 was just tagged; please start your testing engines :-)
> 
> Upload binaries to the sftp and report your results to this thread.
> 
> I'm sorry for the delay between branching and tagging. The changes to
> the release script took a little longer than I hoped.
> 
> Thanks for helping with the release, and do let me know of any issues,
> questions, etc.
> 
> The tracking bug for release blockers is PR24126.
> 
> Cheers,
> Hans

Here's the current status for the Mips packages.

With the following source changes to the tag:
* Applied r242331 - Switch the release script to build with CMake by default
(PR21561)
* Applied r242422 - Fixed an error in cuda-options.cu test -target option must
be used without '='.
* Reverted r241599 - Fix bug in test-release.sh where the script would not exit
if any of the build stages that are sent through a pipe (e.g. tee) failed.

And the following change to the resulting packages:
* Move/symlink $package/usr/local/* to $package/*
(Note the packages uploaded are as built by the script and do not have this
change)

clang+llvm-3.7.0-rc1-mips-linux-gnu.tar.xz
        Failing Tests (6):
            AddressSanitizer-mips-linux :: TestCases/Linux/kernel-area.cc
            AddressSanitizer-mips-linux ::
TestCases/Posix/coverage-direct-large.cc
            UBSan-ASan-mips :: TestCases/Float/cast-overflow.cpp
            UBSan-Standalone-mips :: TestCases/Float/cast-overflow.cpp
            libc++abi :: backtrace_test.pass.cpp
            libc++abi :: test_demangle.pass.cpp
        Test-suite: Just started this morning.

clang+llvm-3.7.0-rc1-mipsel-linux-gnu.tar.xz
        Failing Tests (4):
            AddressSanitizer-mipsel-linux :: TestCases/Linux/kernel-area.cc
            Clang :: Modules/prune.m <- expected since this system uses an
NFS mount with noatime.
            libc++abi :: backtrace_test.pass.cpp
            libc++abi :: test_demangle.pass.cpp
            Test-suite: Still running but ok so far.

clang+llvm-3.7.0-rc1-x86_64-linux-gnu-ubuntu-14.04.tar.xz (cross compiling to
Mips):
	Not started since packages not uploaded yet. Presumably due to the packaging
problems discussed elsewhere in this thread.

With the exception of prune.m (which is expected on that machine) the 'make
check-all' failures are all related to projects that weren't built in
the 3.6 releases. It will take a day or two for the test-suite results to finish
since these machines lack an FPU and have to trap-and-emulate. I have a little
endian with an FPU that I can try the test-suite on which should be much faster.
> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at
cs.uiuc.edu]
> On Behalf Of Hans Wennborg
> Sent: 16 July 2015 23:31
> To: llvmdev; cfe-dev; lldb-dev at cs.uiuc.edu
> Cc: Ben Pope; Pavel Labath; Nikola Smiljanić
> Subject: [LLVMdev] [3.7 Release] RC1 has been tagged, Testing Phase I
> begins
> 
> Dear testers,
> 
> 3.7.0-rc1 was just tagged; please start your testing engines :-)
> 
> Upload binaries to the sftp and report your results to this thread.
> 
> I'm sorry for the delay between branching and tagging. The changes to
> the release script took a little longer than I hoped.
> 
> Thanks for helping with the release, and do let me know of any issues,
> questions, etc.
> 
> The tracking bug for release blockers is PR24126.
> 
> Cheers,
> Hans
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

On 18 July 2015 at 15:05, Renato Golin <renato.golin at linaro.org>
wrote:
> ARMv7 with Compiler-RT up. There were unexpected passes on the
> sanitizer, but that's ok.
AArch64 with Compiler-RT up. Both tested with the test-suite, all pass.

cheers,
--renato

On Sat, Jul 18, 2015 at 7:05 AM, Renato Golin <renato.golin at linaro.org>
wrote:
> On 16 July 2015 at 23:31, Hans Wennborg <hans at chromium.org> wrote:
>> 3.7.0-rc1 was just tagged; please start your testing engines :-)
>>
>> Upload binaries to the sftp and report your results to this thread.
>
> ARMv7 with Compiler-RT up.
Thanks!

The file doesn't seem to have -rc1 in the name like the others, but it
does seem to have been built at the rc1 tag. Do you think we can just
rename it?

Thanks,
Hans

Hi Kun,

On Sat, Jul 18, 2015 at 10:19 PM, Kun Ling <kunling at lingcc.com>
wrote:
> Hi Hans,
>       Test Result Report:  Ubuntu 15.04 AMD64 3.7.0-RC1 release .
Everything
> works fine without any problem.
Nice!
>        SFTP Upload: Not done yet. Since do not have the SFTP access
> information.
Anton, can you help Kun get access to the sftp?

Thanks,
Hans

On Sun, Jul 19, 2015 at 11:20 AM,  <sebastian.dressler at gmail.com>
wrote:
> Hi Hans,
>
> I uploaded
>
>     c55199c92877ed068b2f7d1ece6b0bb4f121a63a 
clang+llvm-3.7.0-rc1-x86_64-apple-darwin.tar.xz
>
> to SFTP.
Thanks!
> Testing was OK except for differences between phase 2 and 3 which I
consider being not harmful (or even: usual). No problem with the build script
here, but OS X also does not use RPATH.
Do you have any idea what the diff is though? The script tries hard to
build and compare in a way that should make the builds compare equal.

Thanks,
Hans
>> On 17.07.2015, at 00:31, Hans Wennborg <hans at chromium.org>
wrote:
>>
>> Dear testers,
>>
>> 3.7.0-rc1 was just tagged; please start your testing engines :-)
>>
>> Upload binaries to the sftp and report your results to this thread.
>>
>> I'm sorry for the delay between branching and tagging. The changes
to
>> the release script took a little longer than I hoped.
>>
>> Thanks for helping with the release, and do let me know of any issues,
>> questions, etc.
>>
>> The tracking bug for release blockers is PR24126.
>>
>> Cheers,
>> Hans
>

On Mon, Jul 20, 2015 at 5:01 AM, Ben Pope <benpope81 at gmail.com>
wrote:
> On Sunday, July 19, 2015 07:43 PM, Renato Golin wrote:
>>
>> On 19 July 2015 at 09:36, Ben Pope <benpope81 at gmail.com>
wrote:
>>>
>>> On Ubuntu 14.04 x64 (with cmake) I get these failures at Phase3 and
no
>>> tarball:
>>
>>
>> The tarball is an issue Hans is aware of. We're fixing it.
>>
>>> Failing Tests (18):
>>>      AddressSanitizer-x86_64-linux :: TestCases/Posix/readv.cc
>>
>>
>> Did you use to build compiler-rt on the previous (autoconf) releases?
>
>
> I don't know.  I didn't specifically enable it.
>
>> If not, this might explain why you're only seeing these errors now.
I think it was built by default before, but that the autoconf build
didn't run as many tests. Having these tests run is one of the
benefits of using the cmake build, but it of course has the downside
that we have to make them pass :-)
> 1) Use the autoconf build and upload if I get a tarball?
> 2) Disable compiler-rt (how?)?
> 3) Disable the -o pipefail and upload if I get a tarball?
> 4) Something else?
I don't think the test failures are correlated to not getting a
tarball. It's probably the "rpath problem" that Dimitry mentioned
further up in the thread. Try using his patch for it, or disabling -o
pipefail.

And please see if you can dig out some more details about the failing
tests and get bugs filed.

Thanks,
Hans

On Thu, Jul 16, 2015 at 3:31 PM, Hans Wennborg <hans at chromium.org>
wrote:
> 3.7.0-rc1 was just tagged; please start your testing engines :-)
>
> Upload binaries to the sftp and report your results to this thread.
>
> I'm sorry for the delay between branching and tagging. The changes to
> the release script took a little longer than I hoped.
>
> Thanks for helping with the release, and do let me know of any issues,
> questions, etc.
>
> The tracking bug for release blockers is PR24126.
Windows binaries uploaded. sha1sums:

b0f5bced4003fe9c55e049392603c68276679e53  LLVM-3.7.0-rc1-win32.exe
7373bdbc5c62a7d4d3cf28458896ba2854ea715d  LLVM-3.7.0-rc1-win64.exe

They were built with the attached batch file, in case anyone wishes to
reproduce.

I applied r242527, which was merged after the rc1 tag, locally to make
Object/archive-extract.test pass.

Cheers,
Hans
-------------- next part --------------
A non-text attachment was scrubbed...
Name: build_llvm_370._bat_
Type: application/octet-stream
Size: 2614 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150720/8c7db472/attachment.obj>

On Tue, Jul 21, 2015 at 7:39 AM, Ben Pope <benpope81 at gmail.com>
wrote:
> On Tuesday, July 21, 2015 05:51 AM, Hans Wennborg wrote:
>>
>> I don't think the test failures are correlated to not getting a
>> tarball. It's probably the "rpath problem" that Dimitry
mentioned
>> further up in the thread. Try using his patch for it
>
>
> It still failed, I used test-release.sh r242767 which appears to have the
> rpath change.
Weird. Did you get any output suggesting what the error was?
>> or disabling -o pipefail.
>
>
> That sort of worked. Again, the paths in the install directory are
> ./usr/local/ but in the tarball they seem as before.
Having /usr/local in the install directory during the build is
expected. As long as they don't up in the tarball (and I fixed that),
it's fine.
> Also, cxxabi.h is in
> ./include/c++/v1 which is nice, but no unwind.h, I haven't checked if
that's
> a problem yet.
I'm not that familiar with libunwind. Clang should have installed an
unwind.h in lib/clang/3.7.0/include/unwind.h. I don't know if
libunwind is expected to install another one.
> Failing Tests (9):
>     MemorySanitizer :: Linux/tcgetattr.cc
>     MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getmntent
>     MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getmntent_r
>     MemorySanitizer-Unit ::
> Msan-x86_64-with-call-Test/MemorySanitizer.getmntent
>     MemorySanitizer-Unit ::
> Msan-x86_64-with-call-Test/MemorySanitizer.getmntent_r
>     SanitizerCommon-asan :: Linux/getpass.cc
>     SanitizerCommon-lsan :: Linux/getpass.cc
>     SanitizerCommon-msan :: Linux/getpass.cc
>     SanitizerCommon-tsan :: Linux/getpass.cc
>
>   Expected Passes    : 24015
>   Expected Failures  : 131
>   Unsupported Tests  : 377
>   Unexpected Failures: 9
>
> Full output below.
>
> lnt seems fine, I've uploaded this file:
> clang+llvm-3.7.0-rc1-x86_64-linux-gnu-ubuntu-15.04.tar.xz
>
>> And please see if you can dig out some more details about the failing
>> tests and get bugs filed.
>
>
> I don't really know what I'm looking for, if you need more info
I'm happy to
> provide it.
The output below is great. I'll try to get these investigated.

Thanks,
Hans

On Thu, Jul 16, 2015 at 3:31 PM, Hans Wennborg <hans at chromium.org>
wrote:
> Dear testers,
>
> 3.7.0-rc1 was just tagged; please start your testing engines :-)
This has been a bumpier ride than 3.6 so far, mainly due to the cmake
switch. We're testing stuff that didn't get tested before, which I
think is good. Thank you very much for your efforts so far.

This is an attempt to summarize this rather long thread. TL;DR: There
have been a bunch of issues, many addressed, some still out-standing.
Most binaries are ready, so I plan to push RC1 to the web site soon.

Binaries on the sftp:
====================clang+llvm-3.7.0-armv7a-linux-gnueabihf.tar.xz
clang+llvm-3.7.0-rc1-aarch64-linux-gnu.tar.xz
clang+llvm-3.7.0-rc1-amd64-unknown-freebsd10.tar.xz
clang+llvm-3.7.0-rc1-i386-unknown-freebsd10.tar.xz
clang+llvm-3.7.0-rc1-mipsel-linux-gnu.tar.xz
clang+llvm-3.7.0-rc1-mips-linux-gnu.tar.xz
clang+llvm-3.7.0-rc1-x86_64-apple-darwin.tar.xz
clang+llvm-3.7.0-rc1-x86_64-linux-gnu-ubuntu-15.04.tar.xz
LLVM-3.7.0-rc1-win32.exe
LLVM-3.7.0-rc1-win64.exe

Some of these have the /usr/local prefix baked in (since fixed in
r242706); I'll remove that manually before publishing the tarballs.

The armv7a tarball doesn't have rc1 in the name. I'll rename that (and
the dir within) before publishing.

Fedora and OpenSUSE isn't ready yet, but those can be added later. I
think we have enough binaries to put RC1 on the web page.

Issues
=====Various compiler-rt test failures, see below.
(Linux/signal_segv_handler.cc might be fixed by r242848.)

Dimitry says he'll use the autoconf build for FreeBSD due to errors.
Has a patch out to do this in the script, but it hasn't landed yet.
(Darwin currently also defaults to autoconf in the script)

Jack Howarth asked about -fopenmp currently essentially being no-op.
As far as I know (please correct me if I'm wrong here) this is still
the case on trunk. If it's not enabled on trunk, there is nothing to
merge.

There is a discussion on openmp-dev about the CMake build being broken
in Pathscale's build. The breakage does not seem to be well understood
yet.

Nikola reports that compiler-rt fails to cmake on x86 openSUSE because
it targets i686, but the system is i586. Same failure happens on the
phase 2 build on x86 Fedora 22, but probably with a different cause.

Renato reported libunwind was missing from the projects list,
preventing libcxxabi and libcxx to build. It was added in r242543, but
there are still problems and Renato said he'll exclude them for this
release.

Files in the tarball were prefixed with /usr/local; fixed in r242706.

The clean_rpath function was failing when no rpath was present in the
binary; fixed in r242722

The file comparison step was broken as cmp(1) doesn't support
--ignore-initial on all platforms; fixed in r242721.

Object/archive-extract.test failed on windows; fixed in r242527

Ben reports that he didn't get a tarball even after the rpath fix and
had to disable -o pipefail to get one. Still not sure what caused
this.



Thanks,
Hans


Appendix: compiler-rt test failures
==================================>From Ben on Ubuntu 14.04 x64:

    AddressSanitizer-x86_64-linux :: TestCases/Posix/readv.cc
    MemorySanitizer :: Linux/tcgetattr.cc
    MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.gethostent
    MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.gethostent_r
    MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getmntent
    MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getmntent_r
    MemorySanitizer-Unit ::
Msan-x86_64-with-call-Test/MemorySanitizer.gethostent
    MemorySanitizer-Unit ::
Msan-x86_64-with-call-Test/MemorySanitizer.gethostent_r
    MemorySanitizer-Unit :: Msan-x86_64-with-call-Test/MemorySanitizer.getmntent
    MemorySanitizer-Unit ::
Msan-x86_64-with-call-Test/MemorySanitizer.getmntent_r
    SanitizerCommon-asan :: Linux/getpass.cc
    SanitizerCommon-asan :: Posix/decorate_proc_maps.cc
    SanitizerCommon-lsan :: Linux/getpass.cc
    SanitizerCommon-msan :: Linux/getpass.cc
    SanitizerCommon-msan :: Linux/signal_segv_handler.cc
    SanitizerCommon-msan :: Posix/decorate_proc_maps.cc
    SanitizerCommon-tsan :: Linux/getpass.cc
    SanitizerCommon-tsan :: Posix/decorate_proc_maps.cc
>From Nikola on Fedora 22 x64:
    LeakSanitizer-AddressSanitizer :: TestCases/cleanup_in_tsd_destructor.cc
    LeakSanitizer-AddressSanitizer :: TestCases/disabler.cc
    LeakSanitizer-AddressSanitizer :: TestCases/disabler_in_tsd_destructor.cc
    LeakSanitizer-AddressSanitizer :: TestCases/ignore_object.cc
    LeakSanitizer-Standalone :: TestCases/cleanup_in_tsd_destructor.cc
    LeakSanitizer-Standalone :: TestCases/disabler.cc
    LeakSanitizer-Standalone :: TestCases/disabler_in_tsd_destructor.cc
    LeakSanitizer-Standalone :: TestCases/ignore_object.cc
>From Ben on x86_64-linux-gnu-ubuntu-15.04:
   MemorySanitizer :: Linux/tcgetattr.cc
    MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getmntent
    MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getmntent_r
    MemorySanitizer-Unit :: Msan-x86_64-with-call-Test/MemorySanitizer.getmntent
    MemorySanitizer-Unit ::
Msan-x86_64-with-call-Test/MemorySanitizer.getmntent_r
    SanitizerCommon-asan :: Linux/getpass.cc
    SanitizerCommon-lsan :: Linux/getpass.cc
    SanitizerCommon-msan :: Linux/getpass.cc
    SanitizerCommon-tsan :: Linux/getpass.cc

On Wednesday, July 22, 2015 04:44 AM, Hans Wennborg
wrote:
> On Tue, Jul 21, 2015 at 7:39 AM, Ben Pope <benpope81 at gmail.com>
wrote:
>> On Tuesday, July 21, 2015 05:51 AM, Hans Wennborg wrote:
>>>
>>> I don't think the test failures are correlated to not getting a
>>> tarball. It's probably the "rpath problem" that
Dimitry mentioned
>>> further up in the thread. Try using his patch for it
>>
>>
>> It still failed, I used test-release.sh r242767 which appears to have
the
>> rpath change.
>
> Weird. Did you get any output suggesting what the error was?
My normal (using cmake) builds on linux usually put the rpath on, 
although I thought the cmake install step then strips them - I just 
checked and that's not true for my latest build from trunk which both 
have RUNPATH, not RPATH like the rc1.  Weirder and weirder.

The rpath step in test-release may have been added or changed back 
around release 3.3; it looks like that discussion didn't hit the mailing 
list, nor did it include you.  I can forward it to you if you like.

Anyway, cmake supports customisation of the rpath handling, so we should 
probably just use that and remove it from the test-release script.

The only errors I can see are:

CMakeFiles/check-all.dir/build.make:49: recipe for target 
'CMakeFiles/check-all' failed
make[3]: *** [CMakeFiles/check-all] Error 1
make[3]: Target 'CMakeFiles/check-all.dir/build' not remade because of 
errors.
CMakeFiles/Makefile2:129: recipe for target 
'CMakeFiles/check-all.dir/all' failed
make[2]: *** [CMakeFiles/check-all.dir/all] Error 2
CMakeFiles/Makefile2:137: recipe for target 
'CMakeFiles/check-all.dir/rule' failed
make[1]: *** [CMakeFiles/check-all.dir/rule] Error 2
make[1]: Target 'check-all' not remade because of errors.
Makefile:171: recipe for target 'check-all' failed
make: *** [check-all] Error 2

So it appears to be -o pipefail picking up the sanitizer failures.

Ben

> Ben reports that he didn't get a tarball even after the rpath fix and
> had to disable -o pipefail to get one. Still not sure what caused
> this.
'make check' failures can cause this. I had to revert r241599 to get a
package.
> Appendix: compiler-rt test failures
> ==================================>
Just to add Mips to this: On big-endian Mips32r2:
            AddressSanitizer-mips-linux :: TestCases/Linux/kernel-area.cc
            AddressSanitizer-mips-linux ::
TestCases/Posix/coverage-direct-large.cc
            UBSan-ASan-mips :: TestCases/Float/cast-overflow.cpp
            UBSan-Standalone-mips :: TestCases/Float/cast-overflow.cpp
            libc++abi :: backtrace_test.pass.cpp
            libc++abi :: test_demangle.pass.cpp

On little-endian Mips32r2:
            AddressSanitizer-mips-linux :: TestCases/Linux/kernel-area.cc
            libc++abi :: backtrace_test.pass.cpp
            libc++abi :: test_demangle.pass.cpp

Jaydeep Patil and Nitesh Jain have shown me a patch for 'libc++abi ::
test_demangle.pass.cpp' which works for me. It should be appearing for
review shortly.
> -----Original Message-----
> From: cfe-dev-bounces at cs.uiuc.edu [mailto:cfe-dev-bounces at
cs.uiuc.edu]
> On Behalf Of Hans Wennborg
> Sent: 22 July 2015 01:53
> To: llvmdev; cfe-dev; lldb-dev at cs.uiuc.edu
> Cc: Ben Pope; Ed Maste; Sebastian Dreßler
> Subject: Re: [cfe-dev] [3.7 Release] RC1 has been tagged, Testing Phase I
> begins
> 
> On Thu, Jul 16, 2015 at 3:31 PM, Hans Wennborg <hans at chromium.org>
> wrote:
> > Dear testers,
> >
> > 3.7.0-rc1 was just tagged; please start your testing engines :-)
> 
> This has been a bumpier ride than 3.6 so far, mainly due to the cmake
> switch. We're testing stuff that didn't get tested before, which I
> think is good. Thank you very much for your efforts so far.
> 
> This is an attempt to summarize this rather long thread. TL;DR: There
> have been a bunch of issues, many addressed, some still out-standing.
> Most binaries are ready, so I plan to push RC1 to the web site soon.
> 
> Binaries on the sftp:
> ====================> clang+llvm-3.7.0-armv7a-linux-gnueabihf.tar.xz
> clang+llvm-3.7.0-rc1-aarch64-linux-gnu.tar.xz
> clang+llvm-3.7.0-rc1-amd64-unknown-freebsd10.tar.xz
> clang+llvm-3.7.0-rc1-i386-unknown-freebsd10.tar.xz
> clang+llvm-3.7.0-rc1-mipsel-linux-gnu.tar.xz
> clang+llvm-3.7.0-rc1-mips-linux-gnu.tar.xz
> clang+llvm-3.7.0-rc1-x86_64-apple-darwin.tar.xz
> clang+llvm-3.7.0-rc1-x86_64-linux-gnu-ubuntu-15.04.tar.xz
> LLVM-3.7.0-rc1-win32.exe
> LLVM-3.7.0-rc1-win64.exe
> 
> Some of these have the /usr/local prefix baked in (since fixed in
> r242706); I'll remove that manually before publishing the tarballs.
> 
> The armv7a tarball doesn't have rc1 in the name. I'll rename that
(and
> the dir within) before publishing.
> 
> Fedora and OpenSUSE isn't ready yet, but those can be added later. I
> think we have enough binaries to put RC1 on the web page.
> 
> Issues
> =====> Various compiler-rt test failures, see below.
> (Linux/signal_segv_handler.cc might be fixed by r242848.)
> 
> Dimitry says he'll use the autoconf build for FreeBSD due to errors.
> Has a patch out to do this in the script, but it hasn't landed yet.
> (Darwin currently also defaults to autoconf in the script)
> 
> Jack Howarth asked about -fopenmp currently essentially being no-op.
> As far as I know (please correct me if I'm wrong here) this is still
> the case on trunk. If it's not enabled on trunk, there is nothing to
> merge.
> 
> There is a discussion on openmp-dev about the CMake build being broken
> in Pathscale's build. The breakage does not seem to be well understood
> yet.
> 
> Nikola reports that compiler-rt fails to cmake on x86 openSUSE because
> it targets i686, but the system is i586. Same failure happens on the
> phase 2 build on x86 Fedora 22, but probably with a different cause.
> 
> Renato reported libunwind was missing from the projects list,
> preventing libcxxabi and libcxx to build. It was added in r242543, but
> there are still problems and Renato said he'll exclude them for this
> release.
> 
> Files in the tarball were prefixed with /usr/local; fixed in r242706.
> 
> The clean_rpath function was failing when no rpath was present in the
> binary; fixed in r242722
> 
> The file comparison step was broken as cmp(1) doesn't support
> --ignore-initial on all platforms; fixed in r242721.
> 
> Object/archive-extract.test failed on windows; fixed in r242527
> 
> Ben reports that he didn't get a tarball even after the rpath fix and
> had to disable -o pipefail to get one. Still not sure what caused
> this.
> 
> 
> 
> Thanks,
> Hans
> 
> 
> Appendix: compiler-rt test failures
> ==================================> From Ben on Ubuntu 14.04 x64:
> 
>     AddressSanitizer-x86_64-linux :: TestCases/Posix/readv.cc
>     MemorySanitizer :: Linux/tcgetattr.cc
>     MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.gethostent
>     MemorySanitizer-Unit :: Msan-x86_64-
> Test/MemorySanitizer.gethostent_r
>     MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getmntent
>     MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getmntent_r
>     MemorySanitizer-Unit ::
> Msan-x86_64-with-call-Test/MemorySanitizer.gethostent
>     MemorySanitizer-Unit ::
> Msan-x86_64-with-call-Test/MemorySanitizer.gethostent_r
>     MemorySanitizer-Unit :: Msan-x86_64-with-call-
> Test/MemorySanitizer.getmntent
>     MemorySanitizer-Unit ::
> Msan-x86_64-with-call-Test/MemorySanitizer.getmntent_r
>     SanitizerCommon-asan :: Linux/getpass.cc
>     SanitizerCommon-asan :: Posix/decorate_proc_maps.cc
>     SanitizerCommon-lsan :: Linux/getpass.cc
>     SanitizerCommon-msan :: Linux/getpass.cc
>     SanitizerCommon-msan :: Linux/signal_segv_handler.cc
>     SanitizerCommon-msan :: Posix/decorate_proc_maps.cc
>     SanitizerCommon-tsan :: Linux/getpass.cc
>     SanitizerCommon-tsan :: Posix/decorate_proc_maps.cc
> 
> From Nikola on Fedora 22 x64:
> 
>     LeakSanitizer-AddressSanitizer ::
TestCases/cleanup_in_tsd_destructor.cc
>     LeakSanitizer-AddressSanitizer :: TestCases/disabler.cc
>     LeakSanitizer-AddressSanitizer ::
TestCases/disabler_in_tsd_destructor.cc
>     LeakSanitizer-AddressSanitizer :: TestCases/ignore_object.cc
>     LeakSanitizer-Standalone :: TestCases/cleanup_in_tsd_destructor.cc
>     LeakSanitizer-Standalone :: TestCases/disabler.cc
>     LeakSanitizer-Standalone :: TestCases/disabler_in_tsd_destructor.cc
>     LeakSanitizer-Standalone :: TestCases/ignore_object.cc
> 
> From Ben on x86_64-linux-gnu-ubuntu-15.04:
> 
>    MemorySanitizer :: Linux/tcgetattr.cc
>     MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getmntent
>     MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getmntent_r
>     MemorySanitizer-Unit :: Msan-x86_64-with-call-
> Test/MemorySanitizer.getmntent
>     MemorySanitizer-Unit ::
> Msan-x86_64-with-call-Test/MemorySanitizer.getmntent_r
>     SanitizerCommon-asan :: Linux/getpass.cc
>     SanitizerCommon-lsan :: Linux/getpass.cc
>     SanitizerCommon-msan :: Linux/getpass.cc
>     SanitizerCommon-tsan :: Linux/getpass.cc
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

On Mon, Jul 20, 2015 at 2:26 AM, Daniel Sanders
<Daniel.Sanders at imgtec.com> wrote:
> Here's the current status for the Mips packages.
[..]
> clang+llvm-3.7.0-rc1-mips-linux-gnu.tar.xz
The root directory in this file is
"clang+llvm-3.7.0-rc1-mipsel-linux-gnu". Is it just the name
that's
wrong, or does it actually have files for the wrong target?