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

Hi testers!

3.6.0-rc1 was just tagged, so testing can begin.

I'm not super familiar with the testing script yet, but I believe the
idea is to run it as follows:

  $ utils/release/test-release.sh -release 3.6.0 -rc 1 -triple
x86_64-unknown-linux-gnu

With the -triple value substituted for your platform. Bill's 3.5rc1
email also said 'test-suite' needs to be run by hand.

Please upload binaries to the sftp and report your results to this thread.

Thanks for helping with the release!

- Hans

Hi,

I uploaded the binary for OS X. Nothing suspicious in testing...

Cheers,
Sebastian

AArch64 tested and uploaded. ARMv7 in progress.

cheers,
--renato

Here are binaries for FreeBSD 10; I did not see any failures during testing.

As usual, I don't have access to sftp (and don't even know which server ;), but the binaries can be found here:

http://www.andric.com/freebsd/clang/clang+llvm-3.6.0-rc1-i386-unknown-freebsd10.tar.xz
http://www.andric.com/freebsd/clang/clang+llvm-3.6.0-rc1-amd64-unknown-freebsd10.tar.xz

SHA256 (clang+llvm-3.6.0-rc1-i386-unknown-freebsd10.tar.xz) = 304c444cd005819e93f3b580fb1f821a0ab2ec69bb56e61902412cc7abd59883
SHA256 (clang+llvm-3.6.0-rc1-amd64-unknown-freebsd10.tar.xz) = 117f763ba7afd1d6f3f4ca4f534464d68be215dcdf52b4edd219930badee0d46

-Dimitry

I've uploaded the Windows binary. Everything looked good except
Modules/compiler_builtins.m (PR20995). I'll take a look at that
tomorrow.

- Hans

I've uploaded the mips binaries and started the test-suite. We unexpectedly* fail two 'make check-all' tests at the moment. One of them is a faulty test and the fix was committed to trunk yesterday. The other is a recently-added test (test/DebugInfo/multiline.ll) that we're looking into.

* There's one expected fail on the little endian build caused by running test/Modules/prune.m on an NFS mount that doesn't track access times correctly. It's still there but it's not clangs fault.

Dimitry:
As usual, I don't have access to sftp (and don't even know which server :wink:

Anton Korobeynikov <anton@korobeynikov.info> should be able to sort this out for you. You'll need to provide an ssh key.

Hi Hans,

ARMv7 is giving me a bit of a headache... I've tried building on two
different machines and I get the same error... Phase 2 completes
successfully, but while building Phase 3, I get the error on *every*
file:

1. /usr/lib/gcc/arm-linux-gnueabihf/4.9/../../../../include/c++/4.9/bits/ptr_traits.h:77:25:
at annotation token
2. /usr/lib/gcc/arm-linux-gnueabihf/4.9/../../../../include/c++/4.9/bits/ptr_traits.h:37:1:
parsing namespace 'std'
3. /usr/lib/gcc/arm-linux-gnueabihf/4.9/../../../../include/c++/4.9/bits/ptr_traits.h:73:5:
parsing struct/union/class body '__ptrtr_rebind_helper'
clang: error: unable to execute command: Bus error
clang: error: clang frontend command failed due to signal (use -v to
see invocation)

Phase 1 passes check-all with flying colours, while Phase 2 fails *a
lot* if C++ Clang tests with seg-faults in the parser. But this is
something we're not seeing in the self-hosting buildbot for the same
commit as 3.6 branched off of:

http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15-selfhost/builds/2343

Could it be some of the merges later?

cheers,
--renato

clang+llvm-3.6.0-rc1-mips-linux-gnu.tar.xz
  A couple 'make check-all' failures. All except one is fixed on the branch. A fix for the remaining one is under review at http://reviews.llvm.org/D7050.
    Test-suite is clean for default options, -mips32, and -mips32r2.

clang+llvm-3.6.0-rc1-mipsel-linux-gnu.tar.xz
  A couple 'make check-all' failures. All except one is fixed on the branch. A fix for the remaining one is under review at http://reviews.llvm.org/D7050.
  Test-suite still running due to a silly mistake on my part.

clang+llvm-3.6.0-rc1-x86_64-linux-gnu-ubuntu-14.04.tar.xz (cross compilation to Mips)
  All clean.
  The big-endian N32 failures that were in 3.5.1 have been fixed.

ARMv7 is giving me a bit of a headache... I've tried building on two
different machines and I get the same error... Phase 2 completes
successfully, but while building Phase 3, I get the error on *every*
file:

1. /usr/lib/gcc/arm-linux-gnueabihf/4.9/../../../../include/c++/4.9/bits/ptr_traits.h:77:25:
at annotation token
2. /usr/lib/gcc/arm-linux-gnueabihf/4.9/../../../../include/c++/4.9/bits/ptr_traits.h:37:1:
parsing namespace 'std'
3. /usr/lib/gcc/arm-linux-gnueabihf/4.9/../../../../include/c++/4.9/bits/ptr_traits.h:73:5:
parsing struct/union/class body '__ptrtr_rebind_helper'
clang: error: unable to execute command: Bus error
clang: error: clang frontend command failed due to signal (use -v to
see invocation)

Phase 1 passes check-all with flying colours, while Phase 2 fails *a
lot* if C++ Clang tests with seg-faults in the parser.

At least having tests failing makes this easier.

But this is
something we're not seeing in the self-hosting buildbot for the same
commit as 3.6 branched off of:
http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15-selfhost/builds/2343

Could it be some of the merges later?

There weren't many merges between the branch point and the rc1 tag. They were:

  r226023 InstCombine: Don't take A-B<0 into A<B if A-B has other uses
  r226029 IR: Fix a use-after-free in RAUW
  r226044 IR: Drop metadata references more aggressively during teardown
  r226046 IR: Always print MDLocation line
  r226049 IR: Move MDLocation into place (clang testcases)
  r226048 IR: Move MDLocation into place
  r226058 IR: Fix comment spelling, NFC

Everything except the InstCombine one is Duncan's debug info/metadata
stuff. Since this bootstrap build isn't using debug info, that just
leaves the InstCombine change, which looks innocent in itself but
maybe it is triggering some other problem (like PR22222?)

Would it be possible to revert that change locally, do the bootstrap
and try some of the failing tests?

If that doesn't work, maybe revert the other chunk of patches and see
if that helps. Or cherry-picking r226075 which is in the branch, but
landed after rc1 was tagged. I don't have any ARM hardware to test on,
so I'm afraid I can't help out much here myself :-/

Thanks,
Hans

I agree with Hans that my changes seem somewhat unlikely to be the cause,
but if reverting them fixes it, please pull me in and I'll do what I can
to help.

None of that seems to be the culprit. I think the real problem here is
that the release scripts are building with autoconf and our buildbots
have migrated to CMake a few months ago.

I'll bootstrap it with CMake and see what I get. Shouldn't we be
moving to CMake based release anyway?

cheers,
--renato

None of that seems to be the culprit. I think the real problem here is
that the release scripts are building with autoconf and our buildbots
have migrated to CMake a few months ago.

I'll bootstrap it with CMake and see what I get. Shouldn't we be
moving to CMake based release anyway?

cheers,
--renato

Everything except the InstCombine one is Duncan's debug info/metadata
stuff. Since this bootstrap build isn't using debug info, that just
leaves the InstCombine change, which looks innocent in itself but
maybe it is triggering some other problem (like PR22222?)

None of that seems to be the culprit. I think the real problem here is
that the release scripts are building with autoconf and our buildbots
have migrated to CMake a few months ago.

I'll bootstrap it with CMake and see what I get.

Thanks, let me know what you find out.

Shouldn't we be
moving to CMake based release anyway?

Oh, the joy of having two build systems. :frowning:

As long as we have two, it doesn't really matter which one we use to
build the binaries, as users building from source will still rely on
both to be working.

- Hans

> Shouldn't we be
> moving to CMake based release anyway?

Oh, the joy of having two build systems. :frowning:

As long as we have two, it doesn't really matter which one we use to
build the binaries, as users building from source will still rely on
both to be working.

- Hans

On that subject, are you aware that the release builds for linux don't build compiler-rt for any target other than x86/x86_64? I noticed it today when I tried the address sanitizer for Mips and found I didn't have the runtime.

It seems that targets have to be explicitly enabled in tools/clang/runtime/compiler-rt/Makefile.

+kcc and samsonov who know the ASan build best

Looks like when ASan support for MIPS landed in r211587, no one
updated the autoconf build. That was before 3.5, so I guess that one
also shipped without ASan support for MIPS.

That's right. I didn't try to test ASan for 3.5 as I was focusing on getting little endian builds up and running.

The main reason I mentioned the build issue on this thread is that AArch64 and ARM releases also ship without sanitizer libraries and I thought that might be surprising.

We're working on the libraries and sanitizers, and I'm hoping the next
release we can build compiler-rt and libc++ altogether.

cheers,
--renato

Sounds good to me.

One small comment/thread_hijack; can we have "make update", or is there an alternative I've missed?

build
    release (cmake/ninja)
    debug (cmake/ninja)
    update (configure/autostuffnobodyunderstands so I can "make update")

It's the one thing I'm missing.

Ben

Sigh... Using CMake gets me the same problems. I have no idea what's
going on but that is not looking right.

I'll try to check out the first commit on 3.6.0 and see if that
builds. Then bisect.

cheers,
--renato

Hans,

CODE RED for ARMv7...

The buildbots are green on self-hosting because they're building with
-mfpu=vfpv3 and not NEON. When I bootstrapped the release, I was using
NEON and that's what killed it. We have a test-suite buildbot running
with NEON, but that wasn't enough to pick up the regression, as it
seemed only Clang was complex enough to show it.

Result: we have a serious code-generation problem with NEON and I have
no idea where it is... at least I know that it's after 3.5 and before
3.6 branch.

I'll start a bissect between 3.5 and 3.6, but given that this is a
self-hosting issue on an ARMv7 board, it could take days.

I don't want to delay the release even further, and I believe none of
the RC1 patches will make a difference, so Hans, please continue with
RC2 and I'll pick it up when I finish. Hopefully, I'll find the bug
before final.

Fingers crossed...

cheers,
--renato

PS: I'll add a slow self-hosting full buildbot with Thumb2+NEON to
cover the other bases we're not covering, and hopefully that'll help
with this issue in the future.