Obsolete powerpc*-*-*spe*

[Peter Dufault]

> On Feb 14, 2017, at 22:08 , Sebastian Huber <sebastian.huber at embedded-brains.de> wrote:
> 
> Looks like embedded PowerPC is going to die in GCC:
> 
> -------- Forwarded Message --------
> Subject: 	Obsolete powerpc*-*-*spe*
> Date: 	Mon, 13 Feb 2017 21:07:03 -0600
> From: 	Segher Boessenkool <segher at kernel.crashing.org <mailto:segher at kernel.crashing.org>>
> To: 	gcc at gcc.gnu.org <mailto:gcc at gcc.gnu.org>
> CC: 	dje.gcc at gmail.com <mailto:dje.gcc at gmail.com>
> 
> 
> 
> Hi all,
> 
> I propose to mark powerpc*-*-*spe* as obsolete in GCC 7.  This includes
> the spe.h installed header file, all the __builtin_spe* intrinsics, the
> -mfloat-gprs= command-line option, and the support for the SPE ABIs.
> 
> No one has properly tested these targets in a long time (the latest
> testresults I could find are from July 2015, >1000 failures), and the
> SPE support makes a lot of code much more complex.
> 
> Any objections to this obsoletion?  GCC 7 will then be the last release
> with support for SPE (it will need --enable-obsolete to build these
> targets), and we will delete the SPE support during GCC 8 development.


I’ve been traveling and just noticed this.  I use this target in three applications with RTEMS.
Who else in the RTEMS community is using this?
The spe.h header file has been hopelessly broken forever, that’s not an issue.
I build and use the “libdsp2” library for SPE. This is primarily assembler and I hope the assembler support for SPE is not affected, but I‘m not sure.
I assume the major issue will be the removal of support for -mfloat-gprs and SPE ABIs.
Can someone with GCC knowledge comment about the possibility of pared-back support?  I’m guessing little or no hope based on the comment that “SPE support makes a lot of code much more complex” and SPE support with the ABI would be needed to use the DSP library and single precision floating point with the -mfloat-gprs registers.
I think this is going to put those applications into maintenance mode and make that target inappropriate for new RTEMS applications.

Peter
-----------------
Peter Dufault
HD Associates, Inc.      Software and System Engineering

This email, like most email, is delivered unencrypted via internet email protocols subject to interception and tampering.  Contact HDA to discuss methods we can use that ensure secure communication.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20170219/334df68c/attachment-0002.html>