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
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? I ask because many of these LTS distros are notoriously slow at updating their packages. While some people may think C++14 doesn't provide enough bang for the buck to justify bumping to GCC 4.9, C++17 definitely does. But at that point we're going to be talking about GCC 6.1 or 6.2, which is going to be significantly harder unless we want to wait 5-7 years, and I suspect people won't. So it might be worth it to start thinking about a long term solution early On Tue, Oct 4, 2016 at 1:04 AM David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote:> 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 > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161004/428d0c21/attachment.html>
On 4 Oct 2016, at 16:29, Zachary Turner <zturner at google.com> 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?Only if we get pre-built binaries of both release and debug configurations, with RTTI enabled[1], otherwise it’s only useful to end users, not to people wanting to develop on top of LLVM (as we use it in the compiler course). David [1] This actually shouldn’t be an issue, but last year someone removed some virtual functions from Instructions.h, so now we emit the vtable in every object and anything including LLVM headers breaks if compiled with RTTI, even if not subclassing any LLVM classes.
On Tue, 04 Oct 2016 15:29:14 +0000 Zachary Turner via llvm-dev <llvm-dev at lists.llvm.org> 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?That wouldn't address the cases where people use different build options (e.g. turning some features on or off), or apply specific patches before building. Regards Antoine.
On Tue, Oct 4, 2016 at 8:29 AM, Zachary Turner <zturner at google.com> wrote:> > I ask because many of these LTS distros are notoriously slow at updating > their packages. While some people may think C++14 doesn't provide enough > bang for the buck to justify bumping to GCC 4.9, C++17 definitely does. But > at that point we're going to be talking about GCC 6.1 or 6.2, which is > going to be significantly harder unless we want to wait 5-7 years, and I > suspect people won't. >If by "notoriously slow" you mean they don't bump their toolchain versions at all, then yeah. We just wait until the LTS release is at end-of-life before dropping it. That means we need to have at least two years of support. Forcing people to upgrade their distro every two years is still pretty annoying, and I'd rather not do it without a compelling reason. Seriously, I think we can survive another year without generic lambdas and generalized constexpr. P.S. 11 days until we drop MSVC 2013 :) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161004/a4949020/attachment.html>
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. Joerg