similar to: Why do we have a git tag called "release_35@215010"?

Displaying 20 results from an estimated 400 matches similar to: "Why do we have a git tag called "release_35@215010"?"

2016 Feb 05
2
Why do we have a git tag called "release_35@215010"?
> 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
2011 Oct 06
1
[LLVMdev] svnsync of llvm tree
On 2011-08-29 04:21, Kurt Lidl wrote: > While I agree bootstrapping a new mirror from scratch is time and > resource consuming, this can be largely avoided by making a seed > of the svn tree available. (Basically, I think that looks like > a compressed tar file of the svn repository.) Or, a svnadmin dump > of the repo could be made available for the adventurous. Having the same
2011 Oct 06
0
[LLVMdev] svnsync of llvm tree
Oliver Schneider <gmane at assarbad.net> writes: >>> However, we have official git mirrors of most of the projects on >>> llvm.org, would using them instead of svnsync be an option for you? >> >> Well, if the authoritative source code control system for all the >> llvm projects is svn, I'd just as soon use svn as the tool at my end. > The git
2011 Aug 29
2
[LLVMdev] svnsync of llvm tree
On Wed, Aug 17, 2011 at 01:47:02PM -0700, Benjamin Kramer wrote: > On 17.08.2011, at 11:36, Kurt Lidl <lidl at pix.net> wrote: > > > Why can't I mirror the whole tree? > > The original reason for this limitation was that complete checkouts > put a lot of stress on the server. While I agree bootstrapping a new mirror from scratch is time and resource consuming,
2012 Apr 26
2
[LLVMdev] git branch release_31
Hi Anton, On Thu, Apr 26, 2012 at 4:05 PM, Anton Korobeynikov <anton at korobeynikov.info> wrote: > Sebastian, > >> I just saw that the git branch remotes/origin/release_31 has been created >> for llvm.  Unfortunately it is missing the right context: right now I can only >> see 11 patches in that branch with the last patch having no parent. >> >> Could
2012 Apr 27
0
[LLVMdev] git branch release_31
> In your svn section of llvm/.git/config, you can specify how to map > the svn branches to different name spaces, something like this: > > [svn-remote "svn"] >        [...] >        branches = branches/*:refs/remotes/origin/* >        fetch = branches:refs/remotes/origin > > I would also change "branches = branches/*:refs/remotes/origin/*" > into
2011 Oct 06
0
[LLVMdev] MIPS 32bit code generation
A simulator should be expecting the machine opcodes not macros. LD shouldn't care at all as long as the object format plays well. I would think it would be better to fix the simulator. Jack ________________________________________ From: llvmdev-bounces at cs.uiuc.edu [llvmdev-bounces at cs.uiuc.edu] on behalf of llvmdev-request at cs.uiuc.edu [llvmdev-request at cs.uiuc.edu] Sent: Thursday,
2014 Oct 01
2
[LLVMdev] Issue with incomplete type debug info in recent release_35
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
2015 Jan 07
2
[LLVMdev] Inclusion of iostream affects devirtualization in release_35
Hello, I've stumbled upon the following behavior in branches/release_35 (as of 218689) under ubuntu 14.04 LTS amd64: whenever I include the (system-wise) gnu iostream header, clang++ stops devirtualizing the following code: #if BREAKAGE_ENSUES #include <iostream> #endif struct Base { virtual int foo() const = 0; }; struct A : Base { int a; A(const int a) : a(a) { } int foo() const
2015 Jan 31
1
[LLVMdev] Release branches are missing from the Git mirror for libc++abi
Hi Anton, It seems that some release branches (e.g. release_30, release_35, and release_36) are missing from the Git mirror for libc++abi. May you help to fix the problem? Thanks. Sincerely, Logan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150201/68faf5d4/attachment.html>
2014 Nov 25
3
[LLVMdev] Proposed patches for Clang 3.5.1
> > > > 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
2018 Aug 03
3
[7.0.0 Release] The release branch is open; trunk is now 8.0.0
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
2014 Sep 10
4
[LLVMdev] Policy for applying fixes to released branches?
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
2014 Aug 27
2
[LLVMdev] migrating from autoconf to cmake+ninja
I want to start using cmake+ninja instead of autoconf for configuring and building llvm from svn, but I have no idea how to map my existing list of autoconf flags to cmake. Here's how I run ./configure right now in the top directory: PREFIX=_some_prefix_dir_ \ ../llvm/configure \ --prefix=$PREFIX \ --libdir=$PREFIX/lib/llvm \ --sysconfdir=$PREFIX/etc \ --enable-shared \
2007 May 30
2
[LLVMdev] wrong codegen
hi, the current release_20 branch seems to miscompile the following reduced testcase (not target architecture specific): #define UInt16 unsigned short #define UInt8 unsigned char UInt8 foo(UInt16 a) { return (UInt8)(((a >> 10) & 1) << 1); } it - misleadingly - optimizes the expression to something like (undef & 2). I guess the problem is related to the DAG combiner but I
2010 Feb 15
2
[LLVMdev] Buildbot
Do the buildbots only build debug components? I am seeing lots of this on trunk with release-style builds: [x86_64-off-opt]: Failed with signal(SIGABRT) at line 1 [x86_64-off-opt]: while running: llvm-as < /ptmp/dag/llvm- project.official/llvm/tags/RELEASE_25/test/Transforms/TailDup/basictest2.ll | opt -tailduplicate -disable-output [x86_64-off-opt]: Value still in symbol table! Type =
2008 Jan 23
1
[LLVMdev] compiling release_22 witout bison installed gives broken build
Hi. I had a strange issue today. basically llvm-as refused to do anything, borking out on the simplest of module: ; ModuleID = 'test' @_nothing_works_here = constant i32 42 $ llvm-as test.ll llvm-as: test.ll:1,0: test.ll:1: error: parse error, expecting `GLOBAL' or `CONSTANT' while reading token: '@_nothing_works_here' It turns out that I forgot to install bison before
2014 Nov 26
6
[LLVMdev] Proposed patches for Clang 3.5.1
On Wed, Nov 26, 2014 at 10:15:13AM +0000, Daniel Sanders wrote: > > From: Daniel Sanders > > Sent: 25 November 2014 17:39 > > To: Eric Christopher; Tom Stellard > > Cc: LLVM Developers Mailing List (llvmdev at cs.uiuc.edu) > > Subject: RE: [LLVMdev] Proposed patches for Clang 3.5.1 > > > > > > > > I'd also like to propose the inclusion of
2014 Sep 09
2
[LLVMdev] Can't build against LLVM-3.5 with CMake: CMakeExports.cmake broken?
On 09/09/2014 01:53 PM, Dan Liew wrote: >> It looks like LLVMConfigLibs was created in r112714 for local use in >> Makefile.rules. The only use outside Makefile.rules is now in >> cmake/modules/Makefile. Teaching cmake/modules/Makefile to do >> a direct invocation would be fine with me. > > Okay. Attached is a patch that does this. Does this work okay for you?
2014 Dec 13
2
[LLVMdev] 3.5.1 Testing Phase Begins
On 13 December 2014 at 16:50, Renato Golin <renato.golin at linaro.org> wrote: > Same here... ARMv7 is already up and tested, AArch64 is proving a bit > more complicated due to old libstdc++ on my box. I'm working on it. I'm seeing one error on AArch64's test-suite: SingleSource/UnitTests/Vector/AArch64/aarch64_neon_intrinsics.c:154979:16: warning: implicit declaration of