Using C++14 code in LLVM

A thread was started over the summer to discuss the timeline for bumping LLVM up to Visual Studio 2015 to enable the use of various new language features. Currently the ETA for this is sometime in mid-October, so within 2-3 weeks.

With this happening imminently, I thought it would be worth tossing this out there and seeing what people think.

With VS on 2015, the major lagging compiler is going to be GCC. Our minimum GCC requirement is 4.7, which is quite old (almost 4 years for anyone keeping count). What are the challenges with pushing this forward?

With VS2015, the biggest remaining missing C++14 features are variable templates, sized allocation, and extended constexpr. But it gains generic lambdas, init-captures, decltype(auto) return, and auto return without requiring the trailing → decltype syntax.

While GCC doesn’t claim to “fully” support C++14 until 5.2 (which is only about 1 year old), you can get all of the above features with GCC 4.9

So if we’re willing to allow “partial” C++14 support in LLVM (i.e a whitelisted set of features), we may be able to get many of the most useful features by going to GCC 4.9, which is still a good 2.5 years old.

One potentially added benefit of this is that GCC supports in 4.9. This might allow us to kill of llvm::Regex in favor of standardizing on std::regex, as GCC is currently the only supported compiler without a regex implementation.

Thoughts?

While GCC doesn't claim to "fully" support C++14 until 5.2 (which is only
about 1 year old), you can get all of the above features with GCC 4.9

I do care quite a bit about GCC 4.8 support, since that's what is
shipped with NetBSD 7.

One potentially added benefit of this is that GCC supports <regex> in 4.9.
This might allow us to kill of llvm::Regex in favor of standardizing on
std::regex, as GCC is currently the only supported compiler without a regex
implementation.

If that is the only argument, we should be able to reuse the libc++
implementation without too much trouble?

Joerg

SGTM

We’re in the process of modernising our Buildbots, but we still use gcc 4.8.2 in many of them.

If we do consider going forward, we’re going to need a lot of coordination and patience, as we are finding issues with newer gcc and glibc on ARM.

Cheers,
Renato

That wasn’t even the main argument :slight_smile: The main argument was the ability to use C++14 in the upstream. I suspect that we won’t want to be tied to C++11 indefinitely though. LLVM already has a section called “Getting a modern host C++ toolchain” for distros with older GCC’s. In theory this could just be bumped from “older than GCC 4.7” to “older than GCC 4.9”. I admit I don’t know much (i.e. anything) about NetBSD. But a quick look at the release history says that even NetBSD 8 (which isn’t even stable yet), is still only going to have GCC 4.8. So if we’re going to be held back by this, we’re looking at 2-4 years before we can use C++14 upstream. Just food for thought.

That said, will the libc++ implementation work with MSVC? I don’t know, but I seriously doubt it.

Jörg, other than just time and energy - what's the (big?) technical
challenge or bug list which prevents NetBSD from doing something
radical like going to a really modern version of gcc? (I realize
NetBSD tends to be very conservative, which isn't a bad thing) I've
never had access to NetBSD 1st hand, but is very modern gcc available
in "ports"?

I haven't been following C++14 closely, but from hallway conversations at work it seems like 17 is the bigger win in terms of features.

Is it worth waiting for 17 instead? Or, as we will only get a subset of 14 features anyway, just instead take a subset of 17 features?

My only worry with 14 is that it's always going to be code churn in terms of using the new features. If they are worth it then no problem, but we should make sure they are. I'd prefer we have the update bots and code churn once instead of twice in the near future.

Finally, I think we have clang 3.1 as the min version. Anyone know what that minimum will move to for the 14 support needed? I don't think it's as much of an issue as most distros are gcc based, but still good to know.

Cheers
Pete

What clang version has all this features?

The big challenge is that every GCC updates shows lots of random
breakage on non-x86 and often enough, on x86 just as well. Breakage in
the buggy-codegen area, not in "random new broken warnings". So while
there is a slow per-platform migration toward GCC 5.4, it tends to be
difficult.

Side note, GCC 4.8 is still the default compiler in many SuSE
environments as well.

Joerg

3.4

Also, our minimum Clang is 3.1, which is a bit over four years old.
For FreeBSD I think increasing this to 3.4 would not cause any trouble
(FreeBSD 10.x has Clang 3.4.1), but requiring Clang newer than that
would be awkward.

I haven't been following C++14 closely, but from hallway conversations at
work it seems like 17 is the bigger win in terms of features.

Is it worth waiting for 17 instead? Or, as we will only get a subset of 14
features anyway, just instead take a subset of 17 features?

My only worry with 14 is that it's always going to be code churn in terms
of using the new features. If they are worth it then no problem, but we
should make sure they are. I'd prefer we have the update bots and code
churn once instead of twice in the near future.

Finally, I think we have clang 3.1 as the min version. Anyone know what
that minimum will move to for the 14 support needed? I don't think it's as
much of an issue as most distros are gcc based, but still good to know.

Cheers
Pete

Sent from my iPhone

I am compiling a large number of packages with their make files .

One important problem is the missing features from compilers .

For example : A program is using C++14 which is compilable with GCC . When
it is tried to be compiled with CLang , it is failing because CLang does
not have C++14 features .

This means , if C++14 is skipped from the CLang compiler , a lot of
packages will not be compilable with CLang .

Then a more easy way to compile a large number of packages , a more
convenient compiler will be GCC and Clang will be eliminated naturally .

My opinion is that during decision of what to include or exclude may make
it necessary to consider coverability of possible compilable ports/packages
and what users can do for them .

Thank you very much .

Mehmet Erol Sanliturk

Given that clang and libc++ have supported C++14 quite early and faster
than GCC, I find that a strange statement without qualification. Note
that clang is often used with gcc as runtime and that can break various
things.

Joerg

My CLang version was older because of operating system Linux version .
If a new version of CLang is installed , it was breaking some packages of
operating system .
If an old version of CLang ( supplied by the operating system as default )
is used , it was not able to compile "New" packages .

For that reason , my statement has become incomplete , but , my intention
is that covering standards in succession in sufficient detail may be useful
for inclusion more compilable packages and wide spread usability of the
compiler whatever it is .

Mehmet Erol Sanliturk

I haven't been following C++14 closely, but from hallway conversations at work it seems like 17 is the bigger win in terms of features.

Is it worth waiting for 17 instead? Or, as we will only get a subset of 14 features anyway, just instead take a subset of 17 features?

I believe C++14 has enough C++11 bug fixes to be worth moving to.

Finally, I think we have clang 3.1 as the min version. Anyone know what that minimum will move to for the 14 support needed? I don't think it's as much of an issue as most distros are gcc based, but still good to know.

We'd have to bump it, but as Zach said, Clang 3.4 has all the
features, so that should be fine.

According to DistroWatch, these are the distros that have 4.9 or higher:

Mint 18 [2016-06]
Ubuntu Utopic [2014-10] (14.10, current 16.04 LTS)
Debian Jessie [2015-04] (8.0 stable, current)
Fedora 21 [2014-12] (current stable: 24)
Slackware 14.2 [2016-07]

And these are the ones that dont:

RedHat (latest is 4.8.5)
OpenSUSE (latest stable is 4.8)
SLES (latest stable is 4.8.5)
CentOS (latest stable is 4.8.5)

So, it's pretty clear that, even if the compiler is 2 or 4 years old,
the distributions are only picking up now and commercially-focused
distributions haven't got there yet.

Based on those numbers, I'd say 4.8 is a good minimum for now. The
BSDs seem to be in a similar conundrum, so it would be pretty bad to
move the requirement to 4.9 and forcing large swaths of people to
manually download / compile their toolchains.

Clang may work natively, but it definitely doesn't work cross-compiled
our of the box, and sometimes not at all. It also needs binutils and
glibc support, which we're not even considering here.

On Linux, GNU compatibility is important, and even if we had a full
toolchain (using rt, libc++, lld, musl/newlib, etc), we'd still need
to be compatible with GNU objects, shared libraries, etc.

I like using new C++14 features just as much as the next guy, but I
prefer to have a stable and usable environment more.

cheers,
--renato

The BSDs don’t seem as much of an issue. FreeBSD 10 and 11 both have LLVM 3.9 and GCC 4.9. NetBSD 6.1.5 and 7.0 both have GCC 5.3 and LLVM 3.8. Open BSD has a very old GCC, but distrowatch claims that it also has LLVM 3.8.

Going back to what Joerg said earlier. http://distrowatch.com/table.php?distribution=netbsd says NetBSD 7 ships with GCC 5.3, but Joerg said 4.8. Which is it? And even if it’s 4.8, the same page also says NetBSD has LLVM 3.8. Is that not sufficient?

BTW, CentOS and OpenSUSE have pre-built binaries for LLVM in the installer, so that won’t require a full bootstrap if someone wanted to get a modern toolchain capable of building LLVM.

FreeBSD 11 has clang 3.8.0. There is gcc in the /usr/src/contrib, but that's 4.2.1. There are still platforms that FreeBSD supports that have not finished moving to clang (from gcc 4.2.1).

-Krzysztof

For anyone still on gcc 4.2.1, then I think this entire discussion is kind of irrelevant, because they are already having to build a new toolchain to compile LLVM, since the minimum is currently 4.7. So for those people, I would imagine 4.7 vs. 4.9 makes no difference?

Maybe I’m misunderstanding the table of the distrowatch page, but if FreeBSD 11 has clang 3.8 as you say, why does distrowatch say FreeBSD 10 and 11 have clang 3.9?

NetBSD 6.1.5 has GCC 4.5 in base, 7.0 has 4.8. Clang is not included the
default for either.

Joerg

Another feedback from a downstream user: in order to build our
llvm-based compiler once and have it run on a large variety of Linux
machines, we're using ubuntu trusty as build environment, which has
the nice property of using a rather old GLIBC version. Ubuntu trusty
ships by default with g++-4.8. This can obviously be worked around
though.