similar to: MLIR changes not sent to any mailing lists?

On Thu, Jan 30, 2020 at 9:50 AM Tom Stellard <tstellar at redhat.com> wrote: > > On 01/30/2020 05:25 AM, Hans Wennborg via llvm-dev wrote: > > For example, 7984b47401f7f36475619abf2ff02de3b5ff0481 does not seem to > > have made it to any mailing lists. > > > > This makes things harder for me as release manager, as those changes > > are essentially landing

On Thu, Feb 6, 2020 at 11:24 AM Hans Wennborg <hans at chromium.org> wrote: > > On Thu, Jan 30, 2020 at 4:04 PM Hans Wennborg <hans at chromium.org> wrote: > > > > On Thu, Jan 30, 2020 at 9:50 AM Tom Stellard <tstellar at redhat.com> wrote: > > > > > > On 01/30/2020 05:25 AM, Hans Wennborg via llvm-dev wrote: > > > > For example,

On 02/10/2020 01:02 PM, Martin Storsjö wrote: > On Thu, 6 Feb 2020, Tom Stellard via llvm-dev wrote: > >> On 02/06/2020 02:48 PM, Greg Bedwell wrote: >>> Here's a non-MLIR commit that also wasn't sent to any list: >>> b3576f60ebc8f660afad8120a72473be47517573 >>> >>> >>> I don't think that this is the same issue as the

On 02/06/2020 02:48 PM, Greg Bedwell wrote: > Here's a non-MLIR commit that also wasn't sent to any list: > b3576f60ebc8f660afad8120a72473be47517573 > > > I don't think that this is the same issue as the mlir commits. This particular one is likely due to the issue of non-ascii characters the commit summary (author/comitter name in this case) causing some sort

For example: https://github.com/llvm/llvm-project/commit/549ff601f053303356abe7d8fca8fbcf5e3502e7 and https://github.com/llvm/llvm-project/commit/4eacc32672e60113b835c4356d1c398dc1e30279 Don't seem to have made it to cfe-commits. This makes it harder to search for stuff, reply to commits, and most importantly it allows these patches to land "under the radar", potentially without

Hello everyone, 3.7-rc3 has just been tagged. Testers, please test, build binaries, upload to the sftp and report results to this thread. Again, a lot of patches got merged between rc2 and rc3, but hopefully nothing that should upset things. One thing that did change is that the release script now correctly symlinks clang-tools-extra into the build. If this causes problems on your platform,

+Hans Wennborg <hans at chromium.org> +tstellar at redhat.com <tstellar at redhat.com> for release thoughts.... On Mon, Jan 14, 2019 at 6:03 PM Craig Topper <craig.topper at gmail.com> wrote: > As far as I could tell, the only non-Intel contributions were from > mechanical API updates or fixing include paths when files moved to other > libraries for layering. > >

It seems this is a cmake vs autoconf thing. With cmake, it builds correctly, but with autoconf I get the same error as you. I probably shouldn't have made this change while we were in the release process as it was potentially risky :-/ I've reverted it now, so hopefully the next build should be problem free. Thanks, Hans On Fri, Aug 21, 2015 at 5:09 AM, Dimitry Andric <dimitry at

Hi Dmitry, if I understood Hans clang-extra wasn't part of the build prior to rc3. Just delete it and run script with --no-checkout. On Fri, Aug 21, 2015 at 7:15 PM, Dimitry Andric <dimitry at andric.com> wrote: > Hm, it does not seem to compile at all here? The build ends with: > > In file included from >

Hi Hans, 2016-07-30 0:57 GMT+02:00 Hans Wennborg via llvm-dev <llvm-dev at lists.llvm.org>: > There are still open merge requests and bugs, but I'd like to get the > real testing started to see where we're at. Just to double-check, is this bug also on people's radar? It causes Clang to crash when trying to build a fair number of Open Source packages/libraries. In my

On Wed, Jul 26, 2017 at 11:10 AM, Tom Stellard <tstellar at redhat.com> wrote: > On 07/26/2017 12:52 PM, Hans Wennborg wrote: >> I'm a little vary of adding more fields, because I think we already >> have lots of fields that are never used. >> > > I'm up for removing unused fields too. Which ones did you have in mind? I think URL, Keywords, Alias, and

Hi all Thanks for all the replies and engagement on this issue. First point, given the state of discussions today I would like to propose that we don't start the merge at 10:00 GMT on Monday 13th as proposed and we delay by at least 24 hours until after the scheduled F18 technical call on Monday afternoon. In order to help compile a plan of action, I've tried to compile a list of the

On 01/14/2020 08:59 AM, Russell Gallop wrote: > Hi Tom, Hans, > > I can't see LLVM-9.0.1-win*.exe from Hans on the GitHub release page (https://github.com/llvm/llvm-project/releases/tag/llvmorg-9.0.1). Is this still in progress? > Hans did you upload these? I don't see them on the server. -Tom > Thanks > Russ > > On Thu, 9 Jan 2020 at 20:05, Tom Stellard via

The problem seems to be caused by the way the symlinks are setup in test-release.sh, e.g. like so: llvm.src/tools/clang -> ../../cfe.src cfe.src/tools/extra -> ../../clang-tools-extra.src When it then tries to access the path llvm.src/tools/clang/tools/extra/clang-apply-replacements/lib/Tooling/../../../../../include, it fails. I tried this on both FreeBSD, OSX and Linux, but it fails

Hi Eric, Renato Thanks again for the engagement and challenge on this, it is really useful feedback to know what we need to do to get F18 into the project in a way that everyone is happy with. I have tried to give timelines on the points addressed below where I can today. Clearly we need to do some work on points 8-11, but are the above plans/answers to points 1-7 sufficient at this stage and

Hey, I need to make a radar chart (also called spider chart, star chart) and am trying to see if there is a plugin for this. GchartRB looked good, but I don''t see Radar Charts on here: http://gchartrb.rubyforge.org/ Does anyone know a good plugin or gem that will generate radar charts? tl;dr, Joe -- Posted via http://www.ruby-forum.com/.

On Thu, Jan 9, 2020 at 4:19 AM Mehdi AMINI via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > On Tue, Jan 7, 2020 at 6:04 AM Peter Waller via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Hi All, >> >> As discussed before Christmas, this is a reminder that we intend to >> merge flang on the 13th January (next Monday) before the

On 10/15/2019 09:44 PM, Mehdi AMINI wrote: > > > On Tue, Oct 15, 2019 at 9:33 PM Tom Stellard <tstellar at redhat.com <mailto:tstellar at redhat.com>> wrote: > > On 10/15/2019 09:24 PM, Mehdi AMINI wrote: > > Hi Tom. > > > > One issue with this is that we don't have a clear "ordering" from linear revision numbers from

The CentOS team likes to offer an apology for the political spam mails which went through our mail servers earlier today. Due to the nature of mailing list software for public discussion groups, there aren't that many security measures which can be taken to check which mails are supposed to get through and which mails aren't. Total safety can only be had by a moderation of all lists -

On 10/16/2019 07:31 AM, Roman Lebedev wrote: > +1, please. > > Also, putting a tag on the *first* commit in the repo, > and doing `git describe --match FIRST_COMMIT_TAG` will be *great*! > Do we need to add a tag or is `git rev-list --count HEAD` good enough? -Tom > Roman. > > On Wed, Oct 16, 2019 at 5:23 PM Robinson, Paul via llvm-dev > <llvm-dev at