
LLVM 8.0.0 Release - samber
https://lists.llvm.org/pipermail/llvm-announce/2019-March/000082.html
======
zegl
I've been wanting to test out the LLVM IR to WebAssembly compilation, but I've
been too lazy (or impatient) to compile LLVM from source. Nice to see that
it's now enabled by default!

~~~
Scuds
Does this mean wasm is effectively just another ISA to compile to and
emscripten is no longer needed?

~~~
Orphis
If you need really small functions, yes. emscripten is providing all the libc
functions, WASM loading code and binding generators. You will probably need
some of that when porting existing libraries or applications to the web!

~~~
e12e
Well, you generally need a libc when compiling for any platform, so that
shouldn't be too special?

~~~
steveklabnik
You don't inherently need a libc for wasm. That is, libc is usually the API
for the platform; wasm doesn't have such a thing really. Your wasm module says
"hey, these are the functions I expose, and these are the functions that I am
planning to call from the environment" and it's the host's job to wire that up
properly. In the browser, that means when you instantiate a wasm module, you
need to provide all the required functions, and then you can call the exposed
functions from JS. Outside the browser, what things you can call and will be
called is defined by the host.

A libc can be useful _inside_ of wasm for existing C or C++ code (or whatever)
that is built for another platform, so that you can more easily compile to
wasm as well. But it's an option, not required.

~~~
e12e
Well, I meant that if you want to cross compile general code, you might want
malloc, printf etc...

I'm not sure the _primary_ appeal of wasm is treating it as a low level target
(even if that is possible and sometimes useful).

~~~
steveklabnik
You can get that stuff without a libc, if you’re not literally compiling C or
C++. If you are, you’re right, though.

------
xvilka
While they did an amazing job on improving the framework, compiler, and tools,
a few important compatibility features weren't addressed:

\- '-MT' and '-MM' options support (like in GCC)[1]

\- '-M'/'-MF' options support (like in GCC)[2]

\- 'MENUEX' menu resource section parsing (like in MSVC)[3]

Also, we recently found a problem[4] while compiling radare2 with 8.0.0 clang-
cl for Windows. Hopefully, it will be addressed soon since the tool offers
sanitizers support for the Windows platform, which is a blast.

[1]
[https://bugs.llvm.org/show_bug.cgi?id=10091](https://bugs.llvm.org/show_bug.cgi?id=10091)

[2]
[https://bugs.llvm.org/show_bug.cgi?id=8312](https://bugs.llvm.org/show_bug.cgi?id=8312)

[3]
[https://bugs.llvm.org/show_bug.cgi?id=40108](https://bugs.llvm.org/show_bug.cgi?id=40108)

[4]
[https://bugs.llvm.org/show_bug.cgi?id=41128](https://bugs.llvm.org/show_bug.cgi?id=41128)

------
benchaney
Does anyone know what the status of the llvm riscv backend is? I haven’t heard
about it in a while.

~~~
steveklabnik
rustc has support in-tree for

    
    
      riscv32imac-unknown-none-elf
      riscv32imc-unknown-none-elf
      riscv64gc-unknown-none-elf
      riscv64imac-unknown-none-elf
    

So, it's at least far enough along to have that turned on!

~~~
bionicbits
Nice, was just looking into this!

~~~
steveklabnik
You have to

    
    
      $ rustup target add <triple>
    

to download the pre-compiled libraries, but then it should be a --target
<triple> away! As far as I know anyway, I'm sure there are bugs since it's so
new.

------
wyldfire
> -mspeculative-load-hardening Clang now has an option to enable Speculative
> Load Hardening.

I wonder -- which targets support this flag? And which ones need it (i.e.
which are susceptible)?

Also, I didn't see it in the changelog -- does libc++ have std::execution::*
yet?

------
newnewpdro
I was able to get AMDGPU & Mesa-OpenCL working reliably on an AMD RX480 with
this release.

On 6 and 7 some OpenCL kernels would consistently fail with illegal
instruction problems.

If you've been using AMDGPU PRO just for OpenCL support, and prefer running
mainline drivers, give AMDGPU a try on llvm8 and a recent kernel.

------
openbasic
Wish they updated the Kaleidoscope tutorial.

------
xvilka
I should also note that KLEE 2.0 was released[1] in line with LLVM 8.0
release. It is the first release in the last 2 years, so the amount of changes
is huge. If you are using symbolic execution - I recommend you to check out
this version.

[1]
[https://github.com/klee/klee/releases/tag/v2.0](https://github.com/klee/klee/releases/tag/v2.0)

------
0x0
Are LLVM releases always timed to align with Xcode releases these days? I
guess most people expect new Xcode and iOS/Mac SDKs on Monday.

~~~
coldtea
> _I guess most people expect new Xcode and iOS /Mac SDKs on Monday._

Most people don't expect them then, and they'd be wrong if they do.

Apple just has one of the regular spring-time announcements for hardware and
services products.

WWDC, when the new Xcode and iOS/Mac SDKs will be announced (but usually not
released to non-devs until Fall), is, and has always been, in the summer
(June).

(And there's another hardware/services announcement in Fall usually).

~~~
0x0
It's expected that iOS 12.2 is coming with Swift5, and ABI stability for the
first time, as well as os-bundled libswift for the first time. Sounds like a
semi major sdk update to me.

~~~
coldtea
Hmm, the minor update with new Swing is indeed a good point.

Not the usual way it happens though. Usually those things came at WWDC.

------
zmodem
[https://news.ycombinator.com/item?id=19441297](https://news.ycombinator.com/item?id=19441297)
links to the release announcement for the whole project, not just the LLVM
module.

~~~
aboutruby
The other post has no comments yet and the link is:
[https://lists.llvm.org/pipermail/llvm-
announce/2019-March/00...](https://lists.llvm.org/pipermail/llvm-
announce/2019-March/000082.html)

~~~
sctb
OK, we'll update this link from
[http://releases.llvm.org/8.0.0/docs/ReleaseNotes.html](http://releases.llvm.org/8.0.0/docs/ReleaseNotes.html).

------
aquabeagle
edit: nevermind

~~~
aepiepaey
No, it does not.

According to you reference link:

> We currently plan to install the new developer policy and add the new
> license in January 2019 after the LLVM 8.0 release has branched.

Also, the source archive for LLVM 8 still contains the old license.

Which means that the first release under the Apache 2 license should be LLVM
9.

