similar to: [LLVMdev] [Announcement] LLVM 3.4 Has Branched!

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: > > * Nov 19 - Nov 24: This is Phase I testing. During this time,

> 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

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

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>

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

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

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

Hi, I would like to begin the 3.4.2 release process for LLVM. There have been two issues identified in 3.4.1, which there is interest in having fixed in a 3.4.x release: 1. Build failure with gcc 4.9 (This is not a regression, 3.4 also fails to build with gcc 4.9). 2. Accidental change of libLLVM's DT_SONAME from libLLVM-3.4 libLLVM-3.4.1.so I will also accept any other bug-fixes that

The LLVM 3.4 branches are now frozen. We’re only accepting major, super horrible bug fixes from now on. The testers are going to do a third phase of testing, but it’s mostly to verify that we don’t have any major problems left. Share and enjoy! -bw

No regressions this time. Fedora and OpenSUSE binaries uploaded. On Sat, Apr 26, 2014 at 12:47 PM, Tom Stellard <tom at stellard.net> wrote: > Dropping llvmdev and cc'ing testers directly, so this email > won't be held in moderation for having too many recipients. > > I like having tester discussions on list, so it would probably > be best to reply to the original

Bill, et al., There are still a number of open bug reports demonstrating miscompiles on x86 with small/reduced test cases. I propose that we either delay this release until these have been fixed, or plan on a point release in the near future. I recommend that we put out another two release candidates, one at the end of this week, and one after another two weeks or so, to allow for these

rc1 did not exhibit this mismatch. A repeat of the rc2 build repeated the mismatch. I diff'd the disassembly between phase 2 and phase 3 and the difference is the same on both builds. The difference follows: # diff x86isel_p{2,3}.s 2c2 < Phase2/Release/llvmCore-8.0.0-rc2.obj/lib/Target/X86/CMakeFiles/LLVMX86CodeGen.dir/X86ISelLowering.cpp.o: file format elf64-x86-64 --- >

On Dec 15, 2013, at 7:10 PM, C. Bergström <cbergstrom at pathscale.com> wrote: > On 12/16/13 09:57 AM, Bill Wendling wrote: >> On Dec 12, 2013, at 11:08 PM, C. Bergström <cbergstrom at pathscale.com> wrote: >> >>> On 12/13/13 01:58 PM, Bill Wendling wrote: >>>> That’s a long laundry list of bugs there. It would be great to have them fixed, but the

Daniel, Note the openmp library only has cmake build machinery preventing autoconf-based builds. Jack On Tue, Jun 23, 2015 at 10:18 AM, Daniel Sanders <Daniel.Sanders at imgtec.com> wrote: > Hi, > > I'll do Mips as usual. Are we going to do an autoconf-based build for LLVM 3.7? If so, I might try Mips64 packages too. > >> -----Original

The LLVM 2.8 branches have been created! We will be conducting several rounds of testing of this branch during September. See http://llvm.org/ for a tentative schedule. What this means for you As I mentioned in a previous e-mail, the branch is still open for code submissions. However there are a few rules that we need to adhere to: No new features are allowed, no matter how trivial they may be.

Hi, I've just tagged the 4.0.1 -rc1 release. Testers can start testing and uploading the binaries. If you still have bug fixes you want to get into the 4.0.1 release, you have until May 22 to submit merge requests. -Tom

i Don't know if others have raised this issue, but I'm seeing *a lot* of llvm-dev emails and cfe emails landing in my spam folder in gmail. Are other people having this problem? On Mon, May 12, 2014 at 11:57 AM, Tom Stellard <tom at stellard.net> wrote: > Hi, > > I would like to begin the 3.4.2 release process for LLVM. There have > been two issues identified in

Anton, please add release_32 also in; clang-tools-extra compiler-rt dragonegg libcxxabi lldb They have release_32 in svn. I don't know they might be released, though. And, could you suppress generating refs/heads/svn-tags and prune them for now? I am sure that orphan branches will stress the llvm.org server to begin git-pack-ing whole tree. ...Takumi 2012/11/15 Anton Korobeynikov

On Tue, Apr 08, 2014 at 04:08:13PM +0400, Robert Khasanov wrote: > Hi Reid, > > Would you approve your patches r203146 and r202774 to be backported to > 3.4.1? They fix stability issues in x86 asm. > Hi Robert, I was able to merge r203146, but it used a c++11 feature: std::string::back() which I replaced with std::string::at(std::string::size() - 1). r202774 was not merged,

Should be there On Fri, Nov 16, 2012 at 3:00 PM, NAKAMURA Takumi <geek4civic at gmail.com> wrote: > Anton, please add release_32 also in; > > clang-tools-extra > compiler-rt > dragonegg > libcxxabi > lldb > > They have release_32 in svn. I don't know they might be released, though. > > And, could you suppress generating refs/heads/svn-tags and prune them