search for: release_360

...e problems? If you cannot solve them by yourself, did/can you ask on Git mailing-list? Why are there no more "svn-tags/RELEASE_NN" tags on GitHub-mirrors? The last I see is "svn-tags/RELEASE_32". So, this seems to have worked someday. So I see a "final" tag for "RELEASE_360" in SVN. Can you please do generate "svn-tags/RELEASE_360" tags for Git accordingly (for llvm | cfe | compiler-rt | ...)? If you cannot do, which are the last git-sha1-commit-ids for llvm | cfe | compiler-rt (svn-revs see below)? In conclusion: Why are people using Git disadvantaged...

...code through llc: ; ModuleID = '.\t.bc' target datalayout = "e-m:w-p:32:32-i64:64-f80:32-n8:16:32-S32" target triple = "i686-pc-windows-gnu" @_ZN3Foo11ZeroAndZeroE = global [2 x i32] [i32 0, i32 0], align 4 !llvm.ident = !{!0} !0 = !{!"clang version 3.6.0 (tags/RELEASE_360/final)"} It turns into this: ; ModuleID = '.\t.ll' target datalayout = "e-m:w-p:32:32-i64:64-f80:32-n8:16:32-S32" target triple = "i686-pc-windows-gnu" @_ZN3Foo11ZeroAndZeroE = global [2 x i32] zeroinitializer, align 4 !llvm.ident = !{!0} !0 = !{!"clang ve...

> In conclusion: > Why are people using Git disadvantaged? Short answer: because of git-svn and differences between what is a tag in git and svn. Long answer: git-svn never created proper git tags. Instead, it converted svn tags to branches (because technically branches and tags are same in svn). These branches were orphan and not usable for bunch of things (I believe Takumi can provide a

...The issue still remains in mesa v10.4.4. So, this is a field test to see if LLVM/Clang v3.6.0rc2 fits my needs. I see the following build-error... ... make[4]: Entering directory `/home/wearefam/src/mesa/mesa-git/src/mapi' CC shared_glapi_libglapi_la-entry.lo clang version 3.6.0 (tags/RELEASE_360/rc2) Target: x86_64-unknown-linux-gnu Thread model: posix Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6.4 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9 Found candidate GCC installation: /...

...test to see if LLVM/Clang v3.6.0rc2 fits my needs. >> >> I see the following build-error... >> ... >> >> make[4]: Entering directory `/home/wearefam/src/mesa/mesa-git/src/mapi' >> CC shared_glapi_libglapi_la-entry.lo >> clang version 3.6.0 (tags/RELEASE_360/rc2) >> Target: x86_64-unknown-linux-gnu >> Thread model: posix >> Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6 >> Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6.4 >> Found candidate GCC installation: /usr/lib/gcc/x86_64-linu...

...>> test.c >> >> bash-4.1$ ./a.out >> >> bash-4.1$ llvm-cov gcov test.c >> >> Unexpected end of memory buffer: 386832052. >> >> Invalid .gcno File! >> >> >> >> bash-4.1$ clang -v >> >> clang version 3.6.0 (tags/RELEASE_360/final) >> >> Target: x86_64-unknown-linux-gnu >> >> Thread model: posix >> >> >> >> Thank you >> >> ~Umesh >> >> >> >> On Tue, Apr 28, 2015 at 8:32 PM, Justin Bogner >> >> <justin at justinbogner.com&...

...add.ll" .globl fadd .align 2 .type fadd,%function fadd: @ @fadd .fnstart .Leh_func_begin0: @ BB#0: push {lr} bl __addsf3 pop {lr} mov pc, lr .Ltmp0: .size fadd, .Ltmp0-fadd .Leh_func_end0: .fnend .ident "Ubuntu clang version 3.6.0-2ubuntu1~trusty1 (tags/RELEASE_360/final) (based on LLVM 3.6.0)" One can clearly see a bl __addsf3 instruction. However for some reason my target produces a lf.add.s (which is a floating point add) instead of branching to a library code. Clearly I'm missing something, but I can't figure out what exactly. Would anyone c...

Hi All, We trying to use clang+llvm to generate the gcc coverage format as clang version 3.6.0 $clang --coverage -Xclang -coverage-cfg-checksum -Xclang -coverage-no-function-names-in-data -Xclang -coverage-version='407*' test.c $a.out $llvm-cov gcov test.gcda Unexpected version: *704. Invalid .gcno File! Debugging the above cause ,But any hints from experts here ,will help a lot

...>> bash-4.1$ ./a.out >>> >> bash-4.1$ llvm-cov gcov test.c >>> >> Unexpected end of memory buffer: 386832052. >>> >> Invalid .gcno File! >>> >> >>> >> bash-4.1$ clang -v >>> >> clang version 3.6.0 (tags/RELEASE_360/final) >>> >> Target: x86_64-unknown-linux-gnu >>> >> Thread model: posix >>> >> >>> >> Thank you >>> >> ~Umesh >>> >> >>> >> On Tue, Apr 28, 2015 at 8:32 PM, Justin Bogner >>> >>...

...gt; "stack-protector-buffer-size"="8" "unsafe-fp-math"="false" > "use-soft-float"="false" } > attributes #1 = { nounwind } > > !llvm.ident = !{!0} > > !0 = !{!"Ubuntu clang version 3.6.0-2ubuntu1~trusty1 > (tags/RELEASE_360/final) (based on LLVM 3.6.0)"} > > On Fri, Nov 25, 2016 at 12:52 PM, Naveed Ul Mustafa via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > >> Hi All, >> >> I need your guidance about a custom attribute. I have defined one >> for variables. It is ac...

...d test to see if LLVM/Clang v3.6.0rc2 fits my needs. >> >> I see the following build-error... >> ... >> >> make[4]: Entering directory `/home/wearefam/src/mesa/mesa-git/src/mapi' >> CC shared_glapi_libglapi_la-entry.lo >> clang version 3.6.0 (tags/RELEASE_360/rc2) >> Target: x86_64-unknown-linux-gnu >> Thread model: posix >> Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6 >> Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6.4 >> Found candidate GCC installation: /usr/lib/gcc/x86_64-linu...

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 All, I need your guidance about a custom attribute. I have defined one for variables. It is accepted in the source code (without any warnings from clang), for example in following snippet. #define NEWATTR __attribute__((moviAttr(1))) int main() { NEWATTR volatile unsigned int a = 5; volatile unsigned int *p; p = &a; return (a+*p); } and actually when I Dump the declaration, after

...ot;unsafe-fp-math"="false" >> > "use-soft-float"="false" } >> > attributes #1 = { nounwind } >> > >> > !llvm.ident = !{!0} >> > >> > !0 = !{!"Ubuntu clang version 3.6.0-2ubuntu1~trusty1 >> > (tags/RELEASE_360/final) (based on LLVM 3.6.0)"} >> > >> > On Fri, Nov 25, 2016 at 12:52 PM, Naveed Ul Mustafa via llvm-dev >> > <llvm-dev at lists.llvm.org> wrote: >> > >> >> Hi All, >> >> >> >> I need your guidance about a custom at...

...net.h:22: In file included from /usr/include/netinet/in.h:23: In file included from /usr/include/sys/socket.h:38: /usr/include/bits/socket.h:345:10: fatal error: 'asm/socket.h' file not found #include <asm/socket.h> clang++-3.6 -E -x c++ - -v < /dev/null clang version 3.6.0 (tags/RELEASE_360/final) Target: x86_64-unknown-linux-gnu Thread model: posix Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.4 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9 Found candidate GCC installation:...

Hi, I've been working on a Blackfin backend (llvm-3.6.0) based on the previous one that was removed in llvm-3.1. llc generates codes like this: 29 p1 = r2; 30 r5 = [p1]; 31 p1 = r2; 32 r6 = [p1 + 4]; 33 r5 = r6 + r5; 34 r6 = [p0 + -4]; 35 r5 *= r6; 36 p1 = r2; 37 r6 = [p1 + 8]; 38 p1 = r2; p1 and r2 are in different register classes. A p*

The raspberry Pi2 is an armv7a chip (Cortex-A7), the first stage builds fine with the native g++ (if not a little slowly at 10+ hours), but it crashes at some point with this command line: Program arguments: /home/ben/development/llvm/3.6.0/rc2/Phase2/Release/llvmCore-3.6.0-rc2.install/bin/clang -cc1 -triple armv7-unknown-linux-gnueabihf -emit-obj -disable-free -disable-llvm-verifier

On 11 Feb 2015, at 11:16, Sedat Dilek <sedat.dilek at gmail.com> wrote: > > On Wed, Feb 11, 2015 at 12:09 AM, Emil Velikov <emil.l.velikov at gmail.com> wrote: >> On 10/02/15 13:17, Dimitry Andric wrote: >>> On 09 Feb 2015, at 18:52, Sedat Dilek <sedat.dilek at gmail.com> wrote: >>>> >>>> On Mon, Feb 9, 2015 at 6:44 PM, Emil Velikov