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
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
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 13 December 2013 05:24, 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 >Even if they take a long time to fix. What is the harm in adding a test case for each one into the release 3.4 now? It sounds to me that they are unlikely to be marked as "won't fix". They will then come up as tests that fail and can be listed as "Known bugs" in the release notes. Although there does not appear to be a "Known bugs" list in the release notes at present. Someone might even be able to use them to make an "automated compare" that can compare them with various large projects and be able to obtain an answer as to whether the project will compile correctly or not with clang/llvm. James