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.
Jeff
