search for: release_21

...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] release_22 -> llvm.org/release_22 = [up to date] release_23 -> llvm.org/release_23 = [up to date] release_24 -> llvm.org/release_24 = [up to date] release_25 -> llvm.org/release_25 = [up to date] release_26 -> llv...

...se svn as the tool at my end. > The git mirrors only contain what's in trunk in the SVN repos. I think it contains branches of several previous releases: $ git branch -r llvm-upstream/master llvm-upstream/release_1 llvm-upstream/release_16 llvm-upstream/release_20 llvm-upstream/release_21 llvm-upstream/release_22 llvm-upstream/release_23 llvm-upstream/release_24 llvm-upstream/release_25 llvm-upstream/release_26 llvm-upstream/release_27 llvm-upstream/release_28 llvm-upstream/release_29 llvm-upstream/svn-tags/RELEASE_1 llvm-upstream/svn-tags/RELEASE_20 llvm-upstr...

...m 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] release_22 -> llvm.org/release_22 > = [up to date] release_23 -> llvm.org/release_23 > = [up to date] release_24 -> llvm.org/release_24 > = [up to date] release_25 -> llvm.org/release_25 > = [up to date]...

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

...dule const&, llvm::VerifierFailureAction, std::basic_string<char, std::char_traits<char>, std::allocator<char> >*)' collect2: ld returned 1 exit status make: *** [play] Error 1 I'm not sure what else I can do beyond 'all', though. I've built LLVM from the RELEASE_21 tag, with object root separate from source root, using '../llvm/configure --prefix=/home/ben; make -j2; make install'. I didn't see any errors during the build. Am I missing something incredibly obvious here? Thanks! Ben Morse

...lso change "branches = branches/*:refs/remotes/origin/*" > into something like "branches = branches/*:refs/remotes/branches/*" This is exactly what was done on llvm.org. Here is an example fron clang.git: fetch = trunk:refs/heads/master tags = tags/{RELEASE_20,RELEASE_21,RELEASE_22,RELEASE_23,RELEASE_24,RELEASE_25,RELEASE_26,RELEASE_27,RELEASE_28,RELEASE_29,RELEASE_30,RELEASE_31}:refs/heads/svn-tags/* branches = branches/{release_20,release_21,release_22,release_23,release_24,release_25,release_26,release_27,release_28,release_29,release_30,release_31}:refs...

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

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,

Hello, Reid. > Fortunately, with SVN, making such a change isn't hard and its tracked > in the commits. Anyone object or have other ideas in this realm? I'm also confused. At one hand, proposed layout (with BTT in the top) seems to be "unnatural", when we will create new tags/branches. In theory, each module can have its own version, thus if the want to "tag"

...%retval4 = load i32* %retval ; <i32> [#uses=1] ret i32 %retval4 } declare i32 @printf(i8* noalias , ...) ------------------------------------------ which gives me the following when compiled and executed: hello world: 2.000000 / 0.600000 i've configured llvm-gcc (RELEASE_21) as follows: $ llvm-arm-gcc -v Using built-in specs. Target: arm-softfloat-linux-gnu Configured with: /nfs/a5/ebner/dev/official/llvm-gcc/configure --prefix=/nfstmp/util/arm-softfloat-linux-gnu/ --program-prefix=llvm-arm- --enable-llvm=/nfs/a5/ebner/dev/cross/arm-softfloat-linux/llvm --enable-c...

...use svn as the tool at my end. > The git mirrors only contain what's in trunk in the SVN repos. I think it contains branches of several previous releases: $ git branch -r llvm-upstream/master llvm-upstream/release_1 llvm-upstream/release_16 llvm-upstream/release_20 llvm-upstream/release_21 llvm-upstream/release_22 llvm-upstream/release_23 llvm-upstream/release_24 llvm-upstream/release_25 llvm-upstream/release_26 llvm-upstream/release_27 llvm-upstream/release_28 llvm-upstream/release_29 llvm-upstream/svn-tags/RELEASE_1 llvm-upstream/svn-tags/RELEASE_20 llvm-upstr...

On Oct 19, 2007, at 7:23 AM, Dietmar Ebner wrote: > hi, > > i'm trying to make some experiments with the ARM backend (llvm 2.1) > and > therefore built an arm-softfloat-linux-gnu toolchain on x86_64 linux. > > however, the llvm-gcc frontend seems to cause troubles with single > precision floating point values, i.e., they are not converted > correctly > to the

...[#uses=1] > ret i32 %retval4 > } > > declare i32 @printf(i8* noalias , ...) > ------------------------------------------ > > which gives me the following when compiled and executed: > hello world: 2.000000 / 0.600000 > > > i've configured llvm-gcc (RELEASE_21) as follows: > $ llvm-arm-gcc -v > Using built-in specs. > Target: arm-softfloat-linux-gnu > Configured with: /nfs/a5/ebner/dev/official/llvm-gcc/configure > --prefix=/nfstmp/util/arm-softfloat-linux-gnu/ > --program-prefix=llvm-arm- > --enable-llvm=/nfs/a5/ebner/dev/cross/a...

hi, i'm trying to make some experiments with the ARM backend (llvm 2.1) and therefore built an arm-softfloat-linux-gnu toolchain on x86_64 linux. however, the llvm-gcc frontend seems to cause troubles with single precision floating point values, i.e., they are not converted correctly to the particular target format (double precision works as expected). it seems the problem is related to

...th access to the external tests, those should be included as well. Note that this testing regimen requires validators to build and test llvm-gcc as well as the native LLVM tools. The tags themselves should live under the tags tree. One possible tagging scheme looks like this: trunk tags ... RELEASE_21 RELEASE_22 RELEASE_23 validated ALL development_24 r54582 X86 development_24 r53215 r54100 r54582 X86-64 (? maybe covered by x86) ... PowerPC ... Alpha ... Sparc ... Mips ... ARM .....