On Wed, Oct 5, 2016 at 3:55 AM, Joerg Sonnenberger via llvm-dev
<llvm-dev at lists.llvm.org> wrote:> On Tue, Oct 04, 2016 at 03:29:14PM +0000, Zachary Turner via llvm-dev
wrote:
>> I'm not familiar with the release process, but couldn't most of
the
>> concerns raised in this thread be addressed by shipping prebuilt
binaries
>> for these big platforms with older toolchains? How much of a burden is
that
>> on the release maintainer?
>
> One thing you seem to be forgetting is that LLVM is an infrastructure
> component now. It is not only a fancy C/C++ compiler, but it is also an
> integral part of the graphic stack for AMD GPUs and possible more.
> That's even more reason to start to be more conservative when it comes
> to shiny new features. Making it a nightmare to merge new GPU drivers
> because some silly infrastructure project decides to run after every new
> language feature is a very good way to screw up a project's reputation.
> This might be somewhat exaggerated, but not that far from the truth.
Pragmatically, I think there is a balance between what's a "shiny new
feature" and something which is part of a 3 year old published
standard that has an open source implementations and supporting
compilers on modern systems.
I'm not advocating that C++14 should be adopted and I think strong
technical arguments for/against need to be made, not comments that
amount to "the sky is falling".
What's the problem c++14 would solve and what are potential
alternative solutions. If the argument is "just because" then I'd
tend
to lean towards a conservative view and delay adoption.
Jörg - I can't poke my nose where it doesn't belong, but if NetBSD
switched to a more modern toolchain it may have some benefits.