similar to: [LLVMdev] Release branches are missing from the Git mirror for libc++abi

I.e., I see this when I run `git fetch`: ``` $ git fetch -v llvm.org From http://llvm.org/git/llvm = [up to date] master -> llvm.org/master = [up to date] release_1 -> llvm.org/release_1 = [up to date] release_16 -> llvm.org/release_16 = [up to date] release_20 -> llvm.org/release_20 = [up to date] release_21 -> llvm.org/release_21 = [up to date]

> On 2016-Feb-05, at 15:22, James Y Knight <jyknight at google.com> wrote: > > That usually happens when someone deletes and then recreates an svn branch with the same name, as happened in r215001 and r215011. > It can be deleted now, if anyone wants to. ``` $ git push llvm.org :release_35 at 215010 fatal: unable to access 'http://llvm.org/git/llvm.git/': The requested

Hi Martin, On Fri, 3 Aug 2018 at 14:10, Martin J. O'Riordan <MartinO at theheart.ie> wrote: > $ git branch --list > * master > martino By default "git branch" only lists local branches. "git branch -a" will list all of them, including (for me) "remotes/origin/release_70". If you just type "git checkout release_70" git will

On 12 May 2014 20:20, Logan Chien <tzuhsiang.chien at gmail.com> wrote: > There is a known issue in the code generated by LLVM. > As a workaround, I am adding "-funwind-tables" to compile the unit tests. I thought I had fixed all of them. Do you have a bug number? > BTW, the LLVM revision which I am using is r207501. > It seems that the recent master has come

I downloaded via svn the release_30 and current version code. I am on x86_64 GNU/Linux, I am compiling with gcc 4.4.6 I compiled release_30 with make ENABLE_OPTIMIZED=0 OPTIMIZE_OPTION=-O0 and current release with make In both cases, when I make check-all I get : FAIL: Clang :: Preprocessor/macro_paste_c_block_comment.c (2562 of 9598) ******************** TEST 'Clang ::

Hi Hans, I have attached a unit test which demonstrates a hang/infinite loop with the opt built with release_36 sources. The fixes are already pushed to "master" branch. The revisions r226588 and r226616 should be pushed to release_36 to fix the unit test. --Sumanth G -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi, I don't see the release_36 branch in http://llvm.org/git/llvm.git or in the github mirror https://github.com/llvm-mirror/llvm/branches Is this a mistake, something still to be done, or is it a change from previous releases? -- Quentin -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hello, disclaimer/ Apologies if this is the wrong llvm/clang mailing list; please, direct me to the right one if needed. /disclaimer I've been experiencing issues with incomplete type info when debugging code generated by clang 3.5.0 from the recent release_35 branch. Generally, the problem manifests itself as the inability to examine any std::string parameter to a function, in either gdb

On Mon, Feb 9, 2015 at 9:47 PM, Anton Korobeynikov <anton at korobeynikov.info> wrote: > Hans, > >>> I see a Git branch "release_36", but what has v3.6.0rc2 for a >>> commit-id, can you tags that? >>> No, there are no tags at all @ github. >> >> Anton, is it possible to translate the svn tags to git tags? > In the past we had problems

Hi Simona, these failures are due to the name of the path to LLVM/clang, see below. > /scratch/user/download/release_30/build/Debug/bin/clang -cc1 -internal-isystem > /scratch/user/download/release_30/build/Debug/bin/../lib/clang/3.0/include > /scratch/user/download/release_30/llvm/tools/clang/test/Preprocessor/macro_paste_c_block_comment.c > > > -Eonly 2>&1 | not grep

The 3.6 release is drawing nearer, but the release notes could still use a lot of improvement: LLVM: https://github.com/llvm-mirror/llvm/blob/release_36/docs/ReleaseNotes.rst Clang: https://github.com/llvm-mirror/clang/blob/release_36/docs/ReleaseNotes.rst The good news is that they can be updated all the way up until release. If you have a patch for the release notes, commit it directly to the

Hi, I was wondering what the policy is for applying fixes to released branches. In particular I have fix that would be useful to have in LLVM 3.5. I recently found and fixed a bug [1] in the way CMake files are generated by the Autoconf/Makefile system and fixed this in r217484. I figured it would be more sensible to ask about this in a thread separate from [2] because this is a much more

I think the better solution should be: LLVMContext& C = is->getContext(); Value *values[] = { ConstantInt::getSigned(Type::getInt64Ty(C), *scsr*), MDString::get(C, *"path"*) }; lnstr.setMetadata(*"your_analysis_name"*, MDNode::get(C, values)); So that you can take advantage of the type system of LLVM bitcode, and don't have to cast the integers from/to strings

On 10/15/2011 05:02 AM, Bill Wendling wrote: > The LLVM 3.0 release branch has been tagged. You may now commit patches at your leisure. Could we have a release_30 branch in git tracking the SVN release_30 branch? Thanks, --Edwin

> Could we have a release_30 branch in git tracking the SVN release_30 branch? Added for {llvm,clang,compiler-rt,dragonegg}.git Let me know if I missed something :) -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

Hi Logan, I'm running the tests on libc++abi on ARM and I'm seeing some errors. On your earlier email you said you ran the tests clean, and I was wondering what magic do I need to get the same results. :) I had to change the build and test scripts a little to make it compile on Linux, but nothing radical. I also had to copy (and link) the libc++abi.so files on install/lib and use that

> > > > I'd also like to propose the inclusion of the recent ABI fixes to the Mips > > > > target but I'm not sure this is a good idea. I'm having difficulty sorting out the > > > > dependencies for these at the moment since they seem to depend on some > > > > of Eric Christopher's Subtarget/TargetMachine refactoring. It may also be a

Hi, is it possible to have appropriate tags for the Git repositories @ github? I see a Git branch "release_36", but what has v3.6.0rc2 for a commit-id, can you tags that? No, there are no tags at all @ github. Can you add in your announces a svn-trunk revision next time (for rc3)? Somehow it should be clear what is "rc2". Thanks. Regards, - Sedat -

Hi Anton and JF, Thanks for your review. After reading the source code more carefully, I have come up with a different way fix this issue. We can simply resolve this issue by adding ARMII::MO_PLT flags with MachineInstrBuilder in FastISel pass (without failing back to DAG lowering). The new patch is attached, and the test case is not changed. Sorry for your inconvenience. Please have a

On 11/13/12 12:37 PM, Chris Lattner wrote: > On Nov 13, 2012, at 7:52 AM, John Criswell <criswell at illinois.edu> wrote: > >>> John, it was not my intention to disrupt your work in any way. >>> However, branching for release is a bit of a grey area and I >>> have made a judgment call to branch SAFECode in sync with llvm. >>> This could have been a