Στις Παρ, 11 Δεκ 2020 στις 8:32 μ.μ., ο/η Jeff Law <l...@redhat.com> έγραψε:
> > > On 12/9/20 6:12 AM, 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 > I haven't looked at the github repo. But I do have a couple comments here. > > First, the author of the changes (pipcet and saaadhu) need to have > copyright assignments on file with the FSF. Otherwise we can not use > their work at all. > saaadhu (1st choice, zero regressions) should have one, has recently commited something, too: https://gcc.gnu.org/git/?p=gcc.git;a=search;h=e7d55c6b81733335d81e35f7c0116bbdffccb682;s=Senthil+Kumar+Selvaraj;st=committer pipcet (2nd choice, some regressions) is willing to release his code, see: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729#c21 saaadhu (like pipcet) is willing to help (was not necessary till now, technically) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729#c18 Second, the work needs to be submitted for inclusion. I don't recall > seeing an official submission from either of them to gcc-patches. > My understanding of "non-FSF world-legals" is that something that is already released/assigned needs no submission. E.g., a copyright-agreement that includes future work on the projects/products code, makes it unnecessary to submit futuer changes: a publicly available modification is already assigned to the project. Sometimes gnu/fsf has his own legal thinking, so possibly "submission by the authors" is a necessity here. But I don't think that those 2 authors are reluctant to submit their code. (just those delays...) > > I'm definitely curious about the testing setup and whether or not it can > be replicated into our Jenkins setup. It is my understanding there is > no newlib support for avr so I'm curious what you're using for a basic > runtime library. > I think you're asking about avr-libc, but not sure... ( I come from hardware design, niche-machines usually, mostly solo-work, so I'm used to achieve goals by inhibiting many many stuff to avoid getting "drowned in complexity", to the point that I look even dumb to others, like "how can he achieve the goal without knowing...".) After inhibiting the official docs (which simply don't work with avr), I evaluated a dozen avr setups, then produced an own setup step by step. My focus was to have testresults close to those (very few) published in the mail archives. I got there. Then, my focus was to achieve a "zero regression" with existing non-cc0 avr-gcc code (I got there, with saaadhu's code). (eliminating the test-fails would be a next step, after getting the code in gcc11 and "saving" the avr backend) CI integration should be possible, really nothing special in my test-setup. > > jeff > >
