Dear testers,
8.0.0-rc1 was just tagged (from the branch at r351980).
It took a little longer than planned, but it's looking good.
Please run the test script, share your results, and upload binaries.
I'll get the source tarballs and docs published as soon as possible,
and binaries as they become available.
Thanks,
Hans
The sources and docs are ready: https://prereleases.llvm.org/8.0.0/
Binaries will be uploaded as they become available.
Thanks,
Hans
Unfortunately I'm running into a problem with check-all, where it fails to link XRayTest-x86_64-Test:
[100%] Generating XRayTest-x86_64-Test
/home/dim/llvm/8.0.0/rc1/Phase3/Release/llvmCore-8.0.0-rc1.obj/./lib/libLLVMSupport.a(Signals.cpp.o): In function `llvm::sys::PrintStackTrace(llvm::raw_ostream&)':
Signals.cpp:(.text._ZN4llvm3sys15PrintStackTraceERNS_11raw_ostreamE+0x24): undefined reference to `backtrace'
Signals.cpp:(.text._ZN4llvm3sys15PrintStackTraceERNS_11raw_ostreamE+0x254): undefined reference to `llvm::itaniumDemangle(char const*, char*, unsigned long*, int*)'
clang-8: error: linker command failed with exit code 1 (use -v to see invocation)
gmake[3]: *** [projects/compiler-rt/lib/xray/tests/unit/CMakeFiles/TXRayTest-x86_64-Test.dir/build.make:73: projects/compiler-rt/lib/xray/tests/unit/XRayTest-x86_64-Test] Error 1
gmake[3]: Target 'projects/compiler-rt/lib/xray/tests/unit/CMakeFiles/TXRayTest-x86_64-Test.dir/build' not remade because of errors.
gmake[2]: *** [CMakeFiles/Makefile2:33513: projects/compiler-rt/lib/xray/tests/unit/CMakeFiles/TXRayTest-x86_64-Test.dir/all] Error 2
gmake[2]: Target 'CMakeFiles/check-all.dir/all' not remade because of errors.
gmake[1]: *** [CMakeFiles/Makefile2:737: CMakeFiles/check-all.dir/rule] Error 2
gmake[1]: Target 'check-all' not remade because of errors.
gmake: *** [Makefile:277: check-all] Error 2
[Release Phase3] check-all failed
It appears this is because -lexecinfo is not passed to the link command line, but I'm unsure why this only seems to affect the XRay test. I'm investigating, but if anybody has a cluestick, please hit me. 
-Dimitry
Thanks for looking into it!
+dberris in case he has any ideas.
At this point, it looks very bad, with last-minute breaking changes
being added before the branching.
With Linux amd64 stand-alone builds, I have the following regressions:
- compiler-rt & LLDB fail at cmake when tests are enabled [1],
- libc++ fails to run tests [2].
Additionally, on (32-bit) x86:
- (llvm) JSONTest.Integers fails when built with newer versions
of gcc [3],
- (clang) CXX/dcl.dcl/dcl.attr/dcl.align/p8.cpp fails [4].
I suppose that's as far as I can go with the current level of breakage.
I'll reply with NetBSD results later.
[1]:https://bugs.llvm.org/show_bug.cgi?id=40443
[2]:https://bugs.llvm.org/show_bug.cgi?id=40445
[3]:https://bugs.llvm.org/show_bug.cgi?id=40274
[4]:https://bugs.llvm.org/show_bug.cgi?id=40449
We've been having similar issue on NetBSD in the past. Long story
short, the code around there is not using CMake rules to build stuff but
a custom compiler invocation, and therefore it does not inherit library
dependencies from CMake.
Short-term solution is to figure out what's missing and add it, with
appropriate conditionals.
Long-term solution (which is probably not suitable for 8.0.0) is to
rewrite that whole stuff. Probably could work by creating a custom
language for CMake that's like C but uses just-built clang, etc.
However, that's just my theory and I'm not 100% sure it'll work or how
much work it'd involve.
Yes, I'm attempting again with this diff applied:
--- llvm.src/projects/compiler-rt/cmake/config-ix.cmake
+++ llvm.src/projects/compiler-rt/cmake/config-ix.cmake
@@ -118,6 +118,7 @@ check_library_exists(dl dlopen "" COMPIL
check_library_exists(rt shm_open "" COMPILER_RT_HAS_LIBRT)
check_library_exists(m pow "" COMPILER_RT_HAS_LIBM)
check_library_exists(pthread pthread_create "" COMPILER_RT_HAS_LIBPTHREAD)
+check_library_exists(execinfo backtrace "" COMPILER_RT_HAS_LIBEXECINFO)
# Look for terminfo library, used in unittests that depend on LLVMSupport.
if(LLVM_ENABLE_TERMINFO)
--- llvm.src/projects/compiler-rt/lib/xray/tests/CMakeLists.txt
+++ llvm.src/projects/compiler-rt/lib/xray/tests/CMakeLists.txt
@@ -71,13 +71,14 @@ if (NOT APPLE)
endforeach()
# We also add the actual libraries to link as dependencies.
- list(APPEND XRAY_UNITTEST_LINK_FLAGS -lLLVMXRay -lLLVMSupport -lLLVMTestingSupport)
+ list(APPEND XRAY_UNITTEST_LINK_FLAGS -lLLVMXRay -lLLVMSupport -lLLVMDemangle -lLLVMTestingSupport)
endif()
append_list_if(COMPILER_RT_HAS_LIBM -lm XRAY_UNITTEST_LINK_FLAGS)
append_list_if(COMPILER_RT_HAS_LIBRT -lrt XRAY_UNITTEST_LINK_FLAGS)
append_list_if(COMPILER_RT_HAS_LIBDL -ldl XRAY_UNITTEST_LINK_FLAGS)
append_list_if(COMPILER_RT_HAS_LIBPTHREAD -pthread XRAY_UNITTEST_LINK_FLAGS)
+ append_list_if(COMPILER_RT_HAS_LIBEXECINFO -lexecinfo XRAY_UNITTEST_LINK_FLAGS)
endif()
macro(add_xray_unittest testname)
Now the next problem is a Asan:DEADLYSIGNAL which keeps on repeating endlessly.
-Dimitry
For compiler-rt and/or LLDB: is anyone else running into "FileCheck
target does not exist"?
https://bugs.llvm.org/show_bug.cgi?id=40443
Will try and figure it out tomorrow morning (in a few hours).
Best
Stefan
In https://llvm.org/svn/llvm-project/llvm/branches/release_80 I find
that RISCV is still in LLVM_EXPERIMENTAL_TARGETS_TO_BUILD. not
LLVM_TARGETS_TO_BUILD. I thought people had agreed to change that in
this release?
There are also at least a couple of fairly important patches that it
would be good to get back-ported into the release branch if possible
r352171 | asb | 2019-01-24 21:11:34 -0800 (Thu, 24 Jan 2019) | 12 lines
[RISCV] Custom-legalise i32 SDIV/UDIV/UREM on RV64M
r352169 | asb | 2019-01-24 21:04:00 -0800 (Thu, 24 Jan 2019) | 24 lines
[RISCV] Custom-legalise 32-bit variable shifts on RV64
Others that would be good, but perhaps not so important to get in:
r352240 | asb | 2019-01-25 13:06:47 -0800 (Fri, 25 Jan 2019) | 7 lines
[RISCV] Add another potential combine to {double,float}-bitmanip-dagcombines.ll
r352237 | apazos | 2019-01-25 12:22:49 -0800 (Fri, 25 Jan 2019) | 3 lines
Reapply: [RISCV] Set isAsCheapAsAMove for ADDI, ORI, XORI, LUI
r352211 | asb | 2019-01-25 08:04:04 -0800 (Fri, 25 Jan 2019) | 6 lines
[RISCV][NFC] s/f32/f64 in double-arith.ll
r352199 | asb | 2019-01-25 06:33:08 -0800 (Fri, 25 Jan 2019) | 8 lines
[RISCV] Add tests to demonstrate bitcasted fneg/fabs dagcombines
r352008 | apazos | 2019-01-23 18:31:23 -0800 (Wed, 23 Jan 2019) | 9 lines
[RISCV] Set isReMaterializable for ORI, XORI
The Windows binaries are ready:
$ sha256sum *8.0.0-rc1*.exe
95ccb3d19db763114b979fd10eb800b91b29a4e81d542260161976929b03c419
LLVM-8.0.0-rc1-win32.exe
03163ac1cdf133ec8f3dab5801cd1aa26cd2931fa0199083f334becaf34f3c6b
LLVM-8.0.0-rc1-win64.exe
They were built with the attached batch file.
build_llvm_800-rc1.bat|attachment (5.31 KB)
Looks good on Debian & Ubuntu (Disco) on all supported archs (still waiting for mipsel & mipsel64 but I am confident):
https://buildd.debian.org/status/package.php?p=llvm-toolchain-8&suite=experimental
https://launchpad.net/ubuntu/+source/llvm-toolchain-8/1:8~+rc1-1~exp1/
Note that it is now using a stage2 build (from -7) and that -8 will NOT ship with Debian Buster.
I will try to dig a bit more into testsuite results.
S
Hi,
working without immediately obvious regressions on OpenMandriva x86-64, x86, aarch64 and armv7hnl.
Since our 4.0 release is imminent, 8.0 won’t go in there, but it will be our main compiler the day after the release and been cut.
Would be nice to get the admin goto patches in to enable building the Linux kernel, but unfortunately that may be too big a change after RC?
ttyl
bero
Uploaded AArch64 binaries:
2c3bd3d686c3712ba5699e9a638bc849ddb0aae3
clang+llvm-8.0.0-rc1-aarch64-linux-gnu.tar.xz
Had one failure in check-all (memory sanitizer). I opened PR40511 for it [1].
I ran into some snags with ARM, I'm still figuring out if there's
something wrong with our infrastructure. Sorry about the delay!
Cheers,
Diana
Hi,
working without immediately obvious regressions on OpenMandriva x86-64, x86, aarch64 and armv7hnl.
Since our 4.0 release is imminent, 8.0 won't go in there, but it will be our main compiler the day after the release and been cut.Would be nice to get the admin goto patches in to enable building the Linux kernel, but unfortunately that may be too big a change after RC?
I'm definitely still open to considering those for llvm 8. I think it
depends on what they look like in the end, and when they land. But
they'll have to land on trunk first
Thanks,
Hans
The results on Darwin look clean. I’ve uploaded:
$ shasum -a 256 rc1/clang+llvm-8.0.0-rc1-x86_64-apple-darwin.tar.xz
2a02c93d62d3676e3782e5cb6751de5e518d212c84296ec0c3e1f7d514b3d0a8 rc1/clang+llvm-8.0.0-rc1-x86_64-apple-darwin.tar.xz
thanks,
vedant
SLES and Ubuntu 14.04 tarballs uploaded. Sorry for the delay. I will try and find time to make a build for bionic / 18.04 too.
99ec00702e39b096ace4fbce3d787b9e485b879e clang+llvm-8.0.0-rc1-x86_64-linux-gnu-ubuntu-14.04.tar.xz
dbf204f70cb09ec459e5eb4fc14e8fa71292daa7 clang+llvm-8.0.0-rc1-x86_64-linux-sles11.3.tar.xz
ARM looks good. Uploaded.
358fc71b8021eddbb1b93142bc09f1ad698677a6
clang+llvm-8.0.0-rc1-armv7a-linux-gnueabihf.tar.xz
Cheers,
Diana
Alex, ping? There was a thread about moving Risc-V out of experimental
but I think it didn't go anywhere?
Separately, do the listed patches sound okay for merging?
Thanks,
Hans
Alex, ping? There was a thread about moving Risc-V out of experimental
but I think it didn't go anywhere?
I think it would make most sense to move RISC-V out of experimental to
become a standard target for the 9.0 release. It would have been nice
to be at that point prior to the 8.0 branch, but it hasn't been
possible with the resources I've had.
Separately, do the listed patches sound okay for merging?
I'm not fully sure what your policy is in merging patches for
experimental targets. It would be nice to merge r352169 and r352171 as
Bruce suggests though.
Best,
Alex
>
> Alex, ping? There was a thread about moving Risc-V out of experimental
> but I think it didn't go anywhere?I think it would make most sense to move RISC-V out of experimental to
become a standard target for the 9.0 release. It would have been nice
to be at that point prior to the 8.0 branch, but it hasn't been
possible with the resources I've had.
Okay, thanks for the update.
> Separately, do the listed patches sound okay for merging?
I'm not fully sure what your policy is in merging patches for
experimental targets. It would be nice to merge r352169 and r352171 as
Bruce suggests though.
I tried merging r352169 but there merge conflicts in
lib/Target/RISCV/RISCVInstrInfo.td,
test/CodeGen/RISCV/atomic-cmpxchg.ll and
test/CodeGen/RISCV/atomic-rmw.ll.
I didn't actually look at the conflicts, but since the target is still
in experimental and the merge isn't trivial, maybe it's not worth it?
I'm still happy to take them if someone wants to help me resolve the
conflicts though.
Thanks,
Hans