llvm dev - Nov 2015 - [cfe-dev] [3.7.1 Release] -rc2 has been tagged

On Sun, Nov 22, 2015 at 8:40 AM, Renato Golin <renato.golin at linaro.org>
wrote:
> On 22 November 2015 at 14:32, Brian Cain <brian.cain at gmail.com>
wrote:
> > AFAICT it's an OpenMP link error (that I got when running
> "test-release.sh"
> > with -openmp).
>
> Right. In that case, don't worry too much.
>
> The default release doesn't come with OpenMP, so unless you *want* and
> know it *works*, you don't need it.
>
>
Well, I preferred that my build would include openmp but didn't know
whether it worked, so was just checking.

So without openmp, I get nonzero "unexpected failures".  It's
fewer
failures than I saw on RC1 though.

$ clang --version
clang version 3.8.0 (http://llvm.org/git/clang.git
6b6df26f3b3b96552353a593bdc93333cf9ea6c3) (http://llvm.org/git/llvm.git
43928f790962f5f6d796416ae8c90b95efeaf01a)
Target: armv7l-unknown-linux-gnueabihf
Thread model: posix
InstalledDir: /opt/clang-latest/bin
...
  Expected Passes    : 22688
  Expected Failures  : 141
  Unsupported Tests  : 422
  Unexpected Passes  : 13
  Unexpected Failures: 31
...
********************
Failing Tests (31):
    libc++abi :: catch_array_01.pass.cpp
    libc++abi :: catch_array_02.pass.cpp
    libc++abi :: catch_class_01.pass.cpp
    libc++abi :: catch_class_02.pass.cpp
    libc++abi :: catch_class_03.pass.cpp
    libc++abi :: catch_class_04.pass.cpp
    libc++abi :: catch_const_pointer_nullptr.pass.cpp
    libc++abi :: catch_function_01.pass.cpp
    libc++abi :: catch_function_02.pass.cpp
    libc++abi :: catch_in_noexcept.pass.cpp
    libc++abi :: catch_member_data_pointer_01.pass.cpp
    libc++abi :: catch_member_function_pointer_01.pass.cpp
    libc++abi :: catch_member_pointer_nullptr.pass.cpp
    libc++abi :: catch_multi_level_pointer.pass.cpp
    libc++abi :: catch_pointer_nullptr.pass.cpp
    libc++abi :: catch_pointer_reference.pass.cpp
    libc++abi :: catch_ptr.pass.cpp
    libc++abi :: catch_ptr_02.pass.cpp
    libc++abi :: inherited_exception.pass.cpp
    libc++abi :: test_aux_runtime.pass.cpp
    libc++abi :: test_aux_runtime_op_array_new.pass.cpp
    libc++abi :: test_guard.pass.cpp
    libc++abi :: test_vector1.pass.cpp
    libc++abi :: test_vector2.pass.cpp
    libc++abi :: uncaught_exceptions.pass.cpp
    libc++abi :: unwind_01.pass.cpp
    libc++abi :: unwind_02.pass.cpp
    libc++abi :: unwind_03.pass.cpp
    libc++abi :: unwind_04.pass.cpp
    libc++abi :: unwind_05.pass.cpp
    libc++abi :: unwind_06.pass.cpp





-- 
-Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151122/ef01ef62/attachment.html>

On 22 November 2015 at 21:58, Brian Cain <brian.cain at gmail.com>
wrote:
> $ clang --version
> clang version 3.8.0 (http://llvm.org/git/clang.git
This looks wrong. Are you sure you're testing Phase3?

> ********************
> Failing Tests (31):
>     libc++abi :: catch_array_01.pass.cpp
>     libc++abi :: catch_array_02.pass.cpp
> (...)
I'm seeing these failures when building with Clang, too. That's why I
still don't release them as is for ARM.

However, the libc++ buildbot, which I assume is running the same
tests, is green, so it may just be a configuration issue that we
haven't solved in CMake yet.

http://lab.llvm.org:8011/builders/libcxx-libcxxabi-arm-linux

That's why I'm not too worried about it for now, but I don't want to
include in the release as of yet, until I'm sure what it is and fix
it.

cheers,
--renato

On Mon, Nov 23, 2015 at 3:30 AM, Renato Golin <renato.golin at linaro.org>
wrote:
> On 22 November 2015 at 21:58, Brian Cain <brian.cain at gmail.com>
wrote:
> > $ clang --version
> > clang version 3.8.0 (http://llvm.org/git/clang.git
>
> This looks wrong. Are you sure you're testing Phase3?
>
No, it was not Phase3.  I've R'd TFM now and I see that it's a
critical
step.  Thanks for pointing it out, sorry for confusion.

-- 
-Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151124/380dab8d/attachment.html>