similar to: New LLVM git repository conversion prototype

On Fri, Nov 16, 2018 at 4:04 PM NAKAMURA Takumi <geek4civic at gmail.com> wrote: > Hello, David. > > On Sat, Nov 17, 2018 at 7:46 AM David Jones via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi James, >> >> I've started working with the prototype layout in context of Google's >> internal infrastructure. With deep apologies, I

Hi James, I've started working with the prototype layout in context of Google's internal infrastructure. With deep apologies, I have a (very late, I know) pair of requests that have only recently solidified for me. 1. Could you add annotated tags after the cut point of each release? (I think this would probably be easy.) 2. Could you mark branch/tag operations somehow other than a

Thank you , James. But this way needs to determine whether the instruction is a LOAD/STORE ,and if I want to preserve the operations on these variables for further dynamic symbolic execution usage(just like KLEE ,but it's a static analysis ,not dynamic),I had to backtrace instructions ,this may be not very efficient if the operation is very complex! -Jin Huang 2014/1/3 Jin Huang

Well shoot, you beat me to it. :) I've been working on a similar tool but it's not ready yet. Looking forward to trying yours! -David James Y Knight via llvm-dev <llvm-dev at lists.llvm.org> writes: > I'm about to post exactly this tool -- I've been testing it on the > CHERI forks of llvm/clang/lld (lots of history and merges and stuff

You will have to insert callinst to tracing functions immediately after the value is produced, not at the entry points. Giri code has many such examples of how to do this. Thanks, Swarup. ________________________________ From: llvmdev-bounces at cs.uiuc.edu [llvmdev-bounces at cs.uiuc.edu] on behalf of Jin Huang [54jin.huang at gmail.com] Sent: Thursday, January 02, 2014 9:47 PM To: llvmdev at

Hi, all. I feel like we've strayed pretty far from the question originally posed in this thread. One of the pieces of feedback I got before I started this thread was that many people felt that, the last time the question of multiple repos vs. monorepo was discussed, it was interspersed with other topics, making it difficult for some people to weigh in appropriately (or even to be aware that

Hi Jin Huang, The updated Giri code is available at https://github.com/liuml07/giri<https://github.com/liuml07/giri.>. This will give you an idea of how to instrument the program to trace different values. You can modify the code to achieve your goals. -Swarup. ________________________________ From: Criswell, John T Sent: Thursday, January 02, 2014 2:12 PM To: Jin Huang; llvmdev at

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

My expectation was 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

Hello. I'm developing a LLVM based project and I'm using a fork of LLVM and Clang repos from https://github.com/llvm-mirror . The workflow was merging my work with release_XX branches from these repos, so now I have my commits interspersed with upstream ones. I'd be grateful for any advice on how should I move my work towards official git monorepo. I want to preserve my history, of

On Fri, Nov 2, 2018 at 2:11 PM Justin Bogner <mail at justinbogner.com> wrote: > James Y Knight <jyknight at google.com> writes: > > Thanks for writing this up. I think it's a really important point which > > deserves discussion. > > > > Ultimately, I think it is a question as to whether to prioritize the easy > > switchover for existing out of

Thanks for writing this up. I think it's a really important point which deserves discussion. Ultimately, I think it is a question as to whether to prioritize the easy switchover for existing out of tree forks, or to prioritize having the best conversion we can make. I feel very strongly that the latter should be the priority for the official repository conversion, and that, therefore, we

> On Oct 13, 2016, at 11:56 AM, Renato Golin <renato.golin at linaro.org> wrote: > > Hi Duncan, > > I don't understand your concerns. > > First, the choice between sub-modules and mono-repo has been put > forward as the only two choices because people felt that, if we let it > open, we'd have too many different implementation details and we'd >

What's the status here? Can someone keep https://llvm.org/docs/Proposals/GitHubMove.html updated with the current status of things? And once things are usable, probably update https://llvm.org/docs/GettingStarted.html#for-developers-to-work-with-a-git-monorepo as well. On Wed, Oct 24, 2018 at 4:57 AM Jacob Carlborg via lldb-dev < lldb-dev at lists.llvm.org> wrote: > On 2018-10-24

Hello, I was wondering what was the current expected practice for committing patches to LLVM now that the Git monorepo is here. I have commit access to SVN but when I try to land my patched through GitHub I get an error saying "Permission to llvm/llvm-project.git denied". Depending on the answer, the documentation might need to be slightly clarified: the getting started documents for

It'd be nice to know what about our repository is breaking it. Do they have any idea what that is? For example -- I think that we probably will want to archive+discard many of the random branches and tags currently in the repository. If the large number of branches and tags is breaking it, then maybe it just starts working after we do so. On Thu, Nov 8, 2018 at 3:53 PM Anton Korobeynikov

Folks, I'm at a loss trying to add Compiler-RT to an LLVM build, even after checking out the instructions at http://compiler-rt.llvm.org, so I'd appreciate your help. I've tried adding the CMake options LLVM_ENABLE_PROJECTS, LLVM_BUILD_EXTERNAL_COMPILER_RT, LLVM_EXTERNAL_COMPILER_RT_SOURCE_DIR, CLANG_DEFAULT_RTLIB. All to no avail. FWIW, I'm building for the targets

Mehdi AMINI <joker.eph at gmail.com> writes: > > If you want a monorepo view for all of your branches' histories > > too it's more involved, but I'm not sure anyone really needs > > that. In any case, even if someone does want that the nature of > > the zipper approach means it could be done later > > non-destructively. >

On 12/12/2018 08:53 PM, James Y Knight via llvm-dev wrote: > On Fri, Nov 16, 2018 at 7:40 PM Jeremy Lakeman <Jeremy.Lakeman at gmail.com <mailto:Jeremy.Lakeman at gmail.com>> wrote: > > Semantic versioning would recommend "v8.0.0-dev", "v8.0.0-rc1" etc. The hyphen indicating that this is a pre-release version coming before "v8.0.0" > >

Here's another question about the current status of this. It's close to two months after the official monorepo was supposed to be published. Can someone give an update? Is this on hold indefinitely? Are there concrete issues that people are working on and this will happen as soon as those are resolved? At the least, I'm assuming the "SVN will shut down 1 year from now"