> 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>
Mehdi Amini <mehdi.amini at apple.com> writes:>> 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?Consider if we adopt C++14 features today. Then to build clang-4.0 you need a C++14 compatible compiler (Maybe clang-3.4, probably more like clang-3.5 or clang-3.6 based on our current clang-3.1 claim). So to bootstrap you build clang-3.5 (I think that's before we required C++11) and then build clang-4.0. That's not too bad, but then lets say we switch to requiring C++17 in clang-4.4 - now, you need to build clang-3.5 first so that you can build clang-4.0, *then* you use clang-4.0 to build clang-4.4. What I'm nervous about here is increasing the number of steps to get to a working compiler - I don't think we want to require C++14 before we can even build C++17.
> On Oct 3, 2016, at 11:14 AM, Justin Bogner <mail at justinbogner.com> wrote: > > Mehdi Amini <mehdi.amini at apple.com> writes: >>> 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? > > Consider if we adopt C++14 features today. Then to build clang-4.0 you > need a C++14 compatible compiler (Maybe clang-3.4, probably more like > clang-3.5 or clang-3.6 based on our current clang-3.1 claim). So to > bootstrap you build clang-3.5 (I think that's before we required C++11) > and then build clang-4.0. > > That's not too bad, but then lets say we switch to requiring C++17 in > clang-4.4 - now, you need to build clang-3.5 first so that you can build > clang-4.0, *then* you use clang-4.0 to build clang-4.4. What I'm nervous > about here is increasing the number of steps to get to a working > compiler - I don't think we want to require C++14 before we can even > build C++17.OK, got it. — Mehdi