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 <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. Thoughts? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161002/03d819b3/attachment.html>
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.9I 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 2016-10-01 22:33 GMT-07:00 Zachary Turner via llvm-dev < llvm-dev at lists.llvm.org>:> 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 <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. > > Thoughts? > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161002/e2e1b5d6/attachment.html>
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 On 2 Oct 2016 6:33 a.m., "Zachary Turner via llvm-dev" < llvm-dev at lists.llvm.org> wrote:> 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 <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. > > Thoughts? > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161002/7e6fa8e6/attachment.html>
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 Oct 1, 2016, at 10:33 PM, Zachary Turner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > 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.9What clang version has all this features? — Mehdi> > 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 <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. > > Thoughts? > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
3.4 On Sun, Oct 2, 2016 at 10:55 AM Mehdi Amini <mehdi.amini at apple.com> wrote:> > > On Oct 1, 2016, at 10:33 PM, Zachary Turner via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > 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 > > What clang version has all this features? > > — > Mehdi > > > > > > 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 <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. > > > > Thoughts? > > _______________________________________________ > > LLVM Developers mailing list > > llvm-dev at lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161002/396d3703/attachment.html>
On 2 October 2016 at 05:33, Zachary Turner via llvm-dev <llvm-dev at lists.llvm.org> wrote:> > 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?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.
On the one hand, I like this proposal. But that is because every system I care about has or can easily acquire a GCC 4.9 baseline compiler. So when I imagine that you want to move to GCC 5 instead of GCC 4.9, I get extremely nervous. I *do* think we should be prepared to move the baseline forward though. We picked GCC 4.7 a *very* long time ago. 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. 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. 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. However, once all of that is settled and we know what the baseline compilers are, I'm 100% in favor of adopting essentially all of the features they support and that work reliably. If we can get most of C++14, great, let's do it. To Pete's point, I do think C++17 has more exciting features in the pipeline, but I think we should take a greedy approach here, and adopt as many features as are beneficial as early as we can get away with given the host compilers we support. Which means the primary question is about the host compilers IMO. -Chandler On Sat, Oct 1, 2016 at 10:33 PM Zachary Turner via llvm-dev < llvm-dev at lists.llvm.org> wrote:> 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 <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. > > Thoughts? > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161003/20cdbfdf/attachment.html>
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
Zachary Turner via llvm-dev <llvm-dev at lists.llvm.org> writes:> 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.I'm not convinced that the cost is worth the gain for these features. Most of these are relatively straight forward (with more boilerplate) to work around in C++11, and I'd rather we not get into a situation where to bootstrap clang you need to build a C++11 compatible version so that you can build a C++14 compatible one so that you can build a C++17 compatible one, etc. Consider that -std=c++17 isn't yet a valid flag on trunk clang, so if we bump to C++14 now then we're practically guaranteed that when we want to update to 17 we'll run into multi-stage bootstrapping problems.> 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.I'd be much happier getting to requiring "full" C++11 support than going to partial C++14 support - having partial support for C++11 has meant that many issues are only caught by bots, and I much prefer the compiler to complain when I use some feature we're not allowed to use yet.> 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. > > Thoughts? > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> ...I think we should take a greedy approach here, and adopt as manyfeatures as are beneficial as early as we can get away with given the host compilers we support. +1! If we can move to C++14 I'd want it for the generalized lambda captures alone. Cheers, Lang. On Mon, Oct 3, 2016 at 12:43 AM, Chandler Carruth via llvm-dev < llvm-dev at lists.llvm.org> wrote:> On the one hand, I like this proposal. But that is because every system I > care about has or can easily acquire a GCC 4.9 baseline compiler. So when I > imagine that you want to move to GCC 5 instead of GCC 4.9, I get extremely > nervous. > > I *do* think we should be prepared to move the baseline forward though. We > picked GCC 4.7 a *very* long time ago. > > 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. 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. > > 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. > > > However, once all of that is settled and we know what the baseline > compilers are, I'm 100% in favor of adopting essentially all of the > features they support and that work reliably. If we can get most of C++14, > great, let's do it. To Pete's point, I do think C++17 has more exciting > features in the pipeline, but I think we should take a greedy approach > here, and adopt as many features as are beneficial as early as we can get > away with given the host compilers we support. > > Which means the primary question is about the host compilers IMO. > > -Chandler > > On Sat, Oct 1, 2016 at 10:33 PM Zachary Turner via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> 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 <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. >> >> Thoughts? >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161003/0323a9b5/attachment.html>
> On Oct 3, 2016, at 10:38 AM, Justin Bogner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Zachary Turner via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> writes: >> 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. > > I'm not convinced that the cost is worth the gain for these features. > Most of these are relatively straight forward (with more boilerplate) to > work around in C++11, and I'd rather we not get into a situation where > to bootstrap clang you need to build a C++11 compatible version so that > you can build a C++14 compatible one so that you can build a C++17 > compatible one, etc. Consider that -std=c++17 isn't yet a valid flag on > trunk clang, so if we bump to C++14 now then we're practically > guaranteed that when we want to update to 17 we'll run into multi-stage > bootstrapping problems.I didn’t quite get this last part, can you elaborate please? Thanks, — Mehdi> >> 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. > > I'd be much happier getting to requiring "full" C++11 support than going > to partial C++14 support - having partial support for C++11 has meant > that many issues are only caught by bots, and I much prefer the compiler > to complain when I use some feature we're not allowed to use yet. > >> 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. >> >> Thoughts? >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev> > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161003/483c4047/attachment-0001.html>
On Mon, Oct 03, 2016 at 10:38:32AM -0700, Justin Bogner via llvm-dev wrote:> Zachary Turner via llvm-dev <llvm-dev at lists.llvm.org> writes: > > 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. > > I'm not convinced that the cost is worth the gain for these features.That is my concern as well. It seems quite a bit like "Oh new, shinny, want!" Keep in mind that LLVM is now integral part of the Mesa toolchain. The requirements here do not only affect developers, but there are a lot of users impacted directly by the choices made. Joerg
I'm not in favor of dropping GCC 4.8 support yet. It's the default compiler for Ubuntu Trusty, which is from 2014, which isn't that old. I think it's important that LLVM build out of the box with the commonly installed system compiler. We made an exception when we went to C++11 because it was worth it. I don't think the features provided by C++14 are quite as compelling as what we got for the pain of raising our minimum GCC version to 4.7.1. On Sat, Oct 1, 2016 at 10:33 PM, Zachary Turner via llvm-dev < llvm-dev at lists.llvm.org> wrote:> 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 <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. > > Thoughts? > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161003/cbf2d12f/attachment.html>
On 3 Oct 2016, at 20:06, Reid Kleckner via llvm-dev <llvm-dev at lists.llvm.org> wrote:> > I'm not in favor of dropping GCC 4.8 support yet. It's the default compiler for Ubuntu Trusty, which is from 2014, which isn't that old. I think it's important that LLVM build out of the box with the commonly installed system compiler.We are currently using Trusty (14.04) on our teaching machines - it’s an LTS release that’s still supported. We upgraded two years ago because we couldn’t build LLVM with the previous LTO release without my needing to build gcc, libstdc++, and CMake from source and install them with futzed rpaths. This was a very fragile environment for teaching. We’re likely to keep 14.04 for another year, because 16.04 breaks various things used in other courses. Building the latest LLVM release wasn’t too bad this time, but it did require that I built a new CMake, because apparently some time between 3.7 and 3.9 we bumped the minimum CMake requirement to one that doesn’t ship with 14.04. If anyone is looking to hire students with LLVM experience, please remember that most university lab systems are using some form of long-term support release of their institution's favourite OS and it’s hard to persuade people to teach using LLVM if they can’t even build it on their lab machines. David