
LLVM 5.0.0 Release - zmodem
http://lists.llvm.org/pipermail/llvm-announce/2017-September/000075.html
======
rui314
> ./configure scripts generated by GNU autoconf determines whether a linker
> supports modern GNU-compatible features or not by searching for "GNU" in the
> --help message. To be compatible with the scripts, we decided to add a
> string "(compatible with GNU linkers)" to our --help message. This is a
> hack, but just like the web browser's User-Agent string (which everyone
> still claim they are "Mozilla/5.0"), we had no choice other than doing this
> to claim that we accept GNU-compatible options.

[http://releases.llvm.org/5.0.0/tools/lld/docs/ReleaseNotes.h...](http://releases.llvm.org/5.0.0/tools/lld/docs/ReleaseNotes.html)

Even though I wrote it, I found this part a bit funny. Configure scripts are
hacky by their nature, and we needed another hack to make their hack work. I'm
not happy about that though.

~~~
chubot
Yup, this is why feature detection is better than version detection.

jQuery changed their strategy in 2009:
[http://blog.jquery.com/2009/01/14/jquery-1-3-released/](http://blog.jquery.com/2009/01/14/jquery-1-3-released/)

"No More Browser Sniffing"

Also, autoconf has a lot of faults, but as far as I recall it's firmly based
on the philosophy of feature detectino vs. version detection.

Maintainers of packages can write bad custom checks that test for features,
but if you use the built-in autoconf checks, they're all about features.

CMake on the other hand seems to use version detection more, which I don't
like.

~~~
wvenable
It helps when you have a platform that supports feature detection reliably.
Most platforms don't have that lucky accident.

~~~
chubot
What's an example where of a feature of cc or ld that you can't detect with
feature detection?

Shell scripts are turing complete and can do arbitrary I/O. In theory you can
write a feature detection for any feature by compiling, linking, and running a
test program. If the feature couldn't be detected this way, then it would be
useless.

Likewise, JavaScript and DOM features should always be detectable by eval(). I
guess one instance where it's impossible is if the API changes the pixels on
the screen and does nothing else.

Although you can actually detect this in some cases with JavaScript!
JavaScript can leak information through the colors of attributes on the
screen, e.g. you can tell if a user visited a site by looking if the link is
purple!

~~~
0x0
No modern browser lets you know the state of a:visited and will lie to you if
you query for colors etc. In fact if you can find a way for js to determine if
a link has been visited you are likely qualified for $$$ bug rewards (which
has happened)

~~~
anon1385
>No modern browser lets you know the state of a:visited

There are loads of ways to extract that information, and the number increases
all the time as browsers get more complex. It's not something browser vendors
actually consider to be a bug. They have historically only 'fixed' the trivial
methods of getting the visited status because it became an issue that was
widely publicised. If they cared at all they would never have implemented
features like Shared Array Buffers.

This stuff is all sitting in years old open bug reports. Nobody cares.

[https://bugzilla.mozilla.org/show_bug.cgi?id=884270](https://bugzilla.mozilla.org/show_bug.cgi?id=884270)
Link Visitedness can be detected by redraw timing

[https://bugs.chromium.org/p/chromium/issues/detail?id=508166](https://bugs.chromium.org/p/chromium/issues/detail?id=508166)
Security: Chrome provides high-res timers which allow cache side channel
attacks

Further reading on some of the exciting new timing attacks added to web
standards in recent years:

[https://arxiv.org/pdf/1502.07373v2.pdf](https://arxiv.org/pdf/1502.07373v2.pdf)
The Spy in the Sandbox – Practical Cache Attacks in Javascript

[https://www.contextis.com/resources/white-papers/pixel-
perfe...](https://www.contextis.com/resources/white-papers/pixel-perfect-
timing-attacks-with-html5) Pixel Perfect Timing Attacks with HTML5 (now fixed
because you could use it to steal the contents of any page)

[http://www.cs.vu.nl/~herbertb/download/papers/anc_ndss17.pdf](http://www.cs.vu.nl/~herbertb/download/papers/anc_ndss17.pdf)
ASLR on the Line: Practical Cache Attacks on the MMU

------
mirekrusin
This is the first time I can see Zig lang [1]. (Self-proclaimed?) C successor
with manual memory management, ironed out edge cases, new take on error
handling (that resembles well written error handling in C), generics, compile
time reflection/execution (macros?), import .h works directly, exporting to C
works directly, nullable types etc... all sound quite interesting actually.
Anybody has experience/comments on the Zig lang, please?

[1] [http://ziglang.org/](http://ziglang.org/)

~~~
kbenson
_Zig competes with C instead of depending on it. The Zig Standard Library does
not depend on libc._

That's an interesting choice. I'm sure there are other semi-recent languages
that have made the same choice, it would be interesting to hear the benefits
and problems of that approach.

I say semi-recent, because there are of course many from before C or that
competed with C and Unix initially, but unless they are still used much
(Lisp?) it's not necessarily the best for a comparison of modern issues.

~~~
anonymousDan
Go

~~~
kbenson
Are you sure? I'm seeing reports that go sometimes wouldn't run with musl
instead of GNU libc, with a runtime segfault[1]. That seems to depend on libc.
Are you saying that Go's standard library primitives are not shims (or more
complex structures) built on top of libc?

1:
[https://github.com/golang/go/issues/14476](https://github.com/golang/go/issues/14476)

~~~
Matthias247
Go uses libc optionally (for some things like DNS resolving). You can build Go
programs which do not utilize libc by disabling cgo and building static
binaries. By default the biggest part of Gos stdlib isn't based on libc, but
some small parts are.

------
KenoFischer
One feature I'm excited about in this release is proper support for non-
integral address spaces. Allows us to do significantly more optimization in
the presence of GC roots in Julia.

------
hawski
Does anyone know the state of the project to compile Linux Kernel with clang?
Does this release help with such a goal?

~~~
rmusial
From an August 23 email (
[https://lists.linuxfoundation.org/pipermail/llvmlinux/2017-A...](https://lists.linuxfoundation.org/pipermail/llvmlinux/2017-August/001517.html)
)

 _Over the past months efforts have been made to upstream the remaining
LLVMLinux patches
([http://llvm.linuxfoundation.org](http://llvm.linuxfoundation.org)) and to
address other outstanding issues in order to build a usable kernel with clang.
To my knowledge upstream is in a relatively good shape by now for x86 and
arm64 (I heard the same about PowerPC, but have no first hand experience),
most of the patches are already in Linus' tree, others have landed in
maintainer trees._

...

It goes on, but there has been some pretty significant work done, and you can
easily compile with clang as your default cc with simple patches.

------
mhh__
Those LLD benchmarks are looking very impressive! Well done to all involved.

~~~
kibwen
Where are you seeing the LLD benchmarks? I'm very curious about the prospect
of LLD performance improvements for the benefit of the Rust compiler, and
having benchmarks would be lovely.

~~~
wyldfire
Maybe these [1] ones comparing ld, gold, lld?

[1] [https://lld.llvm.org/#performance](https://lld.llvm.org/#performance)

------
pc2g4d
Better AVR support for Rust? Can anyone comment on this?

~~~
mhh__
Well, the AVR backend is being actively developed, I have no idea how good it
is. (Although some tooling for embedded systems is rather poor, so one would
imagine that LLVM with the right heuristics couldn't do badly).

rustc is apparently ([https://github.com/rust-
embedded/rfcs/issues/3](https://github.com/rust-embedded/rfcs/issues/3)) not
far of it being usable.

However, I don't regularly write code for uC-ers - and when I do, it's usually
simple enough to be in assembly - so I can't really say anymore than that.

~~~
dyl
AVR-Rust author here

The backend itself is working very well - there are only a handful of known
bugs at this point, and many projects can be compiled with no issues.

The issue you linked also links to ([https://github.com/rust-
lang/rust/issues/44052](https://github.com/rust-lang/rust/issues/44052)),
which shows that once these bugs are fixed, we can start working on merging
avr-rust upstream.

A number of projects/libraries have also been developed recently

* [https://github.com/avr-rust/blink](https://github.com/avr-rust/blink) * [https://github.com/avr-rust/avrd](https://github.com/avr-rust/avrd) * [https://github.com/avr-rust/arduino](https://github.com/avr-rust/arduino) * [https://github.com/gergoerdi/rust-avr-chip8-avr](https://github.com/gergoerdi/rust-avr-chip8-avr)

------
gcp
_Added support for AMD Lightweight Profiling (LWP) instructions._

Funnily enough, AMD already deprecated those. They're not in Zen.

------
gnuvince
What's a good reference to get started with LLVM? I've been wanting to write
an Oberon-2 compiler, but I don't know what LLVM provides, nor how I might use
it from Rust.

~~~
SolarNet
It provides IR, low level optimization passes, native code generation, and
common metadata features (e.g. for debugging). Rust probably has a library
somewhere that binds to it.

So you would have to write linking (with help from LLVM), ASTs, high-level
optimizations and validation, garbage collection (with help from LLVM), and
standard library (or link an existing one). Also intermediate IRs or ASTs you
plan on using (for example Rust's MIR) and their infrastructure.

------
kccqzy
> Added heuristics to convert CMOV into branches when it may be profitable

Does anyone know why this is the case? I thought CMOVs are a straight win over
branches but I guess modern CPUs might be more complicated than that.

~~~
matt_d
"LLVM compiler recognizes opportunities to transform a branch into IR select
instruction(s) - later it will be lowered into X86::CMOV instruction, assuming
no other optimization eliminated the SelectInst. However, it is not always
profitable to emit X86::CMOV instruction. For example, branch is preferable
over an X86::CMOV instruction when:

\- Branch is well predicted

\- Condition operand is expensive, compared to True-value and the False-value
operands"

[https://reviews.llvm.org/D34769](https://reviews.llvm.org/D34769)

"We have seen periodically performance problems with cmov where one operand
comes from memory. On modern x86 processors with strong branch predictors and
speculative execution, this tends to be much better done with a branch than
cmov. We routinely see cmov stalling while the load is completed rather than
continuing, and if there are subsequent branches, they cannot be speculated in
turn."

[https://reviews.llvm.org/D36858](https://reviews.llvm.org/D36858)

------
0x0
Just in time for Xcode 9? :)

~~~
santaclaus
Now if only Apple would quit mysteriously stripping out features from the full
LLVM release...

~~~
Karliss
It seems more likely that they simply don't use upstream release tags and put
their changes and maybe backport some changes on top of randomly chosen
revision. The same way as Google released Android ndk r15 few months ago with
clang "5.0".

The sad part is that their version is neither older or newer than official
release as it doesn't contain everything from upstream release and upstream
doesn't contain all of their changes yet.

~~~
0x0
It can't possibly be pure coincidence that a major llvm release is timed about
one week off from the annual major apple macOS/iOS/toolchain + iPhone hardware
release, with their history of employing big llvm contributors?

~~~
theresistor
It is. The tool chain going into those releases is locked down months in
advance.

