That’s a long laundry list of bugs there. It would be great to have them fixed, but the reality of the situation is that they won’t be fixed for weeks or more, if at all. And with Christmas coming up, it makes things even worse. There are a few days before Phase III starts to have some progress on them. But if they don’t make it, then we’ll have to release without them. -bw On Dec 12, 2013, at 9:24 PM, Hal Finkel <hfinkel at anl.gov> wrote:> 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 outstanding issues to be resolved. > > Specifically, I think that these issues should be resolved prior to the release of 3.4: > > PR18068 [BasicAA] > PR18067 [GVN] > PR16431 (multiple; I suspect covered by the previous two) > PR17638 [IndVarSimplify] > PR18223 [IndVarSimplify] > PR17473 [LSR] > PR18165 [LSR] > PR16729 [Loop Vectorizer] > PR17288 [Loop Vectorizer] > PR18102 [x86 backend or CodeGen] > PR18000 [x86 backend or CodeGen] > PR17504 [x86 backend or CodeGen] > PR17794 > PR17073 > PR16108 > > PR18042 [LCSSA] (This hits an assert, but may miscompile with NDEBUG) > > Of course, the same underlying bug may be causing more than one of these, and at least some of these are already being worked on. Thoughts? > > Thanks again, > Hal > > ----- Original Message ----- >> From: "Bill Wendling" <isanbard at gmail.com> >> To: "cfe-dev at cs.uiuc.edu Developers" <cfe-dev at cs.uiuc.edu>, "<llvmdev at cs.uiuc.edu> Mailing List" >> <llvmdev at cs.uiuc.edu> >> Sent: Thursday, December 12, 2013 1:14:46 AM >> Subject: [cfe-dev] LLVM 3.4 Branch Freeze >> >> 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 >> >> >> _______________________________________________ >> cfe-dev mailing list >> cfe-dev at cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev >> > > -- > Hal Finkel > Assistant Computational Scientist > Leadership Computing Facility > Argonne National Laboratory
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 reality of the situation is that they won’t be fixed for weeks or more, if at all. And with Christmas coming up, it makes things even worse. There are a few days before Phase III starts to have some progress on them. But if they don’t make it, then we’ll have to release without them.How is the release schedule and blockers decided - is there a policy? As an open source project it seems sorta weird (to me) that rushing a release is more important than "getting it right" - granted if it's unlikely any fix date I can totally see your point.. --------- (bw - You do an awesome job of being release manager and please don't take this as a critique - just curious)
The usual procedure is to make time-based releases. So - "release trunk and make sure it's stable enough" plus - fix any outstanding regressions. There is some text wrt this: http://llvm.org/docs/HowToReleaseLLVM.html#release-qualification-criteria On Fri, Dec 13, 2013 at 11:08 AM, "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 reality of the situation is that they won’t be fixed for >> weeks or more, if at all. And with Christmas coming up, it makes things even >> worse. There are a few days before Phase III starts to have some progress on >> them. But if they don’t make it, then we’ll have to release without them. > > How is the release schedule and blockers decided - is there a policy? As an > open source project it seems sorta weird (to me) that rushing a release is > more important than "getting it right" - granted if it's unlikely any fix > date I can totally see your point.. > --------- > (bw - You do an awesome job of being release manager and please don't take > this as a critique - just curious) > > _______________________________________________ > cfe-dev mailing list > cfe-dev at cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev-- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University
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 reality of the situation is that they won’t be fixed for weeks or more, if at all. And with Christmas coming up, it makes things even worse. There are a few days before Phase III starts to have some progress on them. But if they don’t make it, then we’ll have to release without them. > How is the release schedule and blockers decided - is there a policy? As an open source project it seems sorta weird (to me) that rushing a release is more important than "getting it right" - granted if it's unlikely any fix date I can totally see your point..Releasing software is more of an art than a science. Any software release has bugs (not just our project, any project). The question to ask is how severe are those bugs? The balance between the severity and how many people are (potentially) impacted by it. Then you should keep in mind that we have a 6-month release cycle. So any bugs that aren’t fixed now will hopefully be fixed by then. If I wait for these bugs to be fixed, we won’t be releasing until late January. And that’s really not acceptable. For those who actively use LLVM as a library, they are encouraged to keep current with the main trunk. For those who use the official release, they should be made aware of any potential major bugs they may come across. There is evidence to suggest that these (admittedly severe) bugs, some of which have been in the tree for several releases, aren’t affecting many people at the moment. I would love to have them fixed. But it’s not looking feasible at this time. -bw