I'd expect that either we'll either workaround the issues (e.g. not start using the broken feature), or else propose to require even newer versions. And as now, discuss the expected tradeoff between new features and requiring new compiler versions. On Wed, Jan 23, 2019 at 10:22 AM Krzysztof Parzyszek via llvm-dev < llvm-dev at lists.llvm.org> wrote:> On 1/22/2019 3:44 PM, JF Bastien via llvm-dev wrote: > > One clear upside of dropping older toolchains: they don’t even support > > C++11 very well. > > Do we know that the proposed newer compilers support C++14 very well? > If we encounter issues with them, how are we going to deal with that? > > -Krzysztof > > -- > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, > hosted by The Linux Foundation > _______________________________________________ > 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/20190123/01da4fc0/attachment.html>
Please include MSVC in the table. While the picture on Windows is way less complicated than for *nix, it's still a platform and toolchain that matter to a number of us in the community. Separately, there was talk of needing to have bots that specifically use the oldest supported toolchains, otherwise we can't genuinely promise that they are really supported (don't want feature dependencies creeping in by accident). --paulr From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of James Y Knight via llvm-dev Sent: Wednesday, January 23, 2019 10:36 AM To: Krzysztof Parzyszek Cc: llvm-dev Subject: Re: [llvm-dev] [RFC] migrating past C++11 I'd expect that either we'll either workaround the issues (e.g. not start using the broken feature), or else propose to require even newer versions. And as now, discuss the expected tradeoff between new features and requiring new compiler versions. On Wed, Jan 23, 2019 at 10:22 AM Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: On 1/22/2019 3:44 PM, JF Bastien via llvm-dev wrote:> One clear upside of dropping older toolchains: they don’t even support > C++11 very well.Do we know that the proposed newer compilers support C++14 very well? If we encounter issues with them, how are we going to deal with that? -Krzysztof -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190123/bd48c5ce/attachment.html>
> Separately, there was talk of needing to have bots that specifically use the > oldest supported toolchains, otherwise we can't genuinely promise that they are > really supported (don't want feature dependencies creeping in by accident).I second that.
> On Jan 23, 2019, at 9:36 AM, via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Please include MSVC in the table. While the picture on Windows is way less complicated than for *nix, it's still a platform and toolchain that matter to a number of us in the community.What are you asking for precisely? Windows and MSVC versions aren’t as version-locked as some Linux distros are when it comes to compiler version. I’ve listed a precise MSVC version in the list (as we do in GettingStarted’s toolchain list <https://llvm.org/docs/GettingStarted.html#host-c-toolchain-both-compiler-and-standard-library>).> Separately, there was talk of needing to have bots that specifically use the oldest supported toolchains, otherwise we can't genuinely promise that they are really supported (don't want feature dependencies creeping in by accident).Agreed that this is a good thing to have.> --paulr > <> > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of James Y Knight via llvm-dev > Sent: Wednesday, January 23, 2019 10:36 AM > To: Krzysztof Parzyszek > Cc: llvm-dev > Subject: Re: [llvm-dev] [RFC] migrating past C++11 > > I'd expect that either we'll either workaround the issues (e.g. not start using the broken feature), or else propose to require even newer versions. And as now, discuss the expected tradeoff between new features and requiring new compiler versions. > > On Wed, Jan 23, 2019 at 10:22 AM Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > On 1/22/2019 3:44 PM, JF Bastien via llvm-dev wrote: > > One clear upside of dropping older toolchains: they don’t even support > > C++11 very well. > > Do we know that the proposed newer compilers support C++14 very well? > If we encounter issues with them, how are we going to deal with that? > > -Krzysztof > > -- > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, > hosted by The Linux Foundation > _______________________________________________ > 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 > 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/20190123/78bba3a4/attachment.html>
On Wed, Jan 23, 2019 at 9:37 AM via llvm-dev <llvm-dev at lists.llvm.org> wrote:> Please include MSVC in the table. While the picture on Windows is way less > complicated than for *nix, it's still a platform and toolchain that matter > to a number of us in the community. > > > > Separately, there was talk of needing to have bots that specifically use > the oldest supported toolchains, otherwise we can't genuinely promise that > they are really supported (don't want feature dependencies creeping in by > accident). >IMHO the difference between "supported" and having a bot validating the configuration is whether we accept patches to fix issues on this particular platform. Otherwise, I believe historically it has been up to the users that care about a platform to provide CI ressources for it. Do we have an alternative plan? -- Mehdi> > *From:* llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] *On Behalf Of *James > Y Knight via llvm-dev > *Sent:* Wednesday, January 23, 2019 10:36 AM > *To:* Krzysztof Parzyszek > *Cc:* llvm-dev > *Subject:* Re: [llvm-dev] [RFC] migrating past C++11 > > > > I'd expect that either we'll either workaround the issues (e.g. not start > using the broken feature), or else propose to require even newer > versions. And as now, discuss the expected tradeoff between new features > and requiring new compiler versions. > > > > On Wed, Jan 23, 2019 at 10:22 AM Krzysztof Parzyszek via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > On 1/22/2019 3:44 PM, JF Bastien via llvm-dev wrote: > > One clear upside of dropping older toolchains: they don’t even support > > C++11 very well. > > Do we know that the proposed newer compilers support C++14 very well? > If we encounter issues with them, how are we going to deal with that? > > -Krzysztof > > -- > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, > hosted by The Linux Foundation > _______________________________________________ > 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/20190123/b43df2ce/attachment.html>
Krzysztof Parzyszek via llvm-dev
2019-Jan-24 18:58 UTC
[llvm-dev] [RFC] migrating past C++11
On 1/23/2019 9:36 AM, James Y Knight wrote:> I'd expect that either we'll either workaround the issues (e.g. not > start using the broken feature), or else propose to require even newer > versions. And as now, discuss the expected tradeoff between new features > and requiring new compiler versions.I don't know how well requiring newer versions upon discovery of a problem is going to work in practice. Given the cost that upgrading a production compiler can have, this may be met with resistance (although would be the best option from our point of view). My question remains: What level of confidence do we have that the C++14 support in the proposed compilers is actually sufficient for clang/llvm? Do we have any anecdotal evidence that they have been used in actual projects with success? -Krzysztof
> On Jan 24, 2019, at 10:58 AM, Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 1/23/2019 9:36 AM, James Y Knight wrote: >> I'd expect that either we'll either workaround the issues (e.g. not start using the broken feature), or else propose to require even newer versions. And as now, discuss the expected tradeoff between new features and requiring new compiler versions. > > I don't know how well requiring newer versions upon discovery of a problem is going to work in practice. Given the cost that upgrading a production compiler can have, this may be met with resistance (although would be the best option from our point of view). > > My question remains: > What level of confidence do we have that the C++14 support in the proposed compilers is actually sufficient for clang/llvm? Do we have any anecdotal evidence that they have been used in actual projects with success?I have 100% confidence that whichever compiler version we choose will have codegen bugs which require workarounds. Not just for C++14, but for pretty much anything. You can find specific bugs on the WebKit / Firefox / Chromium discussions, but there’s a ton of them and it's pretty much impossible to decide which compiler bug is important to us and which isn’t.> -Krzysztof > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev