[llvm-dev] Using C++14 code in LLVM

[Renato Golin via llvm-dev]

On 3 October 2016 at 08:43, Chandler Carruth via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> I understand that there are systems without GCC 4.9 now, but there were
> systems without GCC 4.7 when we raised the minimum requirements to that
> version.

Moving to 4.7 was a long time ago, when the usage / development
patterns were quite different. At that time, LLVM was more
experimental to most people than it is now, and products based on LLVM
were mostly done by big companies. Nowadays, Clang is in Linux and BSD
distributions, as well as part of a lot more projects (open source or
not).

I agree we should be prepared to move. I just want to make sure the
default is one that doesn't push users/developers away, or, in our
case, break most of our buildbots.


> For me, the question is more how easily users on those systems
> could update. If it is reasonably straight forward, I would be fine moving
> the baseline up. If there are reasons why installing a newer GCC would be
> very hard, that would be more concerning to me.

Yup.

Also, for the vast majority of systems, Clang *cannot* be used alone.
So claiming that Clang is such and such version, "therefore we don't
care about GCC" is a fallacy we shouldn't get ourselves into.

So we're talking here about successfully compiling all LLVM
sub-projects with a "simple enough" toolchain for the targets that we
normally do. This involves native *and* cross compilation on all major
targets, with cross *at least* from x86_64.

The Clang driver support for cross compiling is a mess, compiler-rt
can't yet cross-compile properly and I'm not sure libc++ et al has
even been tested properly in that area. The problem starts when
different OSs have different sysroot and multilib/multiarch styles,
which renders binary tarballs (like Linaro releases) practically
useless out of their tested environments as a sysroot for Clang.

Not to mention that in pre-built binary land, 5.x is already the old
version, with 6.x being current stable and 7.x merge window closing a
few weeks from now. Trunk, releases and distros are usually more than
a year apart from each other.


> I do think moving past GCC 4.9 presents a unique challenge due to the ABI
> break which took place between GCC 4.9 and GCC 5. For example, for me, "just
> installing" a newer version of GCC works great right up until GCC 5 where it
> starts to break for ABI reasons.

We are moving all our buildbots to Ubuntu Xenial 16.04 LTS, which
means GCC 5.4.0, binutils 2.26 and glibc 2.23. They also use 48-bit
VMA which will likely be the new standard for AArch64 kernels from now
on.

But we need to fix a lot of bugs before moving, and any change window
right now will put us in a tight spot. For example, one of the bugs we
found had to be fixed in binutils, which just got merged to master
last week. That means we can't rely on Ubuntu's toolchain anymore, and
will likely force us to use Linaro's toolchain from now on, which is
yet another big move (and more Clang driver changes, which won't go
into Clang 3.9).

So, while I welcome change, and we're working towards it, we may need
more time to move above 4.8. If people are happy to move to 4.8 now,
then 5.x later, I'm game. If people want to wait and move to 5.x when
everyone is ready, I'm also game. But moving to 4.9 now will break *a
lot* of stuff for us, and likely not give us much time to fix them
properly.

cheers,
--renato