search for: honermann

...s that they would continue to be fed from the updates to the svn repo. But again, I don't recall where I got that impression from. It may have been a bad assumption on my part. Tom. From: Anton Korobeynikov <anton at korobeynikov.info> Sent: Tuesday, February 25, 2020 12:36 PM To: Tom Honermann <thonerma at synopsys.com> Cc: llvm-dev at lists.llvm.org; Michael Price <mprice at synopsys.com>; Tim Prince <trprince at synopsys.com>; Christopher Lapkowski <lapkow at synopsys.com> Subject: Re: [llvm-dev] Status of the git.llvm.org git repos Hello These repos were popul...

On 29 June 2016 at 16:50, Tom Honermann <Thomas.Honermann at synopsys.com> wrote: > How would you coordinate dependent updates to the sub-modules? We won't. Not now. Maybe later. Right now, doing that means changing how we work and we're trying to make the least number of changes at a time. But this is the most reques...

On 6/29/2016 10:03 AM, Renato Golin via cfe-dev wrote: > Since the umbrella project cannot see the sub-modules' commits without > some form of update, there are two ways to do this: > > P. Per push: Every push (not commit) on all other repositories will > trigger a hook that will hit a URL on our server, telling it to > generate an incremental ID, update some umbrella's

On 02/19/2015 04:28 PM, Renato Golin wrote: > On 19 February 2015 at 19:58, Tom Honermann <thonermann at coverity.com> wrote: >> The effort isn't always so small for us however. It has generally taken us >> about a month to upgrade and vet a new Clang release. The Clang release >> cadence is faster than ours, so timing isn't always great (not a complain...

On 02/18/2015 04:57 PM, Renato Golin wrote: > On 18 February 2015 at 21:45, Tom Honermann <thonermann at coverity.com> wrote: >> Unfortunately, we don't currently have the resources to do so. When we >> upgrade, we upgrade to the most recent release and perform testing on top of >> it. > > One safe way of doing so, and would help us without adding much...

> -----Original Message----- > From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Kai Peter Nacke > via llvm-dev > Sent: Tuesday, June 16, 2020 8:51 AM > To: Corentin <corentin.jabot at gmail.com> > Cc: llvm-dev at lists.llvm.org > Subject: Re: [llvm-dev] RFC: Adding support for the z/OS platform to LLVM and > clang > > > > 2) Add

I was under the impression that the (non-monorepo) separate LLVM and Clang git repos hosted at git.llvm.org would be maintained for a year after the transition to the mono repo. I don't recall where I got that impression from; probably from some of the many emails on the migration topic. I noticed today that updates to these repos ceased on October 22nd of last year following transition to

On 02/18/2015 04:12 PM, Renato Golin wrote: > On 18 February 2015 at 20:59, Tom Honermann <thonermann at coverity.com> wrote: >> My company also does not use ToT. Being able to associate a product with a >> well-known release is *very* important to us. It enables communication with >> our customers. It allows us to determine compatibility between our Clang &gt...

On 6/29/2016 2:00 PM, Renato Golin via llvm-dev wrote: > On 29 June 2016 at 16:50, Tom Honermann <Thomas.Honermann at synopsys.com> wrote: >> How would you coordinate dependent updates to the sub-modules? > We won't. Not now. Maybe later. > > Right now, doing that means changing how we work and we're trying to > make the least number of changes at a time. > &...

On 02/18/2015 03:01 PM, Renato Golin wrote: > So it seems that you're one of the very few people that doesn't use > ToT. Almost everyone else uses it and the progress of LLVM kind of > assume you do. My company also does not use ToT. Being able to associate a product with a well-known release is *very* important to us. It enables communication with our customers. It allows

Hi all, A short summary: Takumi has done 90% of the work here: https://github.com/llvm-project/llvm-project-submodule and I've been talking to GitHub, and here are the answers to my questions: > 1. How will the umbrella project's auto-increment hook work? Since the umbrella project cannot see the sub-modules' commits without some form of update, there are two ways to do this:

> -----Original Message----- > From: cfe-dev [mailto:cfe-dev-bounces at lists.llvm.org] On Behalf Of Renato > Golin via cfe-dev > Sent: Thursday, June 30, 2016 9:49 AM > To: Reid Kleckner > Cc: LLVM Dev; llvm-foundation at lists.llvm.org; Clang Dev; LLDB Dev > Subject: Re: [cfe-dev] [lldb-dev] [llvm-dev] Sequential ID Git hook > > On 30 June 2016 at 17:33, Reid Kleckner

I checked out llvm/trunk today and found that it failed to build successfully on Linux when 'configure' was invoked with '--disable-shared' and CFLAGS included '-static'. The attached patch modifies a few Makefiles to prevent attempts to build shared libraries when ENABLE_SHARED is not set to 1. Apply the patch in the LLVM root directory with 'patch -p1 ...'

On 2/22/2012 7:29 AM, Sevak Sargsyan wrote: > Hi all, > I have problem with debugging clang, gdb does not stop in function > ParseFrontendArgs, the function works because I wrote errs() and I saw > it in command line, > I also wrote __asm__("int $3") in ParseFrontendArgs but it does not help. Are you debugging the correct process? Note that invocations of

Oh, that's what I was afraid of. So there is definetly no way to compile for ARC? If so, should I write ARC.h(.cpp) in lib/Basic/Targets in order to make it work? чт, 27 сент. 2018 г. в 14:47, Tim Northover <t.p.northover at gmail.com>: > Hi, > > On Thu, 27 Sep 2018 at 12:41, Павел Безбородов via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > clang -target

<div class="socmaildefaultfont" dir="ltr" style="font-family:Arial, Helvetica, sans-serif;font-size:9pt" ><div dir="ltr" >Hi all,</div> <div dir="ltr" >I'm very excited to be able to share this with everyone. </div> <div dir="ltr" > </div> <div dir="ltr" >IBM announced this

On 12/9/2011 8:23 AM, Seb wrote: > This thread is not to discuss how relevant this example is. I just would > like to know: > a) If people think that adding an option to disable a specific pass is > useful. Yes, a peer of mine recently wanted such an option to disable individual passes in order to 1) narrow in on a bug in one of them that affected stack back tracing, and 2) provide

On 6/30/2016 5:20 PM, Robinson, Paul via cfe-dev wrote: > We were using tags for a while in our own SVN->git conversion internally. > (git branch is pushed to SVN and the SVN r-number used to create a tag.) > They are convenient for some things, but each tag adds a new (if small) > file to .git/tags and I don't know that it really scales well when you > are talking about