[5.0.0 Release] Release Candidate 3 tagged

Dear testers,

5.0.0-rc3 was just tagged.

This is a release candidate in the real sense: if nothing bad comes up
in testing, this is what the release is going to look like.

Please build, test and upload binaries to the sftp (use the
/data/testers-uploads/ directory) and let me know what issues remain.

I know we're a little bit behind schedule, but hopefully we can get to
'final' soon.

Cheers,
Hans

Working well here so far.
Is the removal of the RISCVCodeGen, RISCVDesc and RISCVInfo libraries
that were in rc2 intentional?

ttyl
bero

Yes, the removal of RISC-V from LLVM_ALL_TARGETS was intentional.
See https://reviews.llvm.org/D36538 and the accompanying message to
llvm-dev: http://lists.llvm.org/pipermail/llvm-dev/2017-August/116347.html
for the rationale.

Thanks,
Simon

trusty on apt.llvm.org is behind the others by 9 days and is missing the latest rc3 release. Can we get an update on this?

Regards,
Andrew

Hi,

one issue I have with rc3 is that tools using it don't compile with C++17 as public LLVM
headers seem to use a removed feature, std::pointer_to_unary_function.

[ 12%] Building CXX object tsl/CMakeFiles/tsl.dir/src/generated/combined.cpp.o
In file included from /local/cullmann/build/eco.default/eco/tsl/src/generated/combined.cpp:3:
In file included from /local/cullmann/build/eco.default/eco/tsl/src/graph.cpp:29:
In file included from /local/cullmann/build/eco.default/eco/tsl/include/tsl/graph.h:32:
In file included from /local/cullmann/build/eco.default/eco/tsl/include/tsl/llvm.h:52:
In file included from /local/cullmann/build/eco.default/usr/include/llvm/Analysis/BasicAliasAnalysis.h:18:
In file included from /local/cullmann/build/eco.default/usr/include/llvm/Analysis/AliasAnalysis.h:41:
In file included from /local/cullmann/build/eco.default/usr/include/llvm/Analysis/MemoryLocation.h:20:
In file included from /local/cullmann/build/eco.default/usr/include/llvm/IR/CallSite.h:37:
/local/cullmann/build/eco.default/usr/include/llvm/IR/Instructions.h:4198:26: error: no template named 'pointer_to_unary_function' in namespace 'std'
  using DerefFnTy = std::pointer_to_unary_function<Value *, BasicBlock *>;
                    ~~~~~^
/local/cullmann/build/eco.default/usr/include/llvm/IR/Instructions.h:4199:57: error: use of undeclared identifier 'DerefFnTy'
  using handler_iterator = mapped_iterator<op_iterator, DerefFnTy>;
                                                        ^
/local/cullmann/build/eco.default/usr/include/llvm/IR/Instructions.h:4200:40: error: use of undeclared identifier 'handler_iterator'
  using handler_range = iterator_range<handler_iterator>;
                                       ^
/local/cullmann/build/eco.default/usr/include/llvm/IR/Instructions.h:4202:12: error: no template named 'pointer_to_unary_function' in namespace 'std'
      std::pointer_to_unary_function<const Value *, const BasicBlock *>;
      ~~~~~^
/local/cullmann/build/eco.default/usr/include/llvm/IR/Instructions.h:4204:42: error: use of undeclared identifier 'ConstDerefFnTy'
      mapped_iterator<const_op_iterator, ConstDerefFnTy>;
                                         ^
/local/cullmann/build/eco.default/usr/include/llvm/IR/Instructions.h:4205:46: error: unknown type name 'const_handler_iterator'; did you mean 'const_user_iterator'?
  using const_handler_range = iterator_range<const_handler_iterator>;
                                             ^~~~~~~~~~~~~~~~~~~~~~
                                             const_user_iterator
/local/cullmann/build/eco.default/usr/include/llvm/IR/Value.h:365:9: note: 'const_user_iterator' declared here
  using const_user_iterator = user_iterator_impl<const User>;

Greetings
Christoph

Hello

I am not sure to understand how this relates to the 5.0.0 work?

For now, it is broken because of a gcc bug:

I am planning to upgrade the gcc version to 4.9 to workaround this issue. Probably this week.

Sylvestre

Hi,

Uploaded ARM & AArch64:
ee9e89f1d5f8a5fb84cef6c82ded694c5c427e16
clang+llvm-5.0.0-rc3-aarch64-linux-gnu.tar.xz
a8b38e91288b07b2899c397373c018c6c5f6f207
clang+llvm-5.0.0-rc3-armv7a-linux-gnueabihf.tar.xz

The libunwind tests are still failing. I have reopened the bug:
https://bugs.llvm.org/show_bug.cgi?id=33858

Cheers,
Diana

Hi Hans,

Darwin looks good and is ready:

SHA 1: 0ecf576b2ba5dd091a78b906c93af1a76449b1f2 rc3/clang+llvm-5.0.0-rc3-x86_64-apple-darwin.tar.xz
SHA 256: 6c949f35817a424784b9ab4cb16588d394054ce0704a9902adb64b373008aa8c rc3/clang+llvm-5.0.0-rc3-x86_64-apple-darwin.tar.xz

thanks,
vedant

Windows is ready:
$ sha1sum *5.0.0-rc3*
1d4f3cf9e1463803cd5bbb95a029b5544c0989be LLVM-5.0.0-rc3-win32.exe
72f1c558d01e8fde1da2c50b5cbb90e1bbc6375a LLVM-5.0.0-rc3-win64.exe

Built and tested, no changes with respect to the previous rc. I've uploaded:

SHA256 (clang+llvm-5.0.0-rc3-amd64-unknown-freebsd10.tar.xz) = 510d8689239a1b83a154e8ee0230765d0f9054ca534c3a9ed4a2d4e31d8f9704
SHA256 (clang+llvm-5.0.0-rc3-i386-unknown-freebsd10.tar.xz) = 65b21c280575dcf16449c4c051b14f9950ff5f5d0a43b59852a0e1c65a1f145c

-Dimitry

I see there's a patch in progress to fix this: https://reviews.llvm.org/D36049

Since the issue was raised so late in the process, I don't think it
will get fixed for 5.0.0 however. Maybe for 5.0.1.

Thanks,
Hans

Hi,

I've uploaded the binaries for rc3:

SHA256(clang+llvm-5.0.0-rc3-mipsel-linux-gnu.tar.xz)= f682de9375970c3e43b11da94cfbcb38163a79a5a09806ef0198837eefbfc621
SHA256(clang+llvm-5.0.0-rc3-mips-linux-gnu.tar.xz)= 909095eac1ed5a21a5ba7ea5099d56f29576398b8dd7497453c63b2bcafe7874
SHA256(clang+llvm-5.0.0-rc3-x86_64-linux-gnu-debian8.tar.xz)= bb75e1c73b5dec292b7a2092c7876413cc8941eb085e84b53cb31b32d0812b94

During testing, I encountered a new failure when compiling for MIPS32r1, an apparent hang when
compiling: test-suite.src/MultiSource/Applications/JM/lencod/rdopt.c

This issue did not occur for rc2 and I suspect it's related to PR34326 as gdb is giving me stack traces
with DACombine and visitSTORE. Running the test-suite through emulation shows a clean result.

Otherwise, looks ok here.

Thanks,
Simon

Hi,

I've uploaded the binaries for rc3:

SHA256(clang+llvm-5.0.0-rc3-mipsel-linux-gnu.tar.xz)= f682de9375970c3e43b11da94cfbcb38163a79a5a09806ef0198837eefbfc621
SHA256(clang+llvm-5.0.0-rc3-mips-linux-gnu.tar.xz)= 909095eac1ed5a21a5ba7ea5099d56f29576398b8dd7497453c63b2bcafe7874
SHA256(clang+llvm-5.0.0-rc3-x86_64-linux-gnu-debian8.tar.xz)= bb75e1c73b5dec292b7a2092c7876413cc8941eb085e84b53cb31b32d0812b94

Thanks! I've added them to the prerelease page.

During testing, I encountered a new failure when compiling for MIPS32r1, an apparent hang when
compiling: test-suite.src/MultiSource/Applications/JM/lencod/rdopt.c

This issue did not occur for rc2 and I suspect it's related to PR34326 as gdb is giving me stack traces
with DACombine and visitSTORE. Running the test-suite through emulation shows a clean result.

Hmm, if it's related to PR34326, I'd expect it to have shown for rc2
as well. But since you say it doesn't show in emulation, maybe it's
not completely deterministic.