This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Delete powerpcspe

On Tue, Dec 11, 2018 at 2:37 PM Jeff Law <> wrote:
> On 12/11/18 1:44 AM, Richard Biener wrote:
> > On Mon, Dec 10, 2018 at 9:13 PM Segher Boessenkool
> > <> 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...


> jeff

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]