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