[llvm-dev] Using C++14 code in LLVM (original) (raw)

C Bergström via llvm-dev llvm-dev at lists.llvm.org
Sun Oct 2 09:49:21 PDT 2016

On Mon, Oct 3, 2016 at 12:37 AM, Zachary Turner via llvm-dev <llvm-dev at lists.llvm.org> wrote:

On Sat, Oct 1, 2016 at 11:46 PM Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org> wrote:

On Sun, Oct 02, 2016 at 05:33:40AM +0000, Zachary Turner via llvm-dev wrote: > 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 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? That wasn't even the main argument :) 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.

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"?

More information about the llvm-dev mailing list