I’m ok with that, but the reason I’m pushing is because there is no clear plan of action. Even if the plan of action is “When X happens, we can enable C++14”, that’s fine too. I just want to know, concretely, what is X. We should either be able to say never or give a reasonable set of conditions that would enable a switch. All I’ve seen though is “it’s hard” which just means I’m going to ask again next year, and the year after, etc due to lack of clear guidance. To address your point though , this isn’t really about building everything with clang. You don’t need to bootstrap Clang to build a hypothetical C++17 enabled LLVM, you could also bootstrap a more modern version of GCC. This is really more fundamentally about “Can we have a clearly defined policy about how often we can bump the minimum compiler version, like we have for MSVC?” On Tue, Oct 31, 2017 at 10:30 PM Chris Lattner <clattner at nondot.org> wrote:> > > On Oct 31, 2017, at 2:11 PM, Zachary Turner via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > Note that we could, in theory, provide a python script or something > called `bootstrap.py` which > > > > a) downloads a source tarball, or specific git revision for a particular > clang release > > b) compiles it using system compiler > > c) installs it > > d) cleans up > > > > so that you wouldn't have to do anything manually. > > I love that you’re pushing hard on this, but I don’t think that this > approach is practical. While I love the future where everything is built > with ToT clang, there are lots of reason why people either don’t want to do > that (e.g. for “subjectively" bad reasons) or where they really can’t (e.g. > clang doesn’t support their weird target). > > -Chris > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171101/ce9b8046/attachment.html>
FWIW, on FreeBSD, the compiler bootstrap path has mostly been to use "ancient" compilers (e.g. gcc 4.2 from before the switch to GPLv3) to build clang and libc++ 3.4.1, the last version that can be built with a pre-C++11 stack. (This version is available from FreeBSD 9 onwards.) Then, clang/libc++ 3.4.1 can be used to build later versions, such as 5.0.0. I'm not sure that 3.4.1 already supports C++14, but it will probably do so partially. If the requirements are raised to C++17, the bootstrap path will indeed become: ancient compiler -> clang/libc++ 3.4.1 -> clang/libc++ 5.0.0 (or whichever version supports enough of C++17) -> clang/libc++ ToT. -Dimitry> On 1 Nov 2017, at 07:23, Zachary Turner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I’m ok with that, but the reason I’m pushing is because there is no clear plan of action. Even if the plan of action is “When X happens, we can enable C++14”, that’s fine too. I just want to know, concretely, what is X. > > We should either be able to say never or give a reasonable set of conditions that would enable a switch. All I’ve seen though is “it’s hard” which just means I’m going to ask again next year, and the year after, etc due to lack of clear guidance. > > To address your point though , this isn’t really about building everything with clang. You don’t need to bootstrap Clang to build a hypothetical C++17 enabled LLVM, you could also bootstrap a more modern version of GCC. > > This is really more fundamentally about “Can we have a clearly defined policy about how often we can bump the minimum compiler version, like we have for MSVC?” > > On Tue, Oct 31, 2017 at 10:30 PM Chris Lattner <clattner at nondot.org <mailto:clattner at nondot.org>> wrote: > > > On Oct 31, 2017, at 2:11 PM, Zachary Turner via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > > > Note that we could, in theory, provide a python script or something called `bootstrap.py` which > > > > a) downloads a source tarball, or specific git revision for a particular clang release > > b) compiles it using system compiler > > c) installs it > > d) cleans up > > > > so that you wouldn't have to do anything manually. > > I love that you’re pushing hard on this, but I don’t think that this approach is practical. While I love the future where everything is built with ToT clang, there are lots of reason why people either don’t want to do that (e.g. for “subjectively" bad reasons) or where they really can’t (e.g. clang doesn’t support their weird target). > > -Chris > > _______________________________________________ > 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/20171101/9133d14f/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 223 bytes Desc: Message signed with OpenPGP URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171101/9133d14f/attachment.sig>
On Tue, Oct 31, 2017 at 11:23 PM Zachary Turner <zturner at google.com> wrote:> I’m ok with that, but the reason I’m pushing is because there is no clear > plan of action. Even if the plan of action is “When X happens, we can > enable C++14”, that’s fine too. I just want to know, concretely, what is X. > > We should either be able to say never or give a reasonable set of > conditions that would enable a switch. All I’ve seen though is “it’s hard” > which just means I’m going to ask again next year, and the year after, etc > due to lack of clear guidance. > > To address your point though , this isn’t really about building everything > with clang. You don’t need to bootstrap Clang to build a hypothetical C++17 > enabled LLVM, you could also bootstrap a more modern version of GCC. > > This is really more fundamentally about “Can we have a clearly defined > policy about how often we can bump the minimum compiler version, like we > have for MSVC?”To make this even more concrete, let me offer a proposal: * We can bump the minimum required non-Microsoft toolchain version every 4 years. Having something written like this allows us to have a schedule, and having a schedule allows downstream consumers to plan upgrades as needed so as to minimize disruption. 4 years is also a pretty reasonable amount of time IMO, but we can certainly discuss the exact value of N. I haven't said anything here about what it can be bumped *to*. But in the interest of making progress, I'm separating the decisions out into smaller pieces so we can focus on one thing at a time. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171101/a053526a/attachment.html>
André Jansen Medeiros Villar via llvm-dev
2017-Nov-11 01:07 UTC
[llvm-dev] Using C++14 code in LLVM
Given that no policy existed before the adoption of it should include a grace period. So it should read: * Starting with clang 7 we can bump the minimum required non-Microsoft toolchain version every 4 years. 2017-11-01 14:24 GMT-02:00 Zachary Turner via llvm-dev < llvm-dev at lists.llvm.org>:> On Tue, Oct 31, 2017 at 11:23 PM Zachary Turner <zturner at google.com> > wrote: > >> I’m ok with that, but the reason I’m pushing is because there is no clear >> plan of action. Even if the plan of action is “When X happens, we can >> enable C++14”, that’s fine too. I just want to know, concretely, what is X. >> >> We should either be able to say never or give a reasonable set of >> conditions that would enable a switch. All I’ve seen though is “it’s hard” >> which just means I’m going to ask again next year, and the year after, etc >> due to lack of clear guidance. >> >> To address your point though , this isn’t really about building >> everything with clang. You don’t need to bootstrap Clang to build a >> hypothetical C++17 enabled LLVM, you could also bootstrap a more modern >> version of GCC. >> >> This is really more fundamentally about “Can we have a clearly defined >> policy about how often we can bump the minimum compiler version, like we >> have for MSVC?” > > > To make this even more concrete, let me offer a proposal: > > * We can bump the minimum required non-Microsoft toolchain version every 4 > years. > > Having something written like this allows us to have a schedule, and > having a schedule allows downstream consumers to plan upgrades as needed so > as to minimize disruption. > > 4 years is also a pretty reasonable amount of time IMO, but we can > certainly discuss the exact value of N. > > I haven't said anything here about what it can be bumped *to*. But in the > interest of making progress, I'm separating the decisions out into smaller > pieces so we can focus on one thing at a time. > > _______________________________________________ > 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/20171110/af0c05e4/attachment.html>
As long as the target is supported, I think the difficulty of rolling a cross chain is overrated, but I've done lots of them and I remember when it wasn't relatively easy. I don't see their being harder at first as a reason to impede progress with the language which, keep in mind, we're actually writing the compiler in... as long as nobody suggests a total port to Delphi. ;-) GNOMETOYS On Wed, Nov 1, 2017 at 11:24 AM, Zachary Turner via llvm-dev < llvm-dev at lists.llvm.org> wrote:> On Tue, Oct 31, 2017 at 11:23 PM Zachary Turner <zturner at google.com> > wrote: > >> I’m ok with that, but the reason I’m pushing is because there is no clear >> plan of action. Even if the plan of action is “When X happens, we can >> enable C++14”, that’s fine too. I just want to know, concretely, what is X. >> >> We should either be able to say never or give a reasonable set of >> conditions that would enable a switch. All I’ve seen though is “it’s hard” >> which just means I’m going to ask again next year, and the year after, etc >> due to lack of clear guidance. >> >> To address your point though , this isn’t really about building >> everything with clang. You don’t need to bootstrap Clang to build a >> hypothetical C++17 enabled LLVM, you could also bootstrap a more modern >> version of GCC. >> >> This is really more fundamentally about “Can we have a clearly defined >> policy about how often we can bump the minimum compiler version, like we >> have for MSVC?” > > > To make this even more concrete, let me offer a proposal: > > * We can bump the minimum required non-Microsoft toolchain version every 4 > years. > > Having something written like this allows us to have a schedule, and > having a schedule allows downstream consumers to plan upgrades as needed so > as to minimize disruption. > > 4 years is also a pretty reasonable amount of time IMO, but we can > certainly discuss the exact value of N. > > I haven't said anything here about what it can be bumped *to*. But in the > interest of making progress, I'm separating the decisions out into smaller > pieces so we can focus on one thing at a time. > > _______________________________________________ > 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/20171110/4168c186/attachment.html>