This is the mail archive of the
mailing list for the GCC project.
Re: PowerPC SPE maintainership (was Re: Obsolete powerpc*-*-*spe*)
- From: Joel Sherrill <joel dot sherrill at oarcorp dot com>
- To: Joseph Myers <joseph at codesourcery dot com>, Segher Boessenkool <segher at kernel dot crashing dot org>
- Cc: Andrew Jenner <andrew at codesourcery dot com>, David Edelsohn <dje dot gcc at gmail dot com>, GCC Development <gcc at gcc dot gnu dot org>, Olivier Hainque <hainque at adacore dot com>, Sandra Loosemore <sandra at codesourcery dot com>, Arnaud Charlet <charlet at adacore dot com>, Joel Brobecker <brobecker at adacore dot com>
- Date: Mon, 1 May 2017 10:47:03 -0500
- Subject: Re: PowerPC SPE maintainership (was Re: Obsolete powerpc*-*-*spe*)
- Authentication-results: sourceware.org; auth=none
- References: <20170214030703.GS21840@gate.crashing.org> <58A61E7B.email@example.com> <20170216221937.GB21840@gate.crashing.org> <58A63B91.firstname.lastname@example.org> <CAGWvny=aWTzSta=jwZS8HwmWU4riN7ee46CZP8MwS2PcYPC0mw@mail.gmail.com> <452E2837-FC8A-4DA2-A2B9-F58151841F58@adacore.com> <CAGWvnymQjd=k4Hv6PgWW2kuCinQTOQvSRvSEnVRN-C-RnvmKig@mail.gmail.com> <email@example.com> <firstname.lastname@example.org> <20170428231544.GF19687@gate.crashing.org> <alpine.DEB.email@example.com>
On 5/1/2017 5:48 AM, Joseph Myers wrote:
On Sat, 29 Apr 2017, Segher Boessenkool wrote:
We also still have to agree on the target triples for the new port.
If you have any thoughts on this, I'd love to hear them.
It seems fairly obvious that the powerpc-*-eabispe* and
powerpc*-*-linux*spe* triples should continue to work while being mapped
to the new CPU port. It's less obvious what triples should be used for
SPE versions of other SPE-supporting configurations such as
powerpc-*-eabisim*, powerpc-*-rtems*, powerpc-wrs-vxworks*.
powerpc-*-rtemsspe* would be OK.
powerpc-*-eabisimspe* is pretty ugly though.
It is obvious but if powerpc-*-XXXspe* is the pattern, then the
spe cases need to be above in all configure switches. I hate to
mention it but a fair number of odd RTEMS issues turn out to be
from inadvertent side-effects when cleaning up configure switches.
Some testcases will be applicable to both ports, some to only one.
Maintainers of each port should of course watch the other port for changes
that should be carried across, even if we believe, as has been stated in
this discussion, that the parts of the code that would be present in both
ports are stable and very rarely change.