This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Delete powerpcspe
On Tue, Dec 11, 2018 at 2:37 PM Jeff Law <law@redhat.com> wrote:
>
> On 12/11/18 1:44 AM, Richard Biener wrote:
> > On Mon, Dec 10, 2018 at 9:13 PM Segher Boessenkool
> > <segher@kernel.crashing.org> wrote:
> >>
> >> On Mon, Dec 10, 2018 at 06:25:31PM +0000, Andrew Jenner wrote:
> >>> Sorry for the slow response on this, I was on vacation last week.
> >>>
> >>> On 03/12/2018 21:48, Jakub Jelinek wrote:
> >>>> I'd give the maintainers the last week to act if they don't want this
> >>>> to happen and if nothing happens, commit it. PR81084 lists all the reasons
> >>>> why it should be removed when it is totally unmaintained.
> >>>> Just make sure to put stuff that belongs there to gcc/ChangeLog and without
> >>>> gcc/ prefixes.
> >>>
> >>> Yes, please go ahead and commit
> >>
> >> Committed to trunk as r266961.
> >>
> >>> - it's not fair on other maintainers to
> >>> have to work around my lack of action on this port. I will continue to
> >>> work on it out-of-tree and hope to restore it once it is in proper shape.
> >>
> >> The more important thing is maintenance... Regular and/or frequent tests
> >> (posted to gcc-testresults@), bug tracker maintenance, etc. You need to
> >> be visible.
> >
> > Very much agreed on that. Though if we pull out this card we're applying
> > double-standards here considering for example ia64 or some embedded ports.
> The biggest problem with the embedded ports is lack of reliable
> simulator testing combined with reduced address space availability. So
> you end up with a test that works fine today, but due to a runtime clash
> of the stack and heap it may well fail tomorrow due to an unrelated code
> change (by changing what's on the stack and where). Or worse yet, you
> end up with hundreds of tests that time out, causing the testrun to go
> on so long it's useless.
>
> One way to deal with these problems is to create a fake simulator that
> always returns success. That's what my tester does for the embedded
> targets. That allows us to do reliable compile-time tests as well as
> the various scan-whatever tests.
>
> It would be trivial to start sending those results to gcc-testresults.
I think it would be more useful if the execute testing would be
reported as UNSUPPORTED rather than simply PASS w/o being
sure it does.
But while posting to gcc-testresults is a sign of testing tracking
regressions (and progressions!) in bugzilla and caring for those
bugs is far more important...
Richard.
> jeff