LLVM 9.0.0 Release

It's my great pleasure to announce that LLVM 9 is now available.

Get it here: https://llvm.org/releases/download.html#9.0.0

This release is the result of the LLVM community's work over the past
six months (up to trunk r366426 plus commits on the branch). Some
highlights include:

- Support for asm goto, enabling for example the mainline Linux kernel
  for x86_64 to build with Clang
- The RISCV-V target is no longer experimental, but built by default
- Experimental support for C++ for OpenCL

as well as many bug fixes, optimizations, and diagnostics improvements.

For more details, see the release notes:
https://llvm.org/releases/9.0.0/docs/ReleaseNotes.html
https://llvm.org/releases/9.0.0/tools/clang/docs/ReleaseNotes.html
https://llvm.org/releases/9.0.0/tools/clang/tools/extra/docs/ReleaseNotes.html
https://llvm.org/releases/9.0.0/tools/lld/docs/ReleaseNotes.html
https://llvm.org/releases/9.0.0/projects/libcxx/docs/ReleaseNotes.html

Special thanks to the release testers and packagers: Amy Kwan, Andrew
Kelley, Bernhard Rosenkraenzer, Brian Cain, Diana Picus, Dimitry
Andric, Jonas Hahnfeld, Khem Raj, Michał Górny, Neil Nelson, Nick
Desaulniers, Sylvestre Ledru, and Victor Huang. Without your work,
this would not be possible.

For questions or comments about the release, please contact the
community on the mailing lists. Onwards to LLVM 10!

Thanks,
Hans

Will it be possible to canonicalize the download links on this
page? Some of them use the 'releases.llvm.org' while others are
on GitHub. There does not appear to be any pattern to it.

ZV

I believe Tom used GitHub for some of the recent x.0.1 releases.
Eventually they will probably all end up there.

It's my great pleasure to announce that LLVM 9 is now
available.

Get it here: https://llvm.org/releases/download.html#9.0.0

Will it be possible to canonicalize the download links on this
page? Some of them use the 'releases.llvm.org' while others are
on GitHub. There does not appear to be any pattern to it.

We did 7.1.0. and 8.0.1 releases on GitHub as a test, since this is
where we'll be hosting the binaries once SVN is retired.

Why do you need canonical download links?

-Tom

In short, to avoid breaking or requiring additional logic in
scripts that may download or use the official release tarballs.

The SVN --> GitHub migration [0] document is an excellent start,
though I'd like to suggest the (continued?) release of signed,
non-GitHub-generated, official tarballs.

Will sub-project tarballs be released in the future, and/or has
a decision on GitHub-hosted sub-project mirrors been made [1]?
The key is tarball availability. Not everyone has large disks :slight_smile:

Right now links like these work OK ('llvmorg-V' is the tag, or a
commit hash could be used in lieu of the tag):

https://github.com/llvm/llvm-project/archive/llvmorg-V.tar.gz

redirects to...

https://codeload.github.com/llvm/llvm-project/tar.gz/llvmorg-V

and

https://api.github.com/repos/llvm/llvm-project/tarball/llvmorg-V

redirects to...

https://codeload.github.com/llvm/llvm-project/legacy.tar.gz/llvm
org-V

except that in these cases, sub-projects are not available
separately as on the Downloads page for the historical releases.

That's approximately version 3.2 forward, requiring ~250-900MB
(or more) of disk space per version.

Other nits that could be picked (examples not exhaustive):

  * Renaming of 'clang-V' to 'clang-V.src' in 3.0 --> 3.1;

  * Renaming of 'clang-V.src' to 'cfe-V.src' in 3.1 --> 3.2;

  * Inconsistent availability of sub-project documentation;

  * Availability of both .tar.gz and .tar.xz (or other) formats,
    which changed between 3.4.2 and 3.5.0;

  * Tarball sizes are no longer listed after 3.3 --> 3.4;

  * Inconsistent availability of tarball signatures; and

  * Inconsistent availability of PGP key listings for above.

By the way, the GitHub links above don't have a Content-Length
header or checksum of any sort. I'd like to see this as well.

Also, between the two 'codeload.github.com' links above, the one
with 'legacy.tar.gz' includes 8 characters of the corresponding
commit hash in the filename, while the non-legacy one does not.

Some of these will necessarily be moot once the migration is
done, but I believe more consistency and some of this security
(ability to validate tarballs) will be welcomed by others.

ZV

[0]: https://llvm.org/docs/Proposals/GitHubMove.html

[1]: ...#read-only-sub-project-mirrors