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