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 <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? >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. That said, will the libc++ implementation work with MSVC? I don't know, but I seriously doubt it. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161002/b003c9c7/attachment.html>
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 <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? > > > 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"?
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> On Oct 2, 2016, at 9:49 AM, C Bergström via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > 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 <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? >> >> >> 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"? > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
On Mon, Oct 03, 2016 at 12:49:21AM +0800, C Bergström wrote:> 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"?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