[10.0.0 Release] Release Candidate 1 is here

Hello everyone,

It took a bit longer than planned due to master being a somewhat
unstable at the branch point, but Release Candidate 1 has now been
tagged as llvmorg-10.0.0-rc1.

Source code and docs are available at https://prereleases.llvm.org/10.0.0/#rc1

Pre-built binaries will be added there as they become available.

Please file bug reports for any issues you find as blockers of
https://llvm.org/pr44555

Release testers: please start your engines, run the script, share your
results, and upload binaries.

Release Candidate 2 was previously scheduled for February 2. Because
of the late RC1, I've pushed this back a bit to the 11th.

Thanks,
Hans

Would it be possible to get an update of the Windows snapshot builds to build 11.0 https://llvm.org/builds/

Thanks in advance

@MyDeveloperDay

For this rc, I used three patches, which are attached.

Main results on amd64-freebsd11 (I will post i386 results as they become
available):

  Expected Passes : 67894
  Expected Failures : 268
  Unsupported Tests : 4653
  Unexpected Passes : 5
  Unexpected Failures: 541
  Individual Timeouts: 18

Uploaded:
SHA256 (clang+llvm-10.0.0-rc1-amd64-unknown-freebsd11.tar.xz) = 751f2d86eede35a201db524a78ebb0e9d48b71d120b44153f961edb666d30c96

Unfortunately the test-suite did not build at all, as all the Bitcode
compilations failed with segfaults, similar to the following run under
gdb:

Starting program: /home/dim/llvm/10.0.0/rc1/Phase3/Release/llvmCore-10.0.0-rc1.install/usr/local/bin/clang++ -DNDEBUG -O3 -DNDEBUG -w -Werror=date-time -std=c++11 -MD -MT Bitcode/Benchmarks/Halide/local_laplacian/CMakeFiles/halide_local_laplacian.dir/__/common/x86_halide_runtime.bc.o -MF Bitcode/Benchmarks/Halide/local_laplacian/CMakeFiles/halide_local_laplacian.dir/__/common/x86_halide_runtime.bc.o.d -o Bitcode/Benchmarks/Halide/local_laplacian/CMakeFiles/halide_local_laplacian.dir/__/common/x86_halide_runtime.bc.o -c /home/dim/llvm/10.0.0/rc1/llvm-test-suite/Bitcode/Benchmarks/Halide/common/x86_halide_runtime.bc

Program received signal SIGSEGV, Segmentation fault.
0x000000010000000f in ?? ()
(gdb) bt
#0 0x000000010000000f in ?? ()
#1 0x00000000028ca9c0 in llvm::AAResultsWrapperPass::runOnFunction(llvm::Function&) ()
#2 0x0000000002e8edc0 in llvm::FPPassManager::runOnFunction(llvm::Function&) ()
#3 0x0000000002e8f1d3 in llvm::FPPassManager::runOnModule(llvm::Module&) ()
#4 0x0000000002e8f6a9 in llvm::legacy::PassManagerImpl::run(llvm::Module&) ()
#5 0x00000000035de7dc in clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout const&, llvm::Module*, clang::BackendAction, std::__1::unique_ptr<llvm::raw_pwrite_stream, std::__1::default_delete<llvm::raw_pwrite_stream> >) ()
#6 0x0000000003c17e67 in clang::CodeGenAction::ExecuteAction() ()
#7 0x0000000003b7abca in clang::FrontendAction::Execute() ()
#8 0x0000000003aea761 in clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) ()
#9 0x0000000003c12905 in clang::ExecuteCompilerInvocation(clang::CompilerInstance*) ()
#10 0x0000000001cbaf0e in cc1_main(llvm::ArrayRef<char const*>, char const*, void*) ()
#11 0x0000000001cb8f65 in ExecuteCC1Tool(llvm::SmallVectorImpl<char const*>&) ()
#12 0x00000000039eb297 in void llvm::function_ref<void ()>::callback_fn<clang::driver::CC1Command::Execute(llvm::ArrayRef<llvm::Optional<llvm::StringRef> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >*, bool*) const::$_1>(long) ()
#13 0x00000000033e406a in llvm::CrashRecoveryContext::RunSafely(llvm::function_ref<void ()>) ()
#14 0x00000000039ea7f0 in clang::driver::CC1Command::Execute(llvm::ArrayRef<llvm::Optional<llvm::StringRef> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >*, bool*) const ()
#15 0x00000000039bfc5c in clang::driver::Compilation::ExecuteCommand(clang::driver::Command const&, clang::driver::Command const*&) const ()
#16 0x00000000039c01ac in clang::driver::Compilation::ExecuteJobs(clang::driver::JobList const&, llvm::SmallVectorImpl<std::__1::pair<int, clang::driver::Command const*> >&) const ()
#17 0x00000000039d336c in clang::driver::Driver::ExecuteCompilation(clang::driver::Compilation&, llvm::SmallVectorImpl<std::__1::pair<int, clang::driver::Command const*> >&) ()
#18 0x0000000001cb884f in main ()

Looks like the bitcode compilation path is totally busted? Anybody know
an open bug for this?

-Dimitry

fix-clang-1.diff (447 Bytes)

fix-compiler-rt-1.diff (890 Bytes)

fix-test-suite-1.diff (552 Bytes)

Please file bug reports for any issues you find as blockers of

https://llvm.org/pr44555

Release testers: please start your engines, run the script, share your
results, and upload binaries.

Gentoo/amd64 issues (with 32-bit multilib where available):

- libc++ stand-alone builds were broken; revert was committed
  as 3573526c028; with that patch, all tests pass for me.

- there's one openmp issue on 32-bit build:
  https://bugs.llvm.org/show_bug.cgi?id=44733
  
- I've found an LLDB bug with linking liblldb.so in tests.
  I don't think it's strictly a regression but I don't recall noticing
  it before. I've started working on a patch:
  https://reviews.llvm.org/D73767

  However, I'm not sure if it's worth backporting. There's still
  a plethora of failing tests, plus some lit bug causing it to hang
  at the end, and I don't think I'll find time to look into any of this
  anytime soon.

Obtained the following error for Xubuntu/Ubuntu 19.10.

Testing: 0… 10… 20… 30… 40… 50… 60… 70.
FAIL: LLVM :: tools/llvm-ar/quick-append.test (53134 of 69456)
******************** TEST ‘LLVM :: tools/llvm-ar/quick-append.test’ FAILED ********************
Script:

Windows is ready:

$ sha256sum LLVM-10.0.0-rc1-win*.exe
d7d7e51c1b972b071222fb377cc8f828a43030c8bef7530a7b59a8b78126c657
LLVM-10.0.0-rc1-win32.exe
858c4cd712e89be723f5ed9366758e6d759bc0a71f557dce1580a28a61c1fe3e
LLVM-10.0.0-rc1-win64.exe

They were built with the attached batch file.

build_llvm_1000-rc1.bat|attachment (4.58 KB)

>
> It took a bit longer than planned due to master being a somewhat
> unstable at the branch point, but Release Candidate 1 has now been
> tagged as llvmorg-10.0.0-rc1.

For this rc, I used three patches, which are attached.

Main results on amd64-freebsd11 (I will post i386 results as they become
available):

  Expected Passes : 67894
  Expected Failures : 268
  Unsupported Tests : 4653
  Unexpected Passes : 5
  Unexpected Failures: 541
  Individual Timeouts: 18

Uploaded:
SHA256 (clang+llvm-10.0.0-rc1-amd64-unknown-freebsd11.tar.xz) = 751f2d86eede35a201db524a78ebb0e9d48b71d120b44153f961edb666d30c96

Thanks! I've added it to the pre-release page and also to the github release.

Unfortunately the test-suite did not build at all, as all the Bitcode
compilations failed with segfaults, similar to the following run under
gdb:

Starting program: /home/dim/llvm/10.0.0/rc1/Phase3/Release/llvmCore-10.0.0-rc1.install/usr/local/bin/clang++ -DNDEBUG -O3 -DNDEBUG -w -Werror=date-time -std=c++11 -MD -MT Bitcode/Benchmarks/Halide/local_laplacian/CMakeFiles/halide_local_laplacian.dir/__/common/x86_halide_runtime.bc.o -MF Bitcode/Benchmarks/Halide/local_laplacian/CMakeFiles/halide_local_laplacian.dir/__/common/x86_halide_runtime.bc.o.d -o Bitcode/Benchmarks/Halide/local_laplacian/CMakeFiles/halide_local_laplacian.dir/__/common/x86_halide_runtime.bc.o -c /home/dim/llvm/10.0.0/rc1/llvm-test-suite/Bitcode/Benchmarks/Halide/common/x86_halide_runtime.bc

Program received signal SIGSEGV, Segmentation fault.
0x000000010000000f in ?? ()
(gdb) bt
#0 0x000000010000000f in ?? ()
#1 0x00000000028ca9c0 in llvm::AAResultsWrapperPass::runOnFunction(llvm::Function&) ()
#2 0x0000000002e8edc0 in llvm::FPPassManager::runOnFunction(llvm::Function&) ()
#3 0x0000000002e8f1d3 in llvm::FPPassManager::runOnModule(llvm::Module&) ()
#4 0x0000000002e8f6a9 in llvm::legacy::PassManagerImpl::run(llvm::Module&) ()
#5 0x00000000035de7dc in clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout const&, llvm::Module*, clang::BackendAction, std::__1::unique_ptr<llvm::raw_pwrite_stream, std::__1::default_delete<llvm::raw_pwrite_stream> >) ()
#6 0x0000000003c17e67 in clang::CodeGenAction::ExecuteAction() ()
#7 0x0000000003b7abca in clang::FrontendAction::Execute() ()
#8 0x0000000003aea761 in clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) ()
#9 0x0000000003c12905 in clang::ExecuteCompilerInvocation(clang::CompilerInstance*) ()
#10 0x0000000001cbaf0e in cc1_main(llvm::ArrayRef<char const*>, char const*, void*) ()
#11 0x0000000001cb8f65 in ExecuteCC1Tool(llvm::SmallVectorImpl<char const*>&) ()
#12 0x00000000039eb297 in void llvm::function_ref<void ()>::callback_fn<clang::driver::CC1Command::Execute(llvm::ArrayRef<llvm::Optional<llvm::StringRef> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >*, bool*) const::$_1>(long) ()
#13 0x00000000033e406a in llvm::CrashRecoveryContext::RunSafely(llvm::function_ref<void ()>) ()
#14 0x00000000039ea7f0 in clang::driver::CC1Command::Execute(llvm::ArrayRef<llvm::Optional<llvm::StringRef> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >*, bool*) const ()
#15 0x00000000039bfc5c in clang::driver::Compilation::ExecuteCommand(clang::driver::Command const&, clang::driver::Command const*&) const ()
#16 0x00000000039c01ac in clang::driver::Compilation::ExecuteJobs(clang::driver::JobList const&, llvm::SmallVectorImpl<std::__1::pair<int, clang::driver::Command const*> >&) const ()
#17 0x00000000039d336c in clang::driver::Driver::ExecuteCompilation(clang::driver::Compilation&, llvm::SmallVectorImpl<std::__1::pair<int, clang::driver::Command const*> >&) ()
#18 0x0000000001cb884f in main ()

Looks like the bitcode compilation path is totally busted? Anybody know
an open bug for this?

I haven't seen one, but I'm behind on email. Can you please file one
to make sure this gets tracked?

Thanks,
Hans

Thanks for digging into these issues!

I didn't open any bugs yet, because as of yet I'm not sure the problem
isn't on my side.

I checked out the release branch (release/10.x) and configured to build
clang with compiler-rt enabled:

cmake -B build -S llvm -DCMAKE_BUILD_TYPE=Release
-DCMAKE_INSTALL_PREFIX=/usr/lib/llvm-10
-DLLVM_ENABLE_PROJECTS='clang;libcxx;libcxxabi;compiler-rt'

When I then build the program, it results in a linker error:

[ 79%] Linking CXX shared library
../../../../lib/clang/10.0.0/lib/linux/libclang_rt.hwasan-x86_64.so
/usr/bin/ld: CMakeFiles/RTHwasan_dynamic.x86_64.dir/hwasan.cpp.o:
relocation R_X86_64_PC32 against undefined symbol `__ehdr_start' can
not be used when making a shared object; recompile with -fPIC

Looking at the offending code, it mentions that it is supposed to be a
"statically linked executable":

  // In the non-static code path we call dl_iterate_phdr here. But at
this point
  // libc might not have been initialized enough for dl_iterate_phdr to
work.
  // Fortunately, since this is a statically linked executable we can
use the
  // linker-defined symbol __ehdr_start to find the only relevant set
of phdrs.
  extern ElfW(Ehdr) __ehdr_start;

Clearly, some of these assumptions aren't holding true and it's trying
to use this inside a shared object.

If I build clang without compiler-rt I do not get any linker errors and
the compiler works as expected. Is this a new bug or am I doing
something wrong?

Obtained the following error for Xubuntu/Ubuntu 19.10.

Testing: 0.. 10.. 20.. 30.. 40.. 50.. 60.. 70.
FAIL: LLVM :: tools/llvm-ar/quick-append.test (53134 of 69456)
******************** TEST 'LLVM :: tools/llvm-ar/quick-append.test' FAILED ********************

[...]

Command Output (stderr):
--
/home/nnelson/Documents/llvm-project/llvm/utils/release/rc1/llvm-project/llvm/test/tools/llvm-ar/quick-append.test:39:14: error: SAME-NEXT: is on the same line as previous match
# SAME-NEXT: 1.o
             ^
<stdin>:1:148: note: 'next' match was here
/home/nnelson/Documents/llvm-project/llvm/utils/release/rc1/Phase3/Release/llvmCore-10.0.0-rc1.obj/test/tools/llvm-ar/Output/quick-append.test.tmp/1.o
                                                                                                                                                   ^
<stdin>:1:97: note: previous match ended here
/home/nnelson/Documents/llvm-project/llvm/utils/release/rc1/Phase3/Release/llvmCore-10.0.0-rc1.obj/test/tools/llvm-ar/Output/quick-append.test.tmp/1.o
                                                                                                ^

Looks like the test is confused about the "1.o" part of the
"...-rc1.obj" build directory.

I've fixed that in f00ab188f4e4214dfbecfdd8968a183e9363cefa and
cherry-picked to the branch in
e11d70cfe7e2a8537eb774ed1780e9ecd1aa90a0

I didn't open any bugs yet, because as of yet I'm not sure the problem
isn't on my side.

I checked out the release branch (release/10.x) and configured to build
clang with compiler-rt enabled:

cmake -B build -S llvm -DCMAKE_BUILD_TYPE=Release
-DCMAKE_INSTALL_PREFIX=/usr/lib/llvm-10
-DLLVM_ENABLE_PROJECTS='clang;libcxx;libcxxabi;compiler-rt'

When I then build the program, it results in a linker error:

[ 79%] Linking CXX shared library
../../../../lib/clang/10.0.0/lib/linux/libclang_rt.hwasan-x86_64.so
/usr/bin/ld: CMakeFiles/RTHwasan_dynamic.x86_64.dir/hwasan.cpp.o:
relocation R_X86_64_PC32 against undefined symbol `__ehdr_start' can
not be used when making a shared object; recompile with -fPIC

[..]

If I build clang without compiler-rt I do not get any linker errors and
the compiler works as expected. Is this a new bug or am I doing
something wrong?

This sounds like https://bugs.llvm.org/show_bug.cgi?id=42994

Yes, I've just pushed a new one based on 2663a25f: http://llvm.org/builds/

...

Unfortunately the test-suite did not build at all, as all the Bitcode
compilations failed with segfaults, similar to the following run under
gdb:

Starting program: /home/dim/llvm/10.0.0/rc1/Phase3/Release/llvmCore-10.0.0-rc1.install/usr/local/bin/clang++ -DNDEBUG -O3 -DNDEBUG -w -Werror=date-time -std=c++11 -MD -MT Bitcode/Benchmarks/Halide/local_laplacian/CMakeFiles/halide_local_laplacian.dir/__/common/x86_halide_runtime.bc.o -MF Bitcode/Benchmarks/Halide/local_laplacian/CMakeFiles/halide_local_laplacian.dir/__/common/x86_halide_runtime.bc.o.d -o Bitcode/Benchmarks/Halide/local_laplacian/CMakeFiles/halide_local_laplacian.dir/__/common/x86_halide_runtime.bc.o -c /home/dim/llvm/10.0.0/rc1/llvm-test-suite/Bitcode/Benchmarks/Halide/common/x86_halide_runtime.bc

Program received signal SIGSEGV, Segmentation fault.
0x000000010000000f in ?? ()
(gdb) bt
#0 0x000000010000000f in ?? ()
#1 0x00000000028ca9c0 in llvm::AAResultsWrapperPass::runOnFunction(llvm::Function&) ()
#2 0x0000000002e8edc0 in llvm::FPPassManager::runOnFunction(llvm::Function&) ()
#3 0x0000000002e8f1d3 in llvm::FPPassManager::runOnModule(llvm::Module&) ()
#4 0x0000000002e8f6a9 in llvm::legacy::PassManagerImpl::run(llvm::Module&) ()
#5 0x00000000035de7dc in clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout const&, llvm::Module*, clang::BackendAction, std::__1::unique_ptr<llvm::raw_pwrite_stream, std::__1::default_delete<llvm::raw_pwrite_stream> >) ()
#6 0x0000000003c17e67 in clang::CodeGenAction::ExecuteAction() ()
#7 0x0000000003b7abca in clang::FrontendAction::Execute() ()
#8 0x0000000003aea761 in clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) ()
#9 0x0000000003c12905 in clang::ExecuteCompilerInvocation(clang::CompilerInstance*) ()
#10 0x0000000001cbaf0e in cc1_main(llvm::ArrayRef<char const*>, char const*, void*) ()
#11 0x0000000001cb8f65 in ExecuteCC1Tool(llvm::SmallVectorImpl<char const*>&) ()
#12 0x00000000039eb297 in void llvm::function_ref<void ()>::callback_fn<clang::driver::CC1Command::Execute(llvm::ArrayRef<llvm::Optional<llvm::StringRef> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >*, bool*) const::$_1>(long) ()
#13 0x00000000033e406a in llvm::CrashRecoveryContext::RunSafely(llvm::function_ref<void ()>) ()
#14 0x00000000039ea7f0 in clang::driver::CC1Command::Execute(llvm::ArrayRef<llvm::Optional<llvm::StringRef> >, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >*, bool*) const ()
#15 0x00000000039bfc5c in clang::driver::Compilation::ExecuteCommand(clang::driver::Command const&, clang::driver::Command const*&) const ()
#16 0x00000000039c01ac in clang::driver::Compilation::ExecuteJobs(clang::driver::JobList const&, llvm::SmallVectorImpl<std::__1::pair<int, clang::driver::Command const*> >&) const ()
#17 0x00000000039d336c in clang::driver::Driver::ExecuteCompilation(clang::driver::Compilation&, llvm::SmallVectorImpl<std::__1::pair<int, clang::driver::Command const*> >&) ()
#18 0x0000000001cb884f in main ()

Looks like the bitcode compilation path is totally busted? Anybody know
an open bug for this?

I haven't seen one, but I'm behind on email. Can you please file one
to make sure this gets tracked?

Filed <https://bugs.llvm.org/show_bug.cgi?id=44763>. I didn't have a
debug build of clang, so not a really informative backtrace yet.

I suppose the pre-supplied .bc files don't really get processed well by
recent versions of clang. I hope that others can reproduce this.

-Dimitry

Hello,

A little late but macOS built with the following test errors:

FAIL: LLVM :: Bindings/Go/go.test (25649 of 67018)
FAIL: LLVM :: tools/llvm-ar/quick-append.test (52450 of 67018)
FAIL: Profile-x86_64 :: ContinuousSyncMode/online-merging.c (56222 of 67018)
FAIL: ThreadSanitizer-x86_64 :: Darwin/norace-objcxx-run-time.mm
(57192 of 67018)
FAIL: libc++ ::
std/language.support/support.exception/except.nested/assign.pass.cpp
(60964 of 67018)
FAIL: libc++ ::
std/language.support/support.exception/except.nested/ctor_copy.pass.cpp
(60965 of 67018)
FAIL: libc++ ::
std/language.support/support.exception/except.nested/ctor_default.pass.cpp
(60966 of 67018)
FAIL: libc++ ::
std/language.support/support.exception/except.nested/rethrow_if_nested.pass.cpp
(60967 of 67018)
FAIL: libc++ ::
std/language.support/support.exception/except.nested/rethrow_nested.pass.cpp
(60968 of 67018)
FAIL: libc++ ::
std/language.support/support.exception/propagation/make_exception_ptr.pass.cpp
(60978 of 67018)
FAIL: libc++ ::
std/language.support/support.exception/propagation/rethrow_exception.pass.cpp
(60979 of 67018)
FAIL: libc++ :: std/thread/futures/futures.promise/dtor.pass.cpp
(62964 of 67018)
FAIL: libc++ ::
std/thread/futures/futures.promise/set_exception.pass.cpp (62967 of
67018)
FAIL: libc++ ::
std/thread/futures/futures.promise/set_exception_at_thread_exit.pass.cpp
(62969 of 67018)
FAIL: libc++ :: std/thread/futures/futures.async/async.pass.cpp (62991 of 67018)
FAIL: libc++ :: std/thread/futures/futures.shared_future/get.pass.cpp
(62997 of 67018)
FAIL: libc++ ::
std/thread/futures/futures.task/futures.task.members/dtor.pass.cpp
(63003 of 67018)
FAIL: libc++ ::
std/thread/futures/futures.task/futures.task.members/make_ready_at_thread_exit.pass.cpp
(63014 of 67018)
FAIL: libc++ ::
std/thread/futures/futures.task/futures.task.members/operator.pass.cpp
(63015 of 67018)
FAIL: libc++ :: std/thread/futures/futures.unique_future/get.pass.cpp
(63024 of 67018)
FAIL: libunwind :: signal_frame.pass.cpp (64734 of 67018)

That seems to be a few more in there than 9.0.1.

I have uploaded to google drive (still no sftp access):
https://drive.google.com/open?id=1wPXrtRcxxPm29C5ZcwPJLfAXiFjFmCWK
SHA256: 904b9827f4980d311f8fdf1c33ad01aa64c79d99e8f8ef0798851104f9e019b1

Thanks! I've added this to the pre-release page and to github.

I tried building rc1 for 32-bit FreeBSD, but ran into a compile error in mlir:

/home/dim/llvm/10.0.0/rc1/llvm-project/mlir/lib/Transforms/DialectConversion.cpp:787:67: error: non-constant-expression cannot be narrowed from type 'unsigned int' to 'Region::iterator::difference_type' (aka 'int') in initializer list [-Wc++11-narrowing]
    blockActions.push_back(BlockAction::getMove(&block, {&region, position}));
                                                                  ^~~~~~~~
/home/dim/llvm/10.0.0/rc1/llvm-project/mlir/lib/Transforms/DialectConversion.cpp:787:67: note: insert an explicit cast to silence this issue
    blockActions.push_back(BlockAction::getMove(&block, {&region, position}));
                                                                  ^~~~~~~~
                                                                  static_cast<difference_type>( )
1 error generated.

I submitted https://bugs.llvm.org/show_bug.cgi?id=44767 for this.

-Dimitry

Hello,

When running test-release.sh using GCC 5.4.0 we encountered this error :

/home/anil/llvm1000_rc1_binary_upload/rc1/llvm-project/clang-tools-extra/clangd/Hover.cpp: In function ‘llvm::StringLiteral clang::clangd::{anonymous}::getNameForExpr(const clang::Expr*)’:
/home/anil/llvm1000_rc1_binary_upload/rc1/llvm-project/clang-tools-extra/clangd/Hover.cpp:450:10: error: could not convert ‘(const char*)“expression”’ from ‘const char*’ to ‘llvm::StringLiteral’
return “expression”;
^

This was fixed by the commit 40514a7d

commit 40514a7d7a3b745ba43c2d014e54a0d78d65d957
Author: Michael Liao <michael.hliao@gmail.com>

[clangd] Add workaround for GCC5 host compilers. NFC.

diff --git a/clang-tools-extra/clangd/Hover.cpp b/clang-tools-extra/clangd/Hover.cpp
index cfa5e3b…ad715db 100644
— a/clang-tools-extra/clangd/Hover.cpp
+++ b/clang-tools-extra/clangd/Hover.cpp
@@ -439,7 +439,13 @@ bool isLiteral(const Expr *E) {

llvm::StringLiteral getNameForExpr(const Expr *E) {
// FIXME: Come up with names for special expressions.

  • return “expression”;
  • //
  • // It’s an known issue for GCC5, https://godbolt.org/z/Z_tbgi. Work around
  • // that by using explicit conversion constructor.
  • //
  • // TODO: Once GCC5 is fully retired and not the minimal requirement as stated
  • // in GettingStarted, please remove the explicit conversion constructor.
  • return llvm::StringLiteral(“expression”);
    }

Can this be backported to RC1 10.0.0 ?

Thanks,

Anil Mahmud

The following error was found when running test-release.sh on Red Hat 7.4

For the i386 build of this rc, I used four patches, which are attached.

Main results on i386-freebsd11:

  Expected Passes : 64948
  Expected Failures : 251
  Unsupported Tests : 3082
  Unresolved Tests : 1
  Unexpected Passes : 5
  Unexpected Failures: 232
  Individual Timeouts: 10

Uploaded:
SHA256 (clang+llvm-10.0.0-rc1-i386-unknown-freebsd11.tar.xz) = 2ae94f692d58ecc6833c76a809d2aa4fbc35d597ba7be355f2d15aef10d8b6db

Building the test-suite results in the same segfaults as on amd64, which
is tracked in 44763 – Bitcode tests crash in Function Pass Manager.

Note that the test-suite never fully built on i386 anyway, due to its
hardcoded use of SSE instructions, so this is not really a big
regression. :slight_smile:

-Dimitry

fix-clang-1.diff (447 Bytes)

fix-compiler-rt-1.diff (890 Bytes)

fix-mlir-1.diff (545 Bytes)

fix-test-suite-1.diff (552 Bytes)

Hello,

When running test-release.sh using GCC 5.4.0 we encountered this error :

/home/anil/llvm1000_rc1_binary_upload/rc1/llvm-project/clang-tools-extra/clangd/Hover.cpp: In function ‘llvm::StringLiteral clang::clangd::{anonymous}::getNameForExpr(const clang::Expr*)’:
/home/anil/llvm1000_rc1_binary_upload/rc1/llvm-project/clang-tools-extra/clangd/Hover.cpp:450:10: error: could not convert ‘(const char*)"expression"’ from ‘const char*’ to ‘llvm::StringLiteral’
   return "expression";
          ^

This was fixed by the commit 40514a7d

[..]

Can this be backported to RC1 10.0.0 ?

Yes, thanks for finding it! Cherry-picked to the 10.x branch as
cbec01fe05895abe96f2cb80e24367dec60209ee (We can't backport it to RC1
since that's already been released, but this will be part of RC2.)

Thanks,
Hans