This is the mail archive of the gcc-patches@gcc.gnu.org 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 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.

jeff


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