Hi,
I've tagged 3.8.1-rc1, testers can begin testing.
-Tom
Uploaded: clang+llvm-3.8.1-rc1-x86_64-linux-gnu-ubuntu-16.04.tar.xz:
Unexpected Passing Tests (4):
libc++ :: std/depr/depr.c.headers/math_h_isinf.pass.cpp
libc++ :: std/depr/depr.c.headers/math_h_isnan.pass.cpp
libc++ :: std/numerics/c.math/cmath_isinf.pass.cpp
libc++ :: std/numerics/c.math/cmath_isnan.pass.cpp
This is my first time trying to build on aarch64-linux-gnu (I suspect somebody else is covering this for the release testing, I'm just trying it for my own enjoyment), but I get this error:
Building C object projects/libunwind/src/CMakeFiles/unwind.dir/UnwindRegistersRestore.S.o
cd /home/ben/development/llvm/3.8.1/rc1/Phase1/Release/llvmCore-3.8.1-rc1.obj/projects/libunwind/src && /usr/bin/cc -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Dunwind_EXPORTS -I/home/ben/development/llvm/3.8.1/rc1/Phase1/Release/llvmCore-3.8.1-rc1.obj/projects/libunwind/src -I/home/ben/development/llvm/3.8.1/rc1/llvm.src/projects/libunwind/src -I/home/ben/development/llvm/3.8.1/rc1/Phase1/Release/llvmCore-3.8.1-rc1.obj/include -I/home/ben/development/llvm/3.8.1/rc1/llvm.src/include -I/home/ben/development/llvm/3.8.1/rc1/llvm.src/projects/libunwind/include -fPIC -Wall -W -Wno-unused-parameter -Wwrite-strings -Wno-missing-field-initializers -pedantic -Wno-long-long -Wno-comment -Werror=date-time -ffunction-sections -fdata-sections -O3 -DNDEBUG -fPIC -Werror=return-type -W -Wall -Wchar-subscripts -Wconversion -Wmissing-braces -Wno-unused-function -Wshadow -Wsign-compare -Wsign-conversion -Wstrict-aliasing=2 -Wstrict-overflow=4 -Wunused-parameter -Wunused-variable -Wwrite-strings -Wundef -Wno-error -pedantic -D_DEBUG -UNDEBUG -fPIC -fno-exceptions -funwind-tables -o CMakeFiles/unwind.dir/UnwindRegistersRestore.S.o -c /home/ben/development/llvm/3.8.1/rc1/llvm.src/projects/libunwind/src/UnwindRegistersRestore.S
/home/ben/development/llvm/3.8.1/rc1/llvm.src/projects/libunwind/src/UnwindRegistersRestore.S:270:74: warning: invoking macro GLUE2 argument 1: empty macro arguments are undefined in ISO C90 [-Wpedantic]
DEFINE_LIBUNWIND_PRIVATE_FUNCTION(_ZN9libunwind15Registers_arm646jumptoEv)
^
/home/ben/development/llvm/3.8.1/rc1/llvm.src/projects/libunwind/src/UnwindRegistersRestore.S:270:74: warning: invoking macro GLUE2 argument 1: empty macro arguments are undefined in ISO C90 [-Wpedantic]
/home/ben/development/llvm/3.8.1/rc1/llvm.src/projects/libunwind/src/UnwindRegistersRestore.S:270:74: warning: invoking macro GLUE2 argument 1: empty macro arguments are undefined in ISO C90 [-Wpedantic]
/home/ben/development/llvm/3.8.1/rc1/llvm.src/projects/libunwind/src/UnwindRegistersRestore.S:270:74: warning: invoking macro GLUE2 argument 1: empty macro arguments are undefined in ISO C90 [-Wpedantic]
/home/ben/development/llvm/3.8.1/rc1/llvm.src/projects/libunwind/src/UnwindRegistersRestore.S: Assembler messages:
/home/ben/development/llvm/3.8.1/rc1/llvm.src/projects/libunwind/src/UnwindRegistersRestore.S:285: Error: operand 2 should be an integer register -- `ldp x28,fp,[x0,#0x0E0]'
/home/ben/development/llvm/3.8.1/rc1/llvm.src/projects/libunwind/src/UnwindRegistersRestore.S:286: Error: operand 1 should be an integer register -- `ldr lr,[x0,#0x100]'
/home/ben/development/llvm/3.8.1/rc1/llvm.src/projects/libunwind/src/UnwindRegistersRestore.S:309: Error: operand 1 should be an integer register -- `ret lr'
projects/libunwind/src/CMakeFiles/unwind.dir/build.make:182: recipe for target 'projects/libunwind/src/CMakeFiles/unwind.dir/UnwindRegistersRestore.S.o' failed
Any suggestions welcome.
The system is Ubuntu 16.04 on a 2GB Pine64+ (quad core ARM A53).
Ben
This is my first time trying to build on aarch64-linux-gnu (I suspect
somebody else is covering this for the release testing, I'm just trying it
for my own enjoyment), but I get this error:
Hi Ben,
Indeed, I'm doing the release on an old and stable Linux, to mimic
what people had before the ABI move.
I had a few libunwind/libc++ issues on AArch64, but they were related
to GNU problems, so the way I build now (not for the release) is to
get no libc++/unwind on stage 1 and then use stage1's Clang to build
libunwind:
http://buildmaster.tcwglab.linaro.org/builders/clang-cmake-aarch64-prototype
Builds fine, but there are some errors in stage2's test.
Assembler messages:
/home/ben/development/llvm/3.8.1/rc1/llvm.src/projects/libunwind/src/UnwindRegistersRestore.S:285:
Error: operand 2 should be an integer register -- `ldp x28,fp,[x0,#0x0E0]'
/home/ben/development/llvm/3.8.1/rc1/llvm.src/projects/libunwind/src/UnwindRegistersRestore.S:286:
Error: operand 1 should be an integer register -- `ldr lr,[x0,#0x100]'
/home/ben/development/llvm/3.8.1/rc1/llvm.src/projects/libunwind/src/UnwindRegistersRestore.S:309:
Error: operand 1 should be an integer register -- `ret lr'
Maybe your version of GAS doesn't support FP/LR? Mine is binutils
2.25, gcc 4.9.2.
cheers,
--renato
>Hi,
>
>I've tagged 3.8.1-rc1, testers can begin testing.
>
>-TomUploaded: clang+llvm-3.8.1-rc1-x86_64-linux-gnu-ubuntu-16.04.tar.xz:
Unexpected Passing Tests (4):
libc++ :: std/depr/depr.c.headers/math_h_isinf.pass.cpp
libc++ :: std/depr/depr.c.headers/math_h_isnan.pass.cpp
libc++ :: std/numerics/c.math/cmath_isinf.pass.cpp
libc++ :: std/numerics/c.math/cmath_isnan.pass.cpp********************
Failing Tests (124):
There where a number of sanitizer patches backported to the 3.8 branch.
Can anyone bisect these failures?
-Tom
All green for AArch64 with old ABI, and no libc++ & friends. Image uploaded.
Once we have a green libc++ buildbot we'll start shipping them for AArch64, too.
ARM is still in progress.
cheers,
--renato
This is fixed by
http://llvm.org/viewvc/llvm-project?view=revision&revision=271060
ismail
Hi,
ARM is green, the binaries have been uploaded.
Regards,
Diana
Green on most of the Debian main archs:
https://buildd.debian.org/status/package.php?p=llvm-toolchain-3.8&suite=experimental
The armel & mipsel build issue are not regressions from 3.8 (but are
from 3.7)
Cheers,
Sylvestre
Windows looks good, binaries uploaded: (sha1sum)
d1a1c3ab904abda822b94a4084a593edf0ac2a36 LLVM-3.8.1-rc1-win32.exe
04ef1d5965ce32dc1ce61bec04ad0f4fc21a5fd0 LLVM-3.8.1-rc1-win64.exe
Cheers,
Hans
> Hi,
>
> I've tagged 3.8.1-rc1, testers can begin testing.
>
> -TomUploaded: clang+llvm-3.8.1-rc1-x86_64-linux-gnu-ubuntu-16.04.tar.xz:
Hi Ben,
I'm having trouble reproducing these failures on my Fedora system,
are you using the test-release.sh script? If so, what arguments
did you use?
-Tom
Hi,
I had a quick look at that link and it seems to be a linker internal error. Presumably we're triggering a bug in the system toolchain.
FWIW, my mipsel build on a Debian Jessie machine (binutils 2.24.90.20141023-1) successfully completed test-release.sh. I'm currently running the tests.
Here's the relevant bit of the log from your link:
cd "/«BUILDDIR»/llvm-toolchain-3.8-3.8.1~+rc1/build-llvm/tools/clang/lib/StaticAnalyzer/Checkers" && /usr/bin/g++-5 -DCLANG_ENABLE_ARCMT -DCLANG_ENABLE_OBJC_REWRITER -DCLANG_ENABLE_STATIC_ANALYZER -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I"/«BUILDDIR»/llvm-toolchain-3.8-3.8.1~+rc1/build-llvm/tools/clang/lib/StaticAnalyzer/Checkers" -I"/«BUILDDIR»/llvm-toolchain-3.8-3.8.1~+rc1/tools/clang/lib/StaticAnalyzer/Checkers" -I"/«BUILDDIR»/llvm-toolchain-3.8-3.8.1~+rc1/tools/clang/include" -I"/«BUILDDIR»/llvm-toolchain-3.8-3.8.1~+rc1/build-llvm/tools/clang/include" -I"/«BUILDDIR»/llvm-toolchain-3.8-3.8.1~+rc1/build-llvm/include" -I"/«BUILDDIR»/llvm-toolchain-3.8-3.8.1~+rc1/include" -std=c++0x -fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wno-maybe-uninitialized -Wdelete-non-virtual-dtor -Wno-comment -std=c++11 -ffunction-sections -fdata-sections -fno-common -Woverloaded-virtual -fno-strict-aliasing -O2 -g -DNDEBUG -fno-exceptions -o CMakeFiles/clangStaticAnalyzerCheckers.dir/FixedAddressChecker.cpp.o -c "/«BUILDDIR»/llvm-toolchain-3.8-3.8.1~+rc1/tools/clang/lib/StaticAnalyzer/Checkers/FixedAddressChecker.cpp"
/usr/bin/ld: BFD (GNU Binutils for Debian) 2.26 internal error, aborting at ../../bfd/merge.c:909 in _bfd_merged_section_offset
/usr/bin/ld: Please report this bug.
collect2: error: ld returned 1 exit status
Uploaded Fedora and openSUSE binaries. Test suite is green but I’m seeing two libc++ test failures when running check-all. I’m pretty sure these were present in 3.8.0, am I supposed to file bug reports for them?
If they're not regressions, do nothing.
You may want to open bugs for them, but I'm guessing there are already
some. None of them are blockers to the release, though.
cheers,
--renato
Test suite is green but I’m seeing two libc++ test failures when running check-all.
What tests are failing?
std/localization/locale.categories/category.time/locale.time.get.byname/get_monthname.pass.cpp
std/localization/locale.categories/category.time/locale.time.get.byname/get_monthname_wide.pass.cpp
This is on 64bit Fedora, my locale is en_AU.UTF-8
If you tell me how to run these tests individually I could investigate more?
Hi,
I already looked into them: They are known to not work with newer glibcs and will be gone in 3.9.
See http://reviews.llvm.org/rL263554
Cheers,
Jonas
clang+llvm-3.8.1-rc1-x86_64-linux-gnu-debian8.tar.xz (sha1sum 85baf8a1ecdf85c4ba1f2b09fa7156842d1cc5fb)
Native:
All ok.
Cross compilation to various mips targets:
All ok.
clang+llvm-3.8.1-rc1-mips-linux-gnu.tar.xz (sha1sum 248f7b1a073f599f594af2db2f5bf79345e69ddd)
All ok.
I get 48 check-all failures but these are not regressions compared to 3.8.0.
The failures fall into two categories 64-bit atomics tests not linking to
libatomic, and 64-bit sanitizers (which we tried for the first time in 3.8.0
and ended up disabling).
AddressSanitizer-mips64-linux :: TestCases/Posix/coverage-direct-activation.cc
AddressSanitizer-mips64-linux :: TestCases/Posix/coverage-direct-large.cc
AddressSanitizer-mips64-linux :: TestCases/Posix/coverage-direct.cc
AddressSanitizer-mips64-linux :: TestCases/Posix/coverage-fork-direct.cc
AddressSanitizer-mips64-linux :: TestCases/Posix/coverage.cc
DataFlowSanitizer :: custom.cc
DataFlowSanitizer :: propagate.c
MemorySanitizer :: dlerror.cc
MemorySanitizer :: memcmp_test.cc
MemorySanitizer-Unit :: Msan-mips64-Test/MemorySanitizer.ptrtoint
MemorySanitizer-Unit :: Msan-mips64-with-call-Test/MemorySanitizer.ptrtoint
SanitizerCommon-asan :: Linux/getpwnam_r_invalid_user.cc
SanitizerCommon-lsan :: Linux/getpwnam_r_invalid_user.cc
ThreadSanitizer-mips64 :: atexit2.cc
ThreadSanitizer-mips64 :: deadlock_detector_stress_test.cc
ThreadSanitizer-mips64 :: java_alloc.cc
ThreadSanitizer-mips64 :: java_alloc.cc
ThreadSanitizer-mips64 :: java_race_pc.cc
ThreadSanitizer-mips64 :: longjmp.cc
ThreadSanitizer-mips64 :: longjmp2.cc
ThreadSanitizer-mips64 :: longjmp3.cc
ThreadSanitizer-mips64 :: longjmp4.cc
ThreadSanitizer-mips64 :: map32bit.cc
ThreadSanitizer-mips64 :: race_on_mutex.c
ThreadSanitizer-mips64 :: signal_longjmp.cc
libc++ :: std/atomics/atomics.types.generic/integral.pass.cpp
libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_compare_exchange_strong.pass.cpp
libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_compare_exchange_strong_explicit.pass.cpp
libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_compare_exchange_weak.pass.cpp
libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_compare_exchange_weak_explicit.pass.cpp
libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_exchange.pass.cpp
libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_exchange.pass.cpp
libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_exchange_explicit.pass.cpp
libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_fetch_add.pass.cpp
libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_fetch_add_explicit.pass.cpp
libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_fetch_and.pass.cpp
libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_fetch_and_explicit.pass.cpp
libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_fetch_or.pass.cpp
libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_fetch_or_explicit.pass.cpp
libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_fetch_sub.pass.cpp
libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_fetch_sub_explicit.pass.cpp
libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_fetch_xor.pass.cpp
libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_fetch_xor_explicit.pass.cpp
libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_init.pass.cpp
libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_is_lock_free.pass.cpp
libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_load.pass.cpp
libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_load.pass.cpp
libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_load_explicit.pass.cpp
libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_store.pass.cpp
libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/atomic_store_explicit.pass.cpp
libc++ :: std/atomics/atomics.types.operations/atomics.types.operations.req/ctor.pass.cpp
clang+llvm-3.8.1-rc1-mipsel-linux-gnu.tar.xz (sha1sum a57b2355686f20d56d69199ef9c237a4378f1fbf)
All ok.
I get the same libc++ failures as the mips-linux-gnu build above but these
aren't regressions. I don't get the mips64 sanitizer failures because this
is still disabled on this machine (the necessary multilibs aren't present).
Hi,
I've tagged 3.8.1-rc1, testers can begin testing.
Hi,
The test results seem good, so I'll tag -final on Monday.
-Tom
Hi,
we did some testing in OpenMandriva (sadly not as much as we wanted – we’re currently a little overloaded getting our own upcoming release from beta 2 to final). Looks good overall, but we found one regression:
https://llvm.org/bugs/show_bug.cgi?id=28147
ttyl
bero