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). Without any hints on gcc-testresults its hard to asses whether ports pass some very basic functionality criteria (AVR is neither primary nor secondary but shipping totally broken ports isn't in our interest). Thanks a lot, Richard. > Regards, > Dimitar > > [1] https://github.com/dinuxbg/gnupru/blob/master/testing/buildbot-avr.sh > >
