llvm dev - Dec 2016 - [Release-testers] 3.9.1-rc2 is ready for testing

Hi,

I just tagged 3.9.1-rc2, so testing can begin.  There was a bug found in
-rc1 before I could send out a release announcement, so I decided to merge
the fix and tag -rc2 to save some testing cycles.

We can always use more testers, so if you are interested in helping, let
me know.

Thanks,
Tom

On 2 December 2016 at 03:53, Tom Stellard via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> I just tagged 3.9.1-rc2, so testing can begin.  There was a bug found in
> -rc1 before I could send out a release announcement, so I decided to merge
> the fix and tag -rc2 to save some testing cycles.
AArch64 RC2 validated and uploaded.

MD5: 4112d2cc3cd6f390d61c9db8f2897f64
clang+llvm-3.9.1-rc2-aarch64-linux-gnu.tar.xz

On 2 December 2016 at 15:12, Renato Golin <renato.golin at linaro.org>
wrote:
> AArch64 RC2 validated and uploaded.
>
> MD5: 4112d2cc3cd6f390d61c9db8f2897f64
> clang+llvm-3.9.1-rc2-aarch64-linux-gnu.tar.xz
ARM RC2 validated and uploaded.

Found a bug fixed by r283299. Created PR31238. Backported as r288513.

MD5: 5c91906438dd39889df55328496a66ed
clang+llvm-3.9.1-rc2-armv7a-linux-gnueabihf.tar.xz

Everything else, clean.

cheers,
--renato

On Thu, Dec 1, 2016 at 7:53 PM, Tom Stellard via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> Hi,
>
> I just tagged 3.9.1-rc2, so testing can begin.  There was a bug found in
> -rc1 before I could send out a release announcement, so I decided to merge
> the fix and tag -rc2 to save some testing cycles.
Windows looks good and the binaries are uploaded: (sha1sum)

0d0425c3e77ddad8b885ceb66513a3ab85738da8  LLVM-3.9.1-rc2-win32.exe
efc721b59fdfe4b51a71800966c70a872efe897f  LLVM-3.9.1-rc2-win64.exe

They were built with the attached batch file.

Cheers,
Hans
-------------- next part --------------
A non-text attachment was scrubbed...
Name: build_llvm_391-rc2._bat_
Type: application/octet-stream
Size: 3581 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161202/966160af/attachment.obj>

On Thu, Dec 1, 2016 at 9:53 PM, Tom Stellard via Release-testers <
release-testers at lists.llvm.org> wrote:
> Hi,
>
> I just tagged 3.9.1-rc2, so testing can begin.  There was a bug found in
> -rc1 before I could send out a release announcement, so I decided to merge
> the fix and tag -rc2 to save some testing cycles.
>
>
>
SLES11SP3 fails during tests.

[ 92%] Building CXX object
unittests/MC/CMakeFiles/MCTests.dir/StringTableBuilderTest.cpp.o
/tmp/llvm/utils/release/rc2/llvm.src/unittests/ExecutionEngine/Orc/RPCUtilsTest.cpp:37:27:
error: no member named 'yield' in namespace 'std::this_thread'
        std::this_thread::yield();
        ~~~~~~~~~~~~~~~~~~^
[ 92%] Building CXX object
unittests/MC/CMakeFiles/MCTests.dir/TargetRegistry.cpp.o
1 error generated.



It looks like it's only present when _GLIBCXX_USE_SCHED_YIELD.  I'll see
if
I can figure out why it would be packaged this way unless anyone knows off
the top of their head.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161202/0e79261b/attachment-0001.html>

On 02 Dec 2016, at 04:53, Tom Stellard via Release-testers <release-testers
at lists.llvm.org> wrote:
> 
> I just tagged 3.9.1-rc2, so testing can begin.  There was a bug found in
> -rc1 before I could send out a release announcement, so I decided to merge
> the fix and tag -rc2 to save some testing cycles.
Built and tested OK on FreeBSD 10:

SHA256 (clang+llvm-3.9.1-rc2-i386-unknown-freebsd10.tar.xz) =
4539345f89d75a18845b6e64dbcea7db20d841829e7b9d6dd02af35f7e003d53
SHA256 (clang+llvm-3.9.1-rc2-amd64-unknown-freebsd10.tar.xz) =
aae2a3df36af6d92b509a7c070a4cdd6491b298d3b599f6a6b28ef2ca43eccf0

-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/20161203/d98dc818/attachment.sig>

Hi Tom,

There is a bug in upstream LLVM that existed in LLVM 3.9.0 as well so
it likely exists in the 3.9.1 rc too.

I've just put the patch up for review (
https://reviews.llvm.org/D27393 ). Once a fix is approved you may want
to back port it to the 3.9 release branch.

Thanks,
Dan.

Here's the failing tests for rc2 on SLES11.3 (glibc 2.11, libstdc++4.7).
I've done some amount of triaging what some critical elements of the
failures are.  Unabridged log is attached.

Failing Tests (94):
    LLVM-Unit :: ExecutionEngine/Orc/OrcJITTests/DummyRPC.TestAsyncIntInt
    LLVM-Unit :: ExecutionEngine/Orc/OrcJITTests/DummyRPC.TestAsyncVoidBool
    LLVM-Unit :: ExecutionEngine/Orc/OrcJITTests/DummyRPC.TestSerialization
    LLVM-Unit :: Support/SupportTests/ThreadPoolTest.Async
    LLVM-Unit :: Support/SupportTests/ThreadPoolTest.AsyncBarrier
    LLVM-Unit :: Support/SupportTests/ThreadPoolTest.AsyncBarrierArgs
    LLVM-Unit :: Support/SupportTests/ThreadPoolTest.GetFuture
    LLVM-Unit :: Support/SupportTests/ThreadPoolTest.PoolDestruction

All of these ^^ failed with:

terminate called after throwing an instance of 'std::future_error'
  what():  No associated state



    AddressSanitizer-x86_64-linux ::
TestCases/Linux/interface_symbols_linux.c

This fails with "sed: invalid option -- 'E'".  The OS X
manpage (
https://developer.apple.com/legacy/library/documentation/Darwin/Reference/ManPages/man1/sed.1.html)
says "The -E, -a and -i options are non-standard FreeBSD extensions and may
not be available on other operating systems."  It's present in GNU sed
4.2.2 but absent from sed 4.1.5 on SLES11.3.


    AddressSanitizer-x86_64-linux :: TestCases/Linux/new_delete_mismatch.cc

This fails with "syntax error near unexpected token `&'"
because  "|&"
shortcut is not yet supported in bash 3.2.

    Clang Tools :: include-fixer/include_path.cpp
    Clang Tools :: include-fixer/merge.test
    LLVM :: ExecutionEngine/MCJIT/remote/cross-module-a.ll
    LLVM :: ExecutionEngine/MCJIT/remote/eh.ll
    LLVM :: ExecutionEngine/MCJIT/remote/multi-module-a.ll
    LLVM :: ExecutionEngine/MCJIT/remote/simpletest-remote.ll
    LLVM :: ExecutionEngine/MCJIT/remote/stubs-remote.ll
    LLVM :: ExecutionEngine/MCJIT/remote/test-common-symbols-remote.ll
    LLVM :: ExecutionEngine/MCJIT/remote/test-data-align-remote.ll
    LLVM :: ExecutionEngine/MCJIT/remote/test-fp-no-external-funcs-remote.ll
    LLVM :: ExecutionEngine/MCJIT/remote/test-global-init-nonzero-remote.ll
    LLVM :: ExecutionEngine/MCJIT/remote/test-global-init-nonzero-sm-pic.ll
    LLVM :: ExecutionEngine/MCJIT/remote/test-ptr-reloc-remote.ll
    LLVM :: ExecutionEngine/MCJIT/remote/test-ptr-reloc-sm-pic.ll
    LLVM :: ExecutionEngine/OrcMCJIT/remote/cross-module-a.ll
    LLVM :: ExecutionEngine/OrcMCJIT/remote/eh.ll
    LLVM :: ExecutionEngine/OrcMCJIT/remote/multi-module-a.ll
    LLVM :: ExecutionEngine/OrcMCJIT/remote/simpletest-remote.ll
    LLVM :: ExecutionEngine/OrcMCJIT/remote/stubs-remote.ll
    LLVM :: ExecutionEngine/OrcMCJIT/remote/test-common-symbols-remote.ll
    LLVM :: ExecutionEngine/OrcMCJIT/remote/test-data-align-remote.ll
    LLVM ::
ExecutionEngine/OrcMCJIT/remote/test-fp-no-external-funcs-remote.ll
    LLVM ::
ExecutionEngine/OrcMCJIT/remote/test-global-init-nonzero-remote.ll
    LLVM ::
ExecutionEngine/OrcMCJIT/remote/test-global-init-nonzero-sm-pic.ll
    LLVM :: ExecutionEngine/OrcMCJIT/remote/test-ptr-reloc-remote.ll
    LLVM :: ExecutionEngine/OrcMCJIT/remote/test-ptr-reloc-sm-pic.ll
    LLVM :: LTO/X86/parallel.ll
    LLVM :: ThinLTO/X86/cache.ll
    LLVM :: ThinLTO/X86/funcimport.ll
    LLVM :: tools/llvm-cov/binary-formats.c
    LLVM :: tools/llvm-cov/combine_expansions.cpp
    LLVM :: tools/llvm-cov/cov-comdat.test
    LLVM :: tools/llvm-cov/demangle.test
    LLVM :: tools/llvm-cov/double_dots.c
    LLVM :: tools/llvm-cov/prefer_used_to_unused.h
    LLVM :: tools/llvm-cov/prevent_false_instantiations.h

All of these ^^ also fail with "terminate called after throwing an instance
of 'std::future_error' what():  No associated state".

    LLVM :: tools/llvm-cov/showExpansions.cpp

This one fails like:

/tmp/llvm/utils/release/rc2/llvm.src/test/tools/llvm-cov/showExpansions.cpp:19:15:
error: expected string not found in input
// CHECK-DAG: Expansion at line [[@LINE-4]], 7 -> 24
              ^
<stdin>:1:1: note: scanning from here
warning: profile data may be out of date - object is newer
^
<stdin>:1:1: note: with expression "@LINE-4" equal to
"15"
warning: profile data may be out of date - object is newer
^


    LLVM :: tools/llvm-cov/showHighlightedRanges.cpp
    LLVM :: tools/llvm-cov/showLineExecutionCounts.cpp
    LLVM :: tools/llvm-cov/showRegionMarkers.cpp
    LLVM :: tools/llvm-cov/showTemplateInstantiations.cpp
    LLVM :: tools/llvm-cov/universal-binary.c
    LLVM :: tools/llvm-cov/warnings.h

These ^^ fail with "std::future_error / No associated state" as well.

    MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.fgetgrent_r
    MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getgrent
    MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getgrent_r

These don't confess why they failed in the log.

    MemorySanitizer-Unit ::
Msan-x86_64-Test/MemorySanitizer.gethostbyname_r_bad_host_name

This one fails like so:

[ RUN      ] MemorySanitizer.gethostbyname_r_bad_host_name
/tmp/llvm/utils/release/rc2/llvm.src/projects/compiler-rt/lib/msan/tests/msan_test.cc:1114:
Failure
Value of: result
  Actual: 0x7fff577579b8
Expected: (struct hostent *)0
Which is: NULL
[  FAILED  ] MemorySanitizer.gethostbyname_r_bad_host_name (160 ms)


    MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getpwent
    MemorySanitizer-Unit :: Msan-x86_64-Test/MemorySanitizer.getpwent_r
    MemorySanitizer-Unit ::
Msan-x86_64-with-call-Test/MemorySanitizer.fgetgrent_r
    MemorySanitizer-Unit ::
Msan-x86_64-with-call-Test/MemorySanitizer.getgrent
    MemorySanitizer-Unit ::
Msan-x86_64-with-call-Test/MemorySanitizer.getgrent_r
    MemorySanitizer-Unit ::
Msan-x86_64-with-call-Test/MemorySanitizer.gethostbyname_r_bad_host_name

These ^^ tests fail in same fashion as above without the "with-call".

    MemorySanitizer-Unit ::
Msan-x86_64-with-call-Test/MemorySanitizer.getpwent
    MemorySanitizer-Unit ::
Msan-x86_64-with-call-Test/MemorySanitizer.getpwent_r
    MemorySanitizer-x86_64 :: Linux/obstack.cc
    MemorySanitizer-x86_64 :: Linux/process_vm_readv.cc
    MemorySanitizer-x86_64 :: fork.cc
    MemorySanitizer-x86_64 :: iconv.cc

^^ fail with the new bash redirection alias.

    Profile-x86_64 :: Linux/coverage_ctors.cpp
    Profile-x86_64 :: Linux/coverage_dtor.cpp
    Profile-x86_64 :: Linux/coverage_shared.test
    Profile-x86_64 :: Linux/coverage_test.cpp
    Profile-x86_64 :: Linux/extern_template.test
    Profile-x86_64 :: Linux/instrprof-comdat.test
    Profile-x86_64 :: instrprof-visibility.cpp

^^ std::future_error

    SanitizerCommon-Unit ::
Sanitizer-x86_64-Test/SanitizerLinux.ThreadDescriptorSize

/tmp/llvm/utils/release/rc2/llvm.src/projects/compiler-rt/lib/sanitizer_common/tests/sanitizer_linux_test.cc:230:
Failure
Value of: ThreadDescriptorSize()
  Actual: 2288
Expected: (uptr)result
Which is: 2304


    Scudo :: alignment.cpp
    Scudo :: double-free.cpp
    Scudo :: malloc.cpp
    Scudo :: memalign.cpp
    Scudo :: mismatch.cpp
    Scudo :: overflow.cpp
    Scudo :: preinit.cpp
    Scudo :: quarantine.cpp
    Scudo :: realloc.cpp
    Scudo :: sized-delete.cpp
    Scudo :: sizes.cpp

These ^^ fail to find libatomic when linking.  This was added to
libstdc++4.8 but is not present in 4.7.  "Due to time constraints and an
API which is not finalized, there is no libatomic supplied with GCC 4.7. "
from https://gcc.gnu.org/wiki/Atomic/GCCMM

    ThreadSanitizer-x86_64 :: Linux/mutex_robust.cc
    ThreadSanitizer-x86_64 :: Linux/mutex_robust2.cc

These fail to find pthread_mutexattr_getrobust while linking.  pthread.h on
SLES11.3 defines pthread_mutexattr_getrobust and
pthread_mutexattr_getrobust_np (depending on options like __USE_GNU) but
libpthread contains only pthread_mutexattr_getrobust_np.

    ThreadSanitizer-x86_64 :: thread_name2.cc

^^ glibc 2.11 doesn't include 'pthread_setname_np'.

    libc++ :: std/depr/depr.c.headers/uchar_h.pass.cpp

^^ glibc doesn't get uchar until 2.16.

    libc++ ::
std/diagnostics/syserr/syserr.errcat/syserr.errcat.objects/generic_category.pass.cpp
    libc++ ::
std/diagnostics/syserr/syserr.errcat/syserr.errcat.objects/system_category.pass.cpp

^^ these tests fail the 'msg == "Unknown error -1" '
assertion.  I don't
see an obvious reason for why this would fail.



On Fri, Dec 2, 2016 at 6:37 PM, Brian Cain <brian.cain at gmail.com>
wrote:
>
>
> On Thu, Dec 1, 2016 at 9:53 PM, Tom Stellard via Release-testers <
> release-testers at lists.llvm.org> wrote:
>
>> Hi,
>>
>> I just tagged 3.9.1-rc2, so testing can begin.  There was a bug found
in
>> -rc1 before I could send out a release announcement, so I decided to
merge
>> the fix and tag -rc2 to save some testing cycles.
>>
>>
>>
> SLES11SP3 fails during tests.
>
> [ 92%] Building CXX object unittests/MC/CMakeFiles/MCTests.dir/
> StringTableBuilderTest.cpp.o
>
/tmp/llvm/utils/release/rc2/llvm.src/unittests/ExecutionEngine/Orc/RPCUtilsTest.cpp:37:27:
> error: no member named 'yield' in namespace
'std::this_thread'
>         std::this_thread::yield();
>         ~~~~~~~~~~~~~~~~~~^
> [ 92%] Building CXX object unittests/MC/CMakeFiles/
> MCTests.dir/TargetRegistry.cpp.o
> 1 error generated.
>
>
>
> It looks like it's only present when _GLIBCXX_USE_SCHED_YIELD. 
I'll see
> if I can figure out why it would be packaged this way unless anyone knows
> off the top of their head.
>


-- 
-Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161204/8770fdc7/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: llvm.check-Phase3-Release.log
Type: text/x-log
Size: 372087 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161204/8770fdc7/attachment-0001.bin>

All good for debian8 x86_64 and MIPS/MIPSEL:

95e43919516c916b885bb791ff361ec43e111215 
clang+llvm-3.9.1-rc2-mipsel-linux-gnu.tar.xz
fc5fee5b1c014e9c5886c1dd09a0a61e36904653 
clang+llvm-3.9.1-rc2-mips-linux-gnu.tar.xz
1d3b3aca4141ab63bd392c0665d669abb6faccc0 
clang+llvm-3.9.1-rc2-x86_64-linux-gnu-debian8.tar.xz

I'll run a few more tests for MIPSEL but I'm not expecting any problems.
I'll report back if there's any test failure.

- V. Kalintiris

Le 01/12/2016 à 17:53, Tom Stellard via Release-testers a écrit
:
> Hi,
>
> I just tagged 3.9.1-rc2, so testing can begin.  There was a bug found in
> -rc1 before I could send out a release announcement, so I decided to merge
> the fix and tag -rc2 to save some testing cycles.
>
> We can always use more testers, so if you are interested in helping, let
> me know.
Looking great on Debian on all archs (except armel but this is not a 
recent regression).

Sylvestre