Obsolete powerpc*-*-*spe*

[Andrew Jenner]

On 21/02/2017 16:14, David Edelsohn wrote:
> On Mon, Feb 20, 2017 at 11:02 AM, Olivier Hainque <hainque@adacore.com> wrote:
>>> On Feb 17, 2017, at 01:10 , David Edelsohn <dje.gcc@gmail.com> wrote:
>>>
>>> This is not a new issue.  The maintainer did not suddenly resign last
>>> week.  There have been numerous efforts to reach out to the SPE
>>> community for over a *decade*, cajoling them to step up with
>>> maintenance for the port.  I am glad that this notice of obsolescence
>>> has focused more attention on the long-standing problem.
>>
>> Would there be a minimum level of commitment you'd like
>> to get to accept leaving the port in (if not this, at least
>> that ...) ?
>
> [...]
>
> There are three main areas that require attention:
>
> 1) Regular builds of the SPE configuration and regular GCC testsuite
> runs that are reported to the gcc-testsuite mailing list.
>
> 2) Timely reports of any regressions.
>
> 3) An active GCC developer who is the point of contact for the SPE
> port and submits patches for the port.
>
> None of us within IBM are experts on the SPE port.  Someone from the
> SPE community is needed to help triage issues, debug problems and test
> patches that may affect the SPE port.
>
> With evidence of pro-active involvement from an SPE developer, the
> port does not have to be deprecated. The effort needs to be more that
> activity at GCC release cycle boundaries or an accelerated deprecation
> process will be proposed.

I volunteer to be the point of contact for the SPE port.

Over here at CodeSourcery/Mentor Embedded, we have a strong interest in 
SPE *not* being deprecated (we actively ship toolchain products with SPE 
multilibs, and have customers for which these are important). We are 
therefore volunteering resources (specifically, me) to maintain SPE 
upstream as well.

I am in the process of developing some patches to add VLE support 
upstream (and expect to be maintainer of those once they are committed) 
so it would be a good fit for me to be the SPE maintainer as well.

We have been regularly running tests on the SPE multilibs (on our 
internal branches) and they are in better shape than the test results 
Segher found from 2015. We may have some (not yet upstreamed) patches 
that improve the test results - I will be tracking these down and 
upstreaming them ASAP. I will be expanding our regular build and test 
runs to cover trunk as well, and will send test results to gcc-testsuite 
and report regressions.

If there is no objection, I will submit patches tomorrow to un-obsolete 
SPE and add myself to the appropriate section of the MAINTAINERS file. 
The other changes will come once stage 1 opens.

Thanks,

Andrew