On Tue, 15 Dec 2020 at 04:01, Jeff Law <l...@redhat.com> wrote: > > > On 12/14/20 12:10 PM, Dimitar Dimitrov wrote: > > On четвъртък, 10 декември 2020 г. 10:24:50 EET Richard Biener wrote: > >> On Thu, Dec 10, 2020 at 6:42 AM Dimitar Dimitrov <dimi...@dinux.eu> > wrote: > >>> On сряда, 9 декември 2020 г. 15:12:49 EET abebeos via Gcc-patches > wrote: > >>>> Essence: > >>>> > >>>> I need a confirmation that the testsuite setup as presented in: > >>>> > >>>> https://github.com/abebeos/avr-gnu > >>>> > >>>> works fine. > >>>> > >>>> The problem with the avr target is that the testsuite cannot be run > >>>> easily, > >>>> mainly because of the need for a special simulated-target setup, which > >>>> does > >>>> not work for avr as documented. This led developers to a dead-end with > >>>> their non-cc0-avr-backends (the non-cc0 backend is needed thus avr is > >>>> not > >>>> dropped from gcc11). > >>>> > >>>> I integrated a toolchain/testsetup to be able to run the gcc testsuite > >>>> against a simulated avr target. > >>>> > >>>> I then used this toolchain to test 2 different existent > >>>> non-cc0-avr-backends (from pipcet and saaadhu, both github). > >>>> > >>>> The result is that saaadhu's backend seems to be working 100%. It has > >>>> identical testsuite results with the existing (but deprecated) > >>>> cc0-backend, > >>>> which means that it can be used "as-is" for inclusion in gcc11. > >>>> > >>>> Please note that I did this work in context of a bounty @ bountysouce, > >>>> more > >>>> information within the issue: > >>>> > >>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729#c35 > >>> Hi, > >>> > >>> I tested the trees you have given with my own AVR test setup [1]. I > >>> confirm > >>> > >>> your results: > >>> - saaadhu's tree does not introduce any regressions. > >>> - pipcet's tree has 142 gcc and 299 g++ regressions (although many of > >>> them > >>> > >>> are duplicates, e.g. same test case with different optimization > >>> levels). > >>> > >>> It's a bit awkward to copy gcc/config/avr into a mainline tree. > Looking at > >>> their github history, both authors made some small changes in other > areas. > >>> I would have prefered to cherry-pick or apply patches. > >>> > >>> ================================================= > >>> baseline beb9afcaf1466996a301c778596c5df209e7913c > >>> > >>> === gcc Summary === > >>> > >>> # of expected passes 87504 > >>> # of unexpected failures 1105 > >>> # of unexpected successes 15 > >>> # of expected failures 581 > >>> # of unresolved testcases 16786 > >>> # of unsupported tests 5370 > >>> > >>> === g++ Summary === > >>> > >>> # of expected passes 140663 > >>> # of unexpected failures 7932 > >>> # of unexpected successes 21 > >>> # of expected failures 620 > >>> # of unresolved testcases 8603 > >>> # of unsupported tests 11305 > >>> > >>> ================================================= > >>> pipcet/avr-ccmode > >>> > >>> === gcc Summary === > >>> > >>> # of expected passes 87463 > >>> # of unexpected failures 1221 > >>> # of unexpected successes 15 > >>> # of expected failures 581 > >>> # of unresolved testcases 16799 > >>> # of unsupported tests 5359 > >>> > >>> === g++ Summary === > >>> > >>> # of expected passes 140529 > >>> # of unexpected failures 8205 > >>> # of unexpected successes 21 > >>> # of expected failures 620 > >>> # of unresolved testcases 8607 > >>> # of unsupported tests 11301 > >>> > >>> ================================================= > >>> saadhu/avr-cc0 > >>> > >>> === gcc Summary === > >>> > >>> # of expected passes 87504 > >>> # of unexpected failures 1105 > >>> # of unexpected successes 15 > >>> # of expected failures 581 > >>> # of unresolved testcases 16786 > >>> # of unsupported tests 5370 > >>> > >>> === g++ Summary === > >>> > >>> # of expected passes 140663 > >>> # of unexpected failures 7932 > >>> # of unexpected successes 21 > >>> # of expected failures 620 > >>> # of unresolved testcases 8603 > >>> # of unsupported tests 11305 > >>> > >>> On a side note, I build and test AVR backend in mainline everyday. If > >>> there is interest from AVR maintainers I can post daily results to > >>> gcc-testresults@ mailing list. > >> I'd appreciate such postings, not necessarily daily (if there are no > >> changes). Also (as usual) for active release branches (say once a week > or > >> biweekly or even monthly). > > I'll start sending biweekly the AVR testresults from all active branches. > > > > Yesterday my test results were temporarily held back due to large email > size, > > but eventually reached gcc-testresults@ . I'd like to know if I need to > trim > > them somehow. > You might consider using contrib/compare_tests rather than dumping the > entire results to the list. compare_tests focuses on things that > changed from one run to the next. So you need to keep the results from > the prior run for comparison purposes. >
2 remarks here: * contrib/compare_tests produced some strange/inconsistent results during my avr regression tests, so check it first. I switched to contrib/dg-cmp-results for the regressions. * it looks like the list gcc-testresults expects the results created from contrib/test_summary (if i remember it lists only the failures), and the list gcc-regression only(!) the regressions. https://gcc.gnu.org/lists.html - * gcc-testresults <https://gcc.gnu.org/ml/gcc-testresults/>* is a moderate volume list where test results for the GCC compilers are posted. - *gcc-regression <https://gcc.gnu.org/ml/gcc-regression/>* is a moderate volume list where regression results for the GCC compilers are posted. - Note that me a newcomer, so possibly I got something wrong. > Jeff > >
