search for: release_34

I think we have located the revision which fixes this regression: r206094 (or commit 6bb00df in llvm-mirror on GitHub). I have attached a patch which can be applied to the current release_34 branch (tested against the release_34 branch in llvm-mirror). With this patch the attached reg-alloc-test.ll file doesn't fail with the "LLVM ERROR: ran out of registers during register allocation" error any longer. I haven't run any llvm tests to make sure this patch doesn't...

...ate] release_29 -> llvm.org/release_29 = [up to date] release_30 -> llvm.org/release_30 = [up to date] release_31 -> llvm.org/release_31 = [up to date] release_32 -> llvm.org/release_32 = [up to date] release_33 -> llvm.org/release_33 = [up to date] release_34 -> llvm.org/release_34 = [up to date] release_35 -> llvm.org/release_35 = [up to date] release_35 at 215010 -> llvm.org/release_35 at 215010 = [up to date] release_36 -> llvm.org/release_36 = [up to date] release_37 -> llvm.org/release_37 = [up to date]...

I've just read about the 3.4.1 point release, but there seems to be no way to track these in the Git archives, no tags, no branches. Am I missing something? Bas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140512/295256a1/attachment.html>

...; llvm.org/release_29 > = [up to date] release_30 -> llvm.org/release_30 > = [up to date] release_31 -> llvm.org/release_31 > = [up to date] release_32 -> llvm.org/release_32 > = [up to date] release_33 -> llvm.org/release_33 > = [up to date] release_34 -> llvm.org/release_34 > = [up to date] release_35 -> llvm.org/release_35 > = [up to date] release_35 at 215010 -> llvm.org/release_35 at 215010 > = [up to date] release_36 -> llvm.org/release_36 > = [up to date] release_37 -> llvm.org/release_37 &...

...> Evan > > On Jun 1, 2014, at 1:45 PM, Niklas Therning <niklas at therning.org> wrote: > >> I think we have located the revision which fixes this regression: r206094 (or commit 6bb00df in llvm-mirror on GitHub). I have attached a patch which can be applied to the current release_34 branch (tested against the release_34 branch in llvm-mirror). With this patch the attached reg-alloc-test.ll file doesn't fail with the "LLVM ERROR: ran out of registers during register allocation" error any longer. I haven't run any llvm tests to make sure this patch doesn't...

...de/llvm/ADT/SmallVector.h:17: In file included from /tmp/llvm/include/llvm/Support/AlignOf.h:19: /usr/lib64/[...]/c++/4.9.0/cstddef:51:11: error: no member named 'max_align_t' in the global namespace using ::max_align_t; ~~^ 1 error generated. As the fixes got merged to the release_34 branch, I went to check the local configure options and noticed I was passing --enable-cxx11. If I omit that, there's no max_align_t error. I don't remember when I added that, but it used to build prior to gcc 4.9. Just so I understand, is that flag meant to be enabled (and known to work) w...

> Seems release_34 is orphan in llvm.git and clang.git. Could you tweak them? They will be created as soon as there will be commits to them. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

Although release_34(s) Exist, They cannot share root. Could you recreate them manually? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131120/c5d02f3d/attachment.html>

On 29 December 2015 at 08:08, Erik de Castro Lopo <mle+la at mega-nerd.com> wrote: > I would suggest: > > #if SIZEOF_VOIDP == 8 I believe this is not portable. At least on my machine ("4.2.1 Compatible FreeBSD Clang 3.4.1 (tags/RELEASE_34/dot1-final 208032)") it's not defined. Probably this one comes closest: #define __SIZEOF_POINTER__ 8 Riggs

Hi Tom, When running the test script, I got an error message: $ ./test-release.sh -no-64bit -release 3.4.2 -rc 1 -triple armv7a-linux-gnueabihf -j2 # Validating llvm SVN URL llvm 3.4.2 release candidate rc1 doesn't exist! Do I need to get another test-release.sh script? This is the one from release_34 branch we used to release 3.4.1. cheers, --renato On 16 May 2014 22:55, Tom Stellard <tom at stellard.net> wrote: > Hi, > > I have tagged 3.4.2 RC1 in SVN, so testers can begin testing. We > can always use more testers, so if you are interested in helping let me know. > >...

...anager.cpp:312:14: error: request for member ‘getValue’ in ‘fe’, > >which is of non-class type ‘int’ > >if (fe.getValue() == StaleFileEntry) { > >^ Are you sure this is the 3.4.1 source? This doesn't seem to match what is in SVN: https://llvm.org/viewvc/llvm-project/cfe/tags/RELEASE_34/dot1-final/lib/Basic/FileManager.cpp?revision=208032&view=markup -Tom > > solved by adding -std=c++11 to Makefile.config > > > Second one: > > Compilation of "SmallPtrSet.cpp" seems to be broken ... > Solved by removing the conditional compile by > &g...

Hello, A strange problem appears when upgrading from release_34 to testing. Some transformations to bitcode files cause registered global_ctors to not be called. Here's an example (I've also attached the complete example and pasted it below): This works: clang -fsanitize=address -flto -c -o sum.o sum.c clang -fsanitize=address -o sum sum.o T...

Hi, I have just tagged the first release candidate for the 3.4.1 release, so testers may begin testing. Please refer to http://llvm.org/docs/ReleaseProcess.html for information on how to validate a release. If you have any questions or need something clarified, just email the list. For the 3.4.1 release we want to compare test results against 3.4-final. I have added support to the

...oca i32, align 4 store i32 0, i32* %1 store i32 0, i32* %i, align 4 br label %2 ; <label>:2 ; preds = %0 %3 = load i32* %i, align 4 ret i32 %3 } --------------------------------------------------- % clang --version clang version 3.4 (branches/release_34) Target: x86_64-unknown-linux-gnu Thread model: posix % clang -O0 -emit-llvm -mllvm -debug-pass=Structure -S -c -o /dev/stdout main.c Thanks for you help Benjamin Rouxel

On 19/05/2014 00:07, Anton Korobeynikov wrote: > The branch should already be there, because we mirror release_34 branch. > > We stopped to make tags ~ 2 releases ago, because git svn created > orphaned ones (mostly due to our directory layout - we do not "tag" a > particular commit, instead, we're creating separate dirs, etc.). Just to say, thanks for maintaining the git mirror! Th...

Anton, Seems release_34 is orphan in llvm.git and clang.git. Could you tweak them? 2013/11/19 Bill Wendling <isanbard at gmail.com>: > We have officially branched for the LLVM 3.4 release!! > > This means that we are now in the middle of a feature freeze. Here’s what will happen over the next several weeks...

In particular, by now they are alive. On Wed, Nov 20, 2013 at 8:34 AM, Anton Korobeynikov <anton at korobeynikov.info> wrote: >> Seems release_34 is orphan in llvm.git and clang.git. Could you tweak them? > They will be created as soon as there will be commits to them. > > -- > With best regards, Anton Korobeynikov > Faculty of Mathematics and Mechanics, Saint Petersburg State University -- With best regards, Anton Korobey...

Should be there On Wed, Nov 20, 2013 at 8:51 AM, NAKAMURA Takumi <geek4civic at gmail.com> wrote: > Although release_34(s) Exist, > They cannot share root. > > Could you recreate them manually? -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

On 12 May 2014 10:29, "C. Bergström" <cbergstrom at pathscale.com> wrote: > I suspect 3.4.1 is based off > https://github.com/llvm-mirror/clang/tree/release_34 > > (llvm probably has something similar I suppose?) This is correct. Though, I don't know if anyone tagged 3.4.1 on that branch, but I suspect what was released is the HEAD of that branch. Tom would know better. If we're doing a 3.4.2 (as was mentioned earlier), we might have to t...

...sr/lib64/[...]/c++/4.9.0/cstddef:51:11: error: >> no member named 'max_align_t' in the global namespace >> using ::max_align_t; >> ~~^ >> 1 error generated. >> > Is this trunk or the 3.4 branch? > >> As the fixes got merged to the release_34 branch, I went to check the >> local configure options and noticed I was passing --enable-cxx11. If I >> omit that, there's no max_align_t error. I don't remember when I added >> that, but it used to build prior to gcc 4.9. Just so I understand, is >> that flag meant...