[3.6 Release] RC2 has been tagged, Testing Phase II begins

Hi testers,

3.6.0-rc2 was just tagged. Please test and build binaries.

The tracking bug for 3.6 blockers is http://llvm.org/pr22374. Please
file issues against it.

Thanks for helping with the release!
Hans

This time I got an error during check-all, on i386-unknown-freebsd10:

    [...]
    gmake[1]: Entering directory `/home/dim/llvm-3.6.0/rc2/Phase3/Release/llvmCore-3.6.0-rc2.obj/test'
    Making LLVM 'lit.site.cfg' file...
    Making LLVM unittest 'lit.site.cfg' file...
    gmake -C /home/dim/llvm-3.6.0/rc2/Phase3/Release/llvmCore-3.6.0-rc2.obj/test/../tools/clang/test lit.site.cfg Unit/lit.site.cfg
    gmake[2]: Entering directory `/home/dim/llvm-3.6.0/rc2/Phase3/Release/llvmCore-3.6.0-rc2.obj/tools/clang/test'
    Making Clang 'lit.site.cfg' file...
    Making Clang 'Unit/lit.site.cfg' file...
    gmake[2]: Leaving directory `/home/dim/llvm-3.6.0/rc2/Phase3/Release/llvmCore-3.6.0-rc2.obj/tools/clang/test'
    ( ulimit -t 600 ; ulimit -d 512000 ; ulimit -m 512000 ; ulimit -s 8192 ; \
      /usr/local/bin/python /home/dim/llvm-3.6.0/rc2/llvm.src/utils/lit/lit.py -s -v . /home/dim/llvm-3.6.0/rc2/Phase3/Release/llvmCore-3.6.0-rc2.obj/test/../tools/clang/test )
    lit.py: lit.cfg:271: note: Did not find llvm-go in /home/dim/llvm-3.6.0/rc2/Phase3/Release/llvmCore-3.6.0-rc2.obj/Release/bin
    lit.py: lit.cfg:195: note: using clang: '/home/dim/llvm-3.6.0/rc2/Phase3/Release/llvmCore-3.6.0-rc2.obj/Release/bin/clang'
    lit.py: lit.cfg:332: note: Did not find clang-interpreter in /home/dim/llvm-3.6.0/rc2/Phase3/Release/llvmCore-3.6.0-rc2.obj/Release/bin:/home/dim/llvm-3.6.0/rc2/Phase3/Release/llvmCore-3.6.0-rc2.obj/Release/bin
    lit.py: run.py:223: note: failed to initialize multiprocessing
    -- Testing: 20187 tests, 4 threads --
    Testing: 0 .. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80..gmake[1]: *** [check-local-all] Killed
    gmake[1]: Leaving directory `/home/dim/llvm-3.6.0/rc2/Phase3/Release/llvmCore-3.6.0-rc2.obj/test'
    gmake: *** [check-all] Error 2

This is because the ulimit -t 600 was exceeded, as shown in dmesg:

    pid 78288 (python2.7), uid 1000, was killed: exceeded maximum CPU limit

Can we bump the -t limit a little? If a machine is rather busy when doing the tests, this limit can be exceeded. I had this diff for trunk for some time:

Index: test/Makefile

I'd be OK with that. Did the tests pass for you if you raise the limit?

- Hans

...

This is because the ulimit -t 600 was exceeded, as shown in dmesg:

   pid 78288 (python2.7), uid 1000, was killed: exceeded maximum CPU limit

Can we bump the -t limit a little? If a machine is rather busy when doing the tests, this limit can be exceeded.

I'd be OK with that. Did the tests pass for you if you raise the limit?

Yes, re-running "gmake check-all" from the rc2/Phase3/Release/llvmCore-3.6.0-rc2.obj subdirectory succeeds now:

                      -- Testing: 20187 tests, 4 threads --
Testing Time: 250.10s
  Expected Passes : 19873
  Expected Failures : 101
  Unsupported Tests : 213

The hypervisor I'm running on is also much less busy, which is why the testing time is now just 250 seconds... Virtualization is not always that great :slight_smile:

I've also uploaded the resulting binaries to the sftp area:

SHA256 (clang+llvm-3.6.0-rc2-i386-unknown-freebsd10.tar.xz) = 820a4bb750872ae4055cc9bc5305f7e1ef9e77e192812521ee5adfc0d2049461
SHA256 (clang+llvm-3.6.0-rc2-amd64-unknown-freebsd10.tar.xz) = c6e59552a9c3ca3486d803438594467d7b0f740e36170fc597eec5e0d1a42859

-Dimitry

Hi Hans,

Do you want to send a patch out to the list for raising the timeout?

Thanks,
Hans

I've sent a patch to llvm-commits.

-Dimitry

Win binaries are now on the sftp. Attaching the script I used for
building in case someone wants to reproduce it.

build_llvm_360.bat|attachment (2.52 KB)

Uploaded mips binaries. Most testing is still running but it's looking good so far.

clang+llvm-3.6.0-rc2-mips-linux-gnu.tar.xz
  All clear.

clang+llvm-3.6.0-rc2-mipsel-linux-gnu.tar.xz
  All clear for default options.
  Still running for the other configs.

clang+llvm-3.6.0-rc2-x86_64-linux-gnu-ubuntu-14.04.tar.xz (cross compiling for Mips):
  Still running

clang+llvm-3.6.0-rc2-mipsel-linux-gnu.tar.xz
  All clear for default options.
  Still running for the other configs.

I just had to kill Searching-dbl.simple and Packing-dbl.simple for the mips32 config which were at 65hrs and 15hrs real time respectively. This is far in excess of the 15,000s time limit that's supposed to be in force. I'm not sure what's going on here.

In rc1, Searching-dbl.simple took 357 seconds user time (7731s real time, the FPU is emulated via kernel traps) and Packing-dbl.simple took 555s user time (8724 real time).

clang+llvm-3.6.0-rc2-x86_64-linux-gnu-ubuntu-14.04.tar.xz (cross compiling
for Mips):
  Still running

Of what's completed so far (it's _still_ running which is strange in itself), I'm seeing a lot of timeouts that weren't in rc1. Mostly on the TSVC tests.

Sorry, mixed up my terminals. This one has finished but I see timeouts that I didn't have in rc1.

Hi Hans,

I just built RC2 with the patch that fixes the NEON builds on ARM and
uploaded to the FTP site. It checks-all clean, but I'm running the
test-suite now.

We'll still need RC3, but at least this one helps people test before
that happens, so we only need to flag RC3 when all other arches are
good.

cheers,
--renato

Thanks! I've added it to the pre-release web page so folks can try it out.

- Hans

Well, where is the patch? :slight_smile:

Joerg

I assume Renato is referring to
http://llvm.org/viewvc/llvm-project?view=revision&revision=228153

Thanks,
Hans

Yes, sorry, indeed I was. :slight_smile:

Cheers,
Renato

Test-suite passes with flying colours.

cheers,
--renato

It certainly works better than before, testing continues...

Joerg

> > clang+llvm-3.6.0-rc2-mipsel-linux-gnu.tar.xz
> > All clear for default options.
> > Still running for the other configs.
>
> I just had to kill Searching-dbl.simple and Packing-dbl.simple for the
> mips32 config which were at 65hrs and 15hrs real time respectively. This is
> far in excess of the 15,000s time limit that's supposed to be in force. I'm not
> sure what's going on here.
>
> In rc1, Searching-dbl.simple took 357 seconds user time (7731s real time,
> the FPU is emulated via kernel traps) and Packing-dbl.simple took 555s user
> time (8724 real time).

This testing has now finished. All is well apart from the two tests I killed. I'm re-running them overnight to see if it happens again and I'll start debugging in the morning.

> > clang+llvm-3.6.0-rc2-x86_64-linux-gnu-ubuntu-14.04.tar.xz (cross
> > compiling for Mips):
> > Still running
>
> Of what's completed so far I'm seeing a lot of timeouts that weren't in rc1.
> Mostly on the TSVC tests.

It's looks like the qemu update that was needed for microMIPS has introduced a bug in some of the other configs. I've successfully re-run some of the failing tests with the previous qemu. I'm re-running the rest overnight and it should be mostly finished by the morning.

> > > clang+llvm-3.6.0-rc2-mipsel-linux-gnu.tar.xz
> > > All clear for default options.
> > > Still running for the other configs.
> >
> > I just had to kill Searching-dbl.simple and Packing-dbl.simple for the
> > mips32 config which were at 65hrs and 15hrs real time respectively. This is
> > far in excess of the 15,000s time limit that's supposed to be in force. I'm not
> > sure what's going on here.
> >
> > In rc1, Searching-dbl.simple took 357 seconds user time (7731s real time,
> > the FPU is emulated via kernel traps) and Packing-dbl.simple took 555s user
> > time (8724 real time).

This testing has now finished. All is well apart from the two tests I killed. I'm re-running them overnight to see if it > happens again and I'll start debugging in the morning.

The two tests I had to kill passed as normal when re-run, so this package is ok.

> > > clang+llvm-3.6.0-rc2-x86_64-linux-gnu-ubuntu-14.04.tar.xz (cross
> > > compiling for Mips):
> > > Still running
> >
> > Of what's completed so far I'm seeing a lot of timeouts that weren't in rc1.
> > Mostly on the TSVC tests.

It's looks like the qemu update that was needed for microMIPS has introduced a bug in some of the other configs. > I've successfully re-run some of the failing tests with the previous qemu. I'm re-running the rest overnight and it
should be mostly finished by the morning.

I can confirm that it was the qemu update. With the previous qemu all the existing test configs pass and only the new micromips test config has problems. I'll figure out exactly what's wrong with the new qemu later.