similar to: [RFC] Toolchain update policy (migrating LLVM past C++11)

Hello fans of the auto keyword! We now have a policy on how LLVM toolchains get updated <https://reviews.llvm.org/rL351765>! Let’s put that policy to good use, and talk about how we’ll move all monorepo projects past C++11. Previous Discussions LLVM dev meeting 2018 BoF "Migrating to C++14, and beyond! <http://llvm.org/devmtg/2018-10/talk-abstracts.html#bof3>" A Short

+1, thanks again for driving this. On Fri, Jan 25, 2019 at 3:57 PM JF Bastien via llvm-dev < llvm-dev at lists.llvm.org> wrote: > The discussion seems to have died down and gotten good consensus. I’ve > therefore create a patch which applies the proposed soft-errors: > > https://reviews.llvm.org/D57264 > > > We’ll only migrate to hard-error (and start using new

On Mon, Apr 1, 2019 at 1:16 PM JF Bastien via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hello folks (except fans of April 1st: this is *not* a joke), > > We discussed migrating past C++11 > <http://lists.llvm.org/pipermail/llvm-dev/2019-January/129452.html> recently > and got consensus. This led us to bump our minimum toolchain requirements >

> On Apr 1, 2019, at 4:10 PM, JF Bastien via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > >> On Apr 1, 2019, at 4:07 PM, Chandler Carruth <chandlerc at gmail.com <mailto:chandlerc at gmail.com>> wrote: >> >> On Mon, Apr 1, 2019 at 1:16 PM JF Bastien via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>

> On May 6, 2019, at 11:02 AM, Chandler Carruth <chandlerc at gmail.com> wrote: > > I know you'll be shocked that we've slipped in our efforts. ;] I don't have a super meaningful ETA update though -- a bunch of unknows have been found and addressed, and again, I feel like we might finish this in roughly a month. > > On the flip side, I do want to clarify the

On Mon, May 6, 2019 at 2:44 PM James Y Knight <jyknight at google.com> wrote: > Given the small number of library features added by c++14, and given that > they were mostly already implemented in libstdc++ 4.9 [1], I suspect that > moving to c++14 with that stdlib as the minimum probably will not actually > cause friction for developers who are using normal toolchains to be able

I'm happy to announce that Google has migrated to libc++, and we're ready for C++14 and beyond. JF, what are the remaining blockers? /Eric On Mon, May 6, 2019 at 5:12 PM JF Bastien via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On May 6, 2019, at 2:08 PM, Chandler Carruth <chandlerc at gmail.com> wrote: > > On Mon, May 6, 2019 at 2:44 PM James Y

I’d like us to move forward with something along the lines Erich proposed back in May, ideally early enough in the LLVM 8 release process that people testing the release will be able to provide feedback. Are there any remaining concerns? > On May 23, 2018, at 6:21 AM, Keane, Erich via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi all- > I just wanted to bump this again,

> On Jan 10, 2019, at 4:30 PM, Mehdi AMINI <joker.eph at gmail.com> wrote: > > I'm a bit puzzled as of why would a fix period of time be the best option to automatically cut support for older compilers? > > Historically I believe we've been looking at a combination of: > > 1) What new feature we gain by dropping support for a given version of the compiler >

I've heard just about zero opposition to this, so I've put a code review together here: https://reviews.llvm.org/D47073 With the intent of either implementing this policy change, or encouraging further discussion/bikeshed. Thanks all! -Erich -----Original Message----- From: Brooks Davis [mailto:brooks at freebsd.org] Sent: Sunday, May 13, 2018 10:34 AM To: Keane, Erich <erich.keane

Last time this came up, there were a lot of people that were stuck on GCC 4.9 due to ABI reasons. I think forcing that upgrade is going to be the most disruptive part of this, and I think that will really need a decent amount of time. =[ On Thu, May 10, 2018 at 2:26 PM JF Bastien via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > On May 10, 2018, at 12:25 PM, Evgeny Astigeevich

On Fri, May 11, 2018 at 01:37:22PM +0000, Keane, Erich via llvm-dev wrote: > Hi All- > As we all know, the C++14 discussion is flaring up again. Chandler brought up that he would like a concrete plan to switch. In my opinion, this is insufficient, as it will result in us simply having this discussion AGAIN next release. Instead, I would prefer us to have a concrete Policy on our host

Hi All- As we all know, the C++14 discussion is flaring up again. Chandler brought up that he would like a concrete plan to switch. In my opinion, this is insufficient, as it will result in us simply having this discussion AGAIN next release. Instead, I would prefer us to have a concrete Policy on our host compilers. That way, changes like this are unsurprising to our users, and advance our

And what will be the lowest version of clang that will be supported for building? FreeBSD's oldest supported OS release is still stuck with clang 3.4 (and a corresponding copy of libc++), which has some support for C++14, although it's still called c++1y there, but probably not C++17. Also, it isn't exactly clear from which llvm/clang release C++17 is fully supported. -Dimitry >

Hi, IMHO, it’s a good idea to move to C++14 first. What do you think about doing this by two phases: Phase1: require GCC >= 5 but build in C++11 mode (this will give time to adapt build infrastructure to a new gcc) Phase2: switch to C++14 Thanks, Evgeny From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Reid Kleckner via llvm-dev <llvm-dev at lists.llvm.org>

Hello compiler enthusiasts, The Apple LLVM team would like to propose that a new a security process and an associated private LLVM Security Group be created under the umbrella of the LLVM project. A draft proposal for how we could organize such a group and what its process could be is available on Phabricator <https://reviews.llvm.org/D70326>. The proposal starts with a list of goals for

> On May 10, 2018, at 1:50 PM, Chandler Carruth <chandlerc at google.com> wrote: > > Last time this came up, there were a lot of people that were stuck on GCC 4.9 due to ABI reasons. I think forcing that upgrade is going to be the most disruptive part of this, and I think that will really need a decent amount of time. =[ Those people don’t build a browser? Because if they build

> On May 10, 2018, at 12:25 PM, Evgeny Astigeevich via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi, > > IMHO, it’s a good idea to move to C++14 first. > > What do you think about doing this by two phases: > > Phase1: require GCC >= 5 but build in C++11 mode (this will give time to adapt build infrastructure to a new gcc) > Phase2: switch to

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

Thank you for progressing this, JF! As vendor contacts for Arm, myself (kristof.beyls at arm.com<mailto:kristof.beyls at arm.com>) and Peter Smith (peter.smith at arm.com<mailto:peter.smith at arm.com>) are interested in being part of the Security Group. We’re also interested in helping in the forming of this group. Thanks, Kristof On 11 Jun 2020, at 17:39, JF Bastien via llvm-dev