<br><div id="origbody">> On 9 November 2015 at 09:04, via llvm-dev <llvm-dev@lists.llvm.org> wrote:<br>> > After searching the whole project, I only find about ~10000 cases from<br>> > "llvm/test" for each commit, and a separate testsuit wrote with high level<br>> > language(i.e. C/C++) to verify the quality and performance. As a general<br>> > Backend, you know, it must be strong enough to cope with all the IR<br>> > generated by Frontend. I cannot believe what I see. Did I miss something ?<br>> Hi,<br>> You're missing all the Clang, compiler-rt, libc++ tests on their own<br>> repositories. That'll add a few more tens of thousands of tests into<br>> the bundle. But that's just the regression / base validation, the<br>> release has a second stage which is less visible than, I believe, for<br>> GCC. We also run the test-suite and benchmarks on trunk validation,<br>> which is something I believe GCC doesn't do, so releases have a lot<br>> less bugs than GCC to begin with. GCC focus on fixing all bugs at<br>> release time, while LLVM focus on fixing them as they happen, which is<br><p>> much easier and more stable for all developers.</p><p><br></p><p>Yes, there are many test cases that we could leverage as LLVM is widely used. However, I am not sure if these cases are part of the release process,</p><p>as they are not part of this project. Is it that, when LLVM is going to release, we must pass all the regression tests and test-suit to make sure that, the basic functionality and performance is good. Then, release it. Clang/rt and other project would use the new LLVM and report bugs to us if have issues?</p><p><br></p><p>The regression test and test-suit is our release criteria, and people would do more tests for us from other projects. Is it right?</p><p><br></p>> > Further, I notice that, under llvm project repo, there is also a clang-tests<br>> > that using gcc test<br>> > suits(http://llvm.org/svn/llvm-project/clang-tests/trunk/gcc-4_2-testsuite/).<br>> > Is that test suit used by llvm to guarantee the quality before the release ?<br>> The GCC test-suite, AFAIK, has very poor quality on what's considered<br>> a pass or a failure, and it's common to release GCC with thousands of<br>> failures on those tests. Some people may run it, but I honestly don't<br>> trust it myself, nor have the time to sift through every single test<br>> to make sure my errors are compiler errors or test errors. You can't<br>> assume that just because GCC runs *more* tests, that what they're<br>> testing is more *thorough*. There are also lots of tests that have<br>> erratic behaviour, which only adds noise to the process.<br>> The release process also involves passing standard compiler benchmarks<br>> from the part of the base testers, and higher level applications (like<br>> Chromium) from the community. Different targets may get different<br>> community interest, but most targets have an additional phase inside<br>> companies like, ARM, Mips, Intel, Apple, Google, Sony, Qualcomm, etc.<br>> They all have internal work-loads that represent a larger piece of<br>> real world code that the test-suite can offer. Whenever those work<br>> loads fail, we get bug reports. It's also good practice to add a<br>> snippet to the test-suite or the regression tests in these cases.<br>> As a separate quality control, there are a few efforts tracking<br>> trunk/releases to build the Linux kernel, Debian, FreeBSD, Mandriva,<br>> OpenEmbedded and other large scale projects. Whenever something breaks<br>> on those projects, bugs are reported and fixed on the next stable<br>> release possible.<br>> I think it's a pretty solid validation process for both trunk and releases.<br>> cheers,<br><p>> --renato</p><p>Agree that, LLVM tests have much better quality than GCC's. So all the tests are most provided by developers and bugzilla. Do we have the test team to do that ? <br></p></div>