similar to: Pointer to temporary issue in ArrayRefTest.InitializerList

Sorry for the inline-comment format being weird, I haven't figured out yet how to do '>' stuff in outlook yet :/ Hopefully this is clear enough. -----Original Message----- From: mehdi.amini at apple.com [mailto:mehdi.amini at apple.com] Sent: Wednesday, August 24, 2016 10:55 AM To: Keane, Erich <erich.keane at intel.com> Cc: llvm-dev at lists.llvm.org Subject: Re:

Hi, Building LLVM with a newer GCC version seems to generate several compiler warnings, some of which look like false positives. For example, the '-Winit-list-lifetime' warning added in GCC9 triggers for one of the constructors for ArrayRef, the one taking an initializer_list. How are false positive warnings dealt with in LLVM in general? It's of course possible to just ignore them

Hello, GCC 9.0 introduces a new warning checkers and some of them found possible issues in LLVM. In file included from /home/davidbolvansky/trunk/llvm/include/llvm/Analysis/LazyCallGraph.h:38, from /home/davidbolvansky/trunk/llvm/unittests/Analysis/LazyCallGraphTest.cpp:10: /home/davidbolvansky/trunk/llvm/include/llvm/ADT/ArrayRef.h: In instantiation of

To be clear: I’m concerned about the amount of our infrastructure (as well as downstream infrastructure, this would be actually pretty painful for both of my downstreams) that the community would have break/need fixing as a part of that. So I want this to happen ONCE. I think it is well motivated now, but switching from ‘default’ to ‘main’ when that becomes the ‘standard’ one seems way less

I mean, we could change it twice? There are about a hundred scripts out there for doing it. -eric On Fri, Jun 19, 2020 at 11:40 AM Keane, Erich <erich.keane at intel.com> wrote: > Do we have any ability to reach out to github (at least?) to see what they > are going to do? I’d very much like to avoid being the odd-project-out > here. > > > > > > > >

I disagree with your timing concerns. Changing is still straightforward and I'd like to see this done within 1-2 weeks. Thanks. -eric On Fri, Jun 19, 2020 at 12:22 PM Chris Tetreault <ctetreau at quicinc.com> wrote: > +1 to waiting until git and/or github decide on a new name for the default > branch. I think there is a compelling reason to change the name of the > default

As I mentioned on another thread, we also use the term "slave" for the BuildBot builders. In the past, I was told this was due to being stuck on an old version of BuildBot. Fortunately, there is already work in progress to update BuildBot to a newer version. Since that's also going affect all the build machines, perhaps changing the name of the main branch should happen

That's a good point, we should definitely be respectful of the build bot owners time, that said I think it's the coordination that takes the time rather than the change :) On Fri, Jun 19, 2020 at 11:48 AM Keane, Erich via llvm-dev < llvm-dev at lists.llvm.org> wrote: > My understanding is the biggest concern about the name change is the > ‘cost’ associated with needing to

There's really no guarantee that things will shake out the same in near term between the projects. -eric On Fri, Jun 19, 2020 at 11:31 AM Keane, Erich <erich.keane at intel.com> wrote: > I’m a bit mixed on this. While yes, we should change this as soon as is > practical, it would be a shame to pick something sufficiently different > from the rest of the world, as that would

Alright, I guess it isn’t just my pain then, it makes it feel better ☺ I think that proposed feature would be really nice, since it would encourage people to write tests that have a //CHECK: some-thing-after-header first! From: Reid Kleckner [mailto:rnk at google.com] Sent: Thursday, March 30, 2017 11:15 AM To: Keane, Erich <erich.keane at intel.com> Cc: llvm-dev at lists.llvm.org Subject:

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,

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

Ah, I see what you mean. I would have no problem with January 7th being pushed back a while if that helps out your transition. Would that be possible Mike? From: Stephen Hines <srhines at google.com> Sent: Monday, November 16, 2020 6:03 PM To: Keane, Erich <erich.keane at intel.com> Cc: Mehdi AMINI <joker.eph at gmail.com>; llvm-dev <llvm-dev at lists.llvm.org>; clang

Stephen, does that help you out? From: Mike Edwards <mike at sqlby.me> Sent: Wednesday, November 18, 2020 10:55 AM To: Keane, Erich <erich.keane at intel.com> Cc: Stephen Hines <srhines at google.com>; llvm-dev <llvm-dev at lists.llvm.org>; clang developer list <cfe-dev at lists.llvm.org>; Mehdi AMINI <joker.eph at gmail.com> Subject: Re: [llvm-dev] Renaming

> On Dec 14, 2016, at 9:37 AM, Keane, Erich via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > One of my coworkers noticed that we(Clang/LLVM) have quite a few places where we need to iterate through 2 equally sized ranges at the same time, often related to parm/arg relationships. In a few cases we(Clang/LLVM) use a traditional for-loop with 2 iterators in it. In a few others,

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

Hi all- I hope this is the right place for this. Anyway, the primary usage for the utility "FileCheck" is to pattern match for specific values in a stream. This is perfectly consistent and deterministic for the most part! However, when validating clang's LLVM-IR generation, it is possible to make an invalid match against the top few generated lines (the LLVM-IR Headers), which are

Based on my reading of the release pages (https://gcc.gnu.org/releases.html and http://releases.llvm.org/) 6/5 would make GCC 4.7 and Clang 3.1 required, and GCC 4.8 and Clang 3.3 the first to not warn. 6/5 is surprisingly close to making the policy conform to exactly our current time-lag, where we are GCC4.8 (instead of 4.7) and Clang 3.1 (also 3.1). -Erich From: Andrew Kelley

> 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 >

Hi all- A few weeks ago I noticed that our "omit braces with single line blocks" rule wasn't written down! Additionally, as a group on IRC and in review, noticed that the enforcement of this rule has been extremely inconsistent. We made a first run at codifying our existing practice here: https://reviews.llvm.org/D80947, which was then committed after significant time on