Re: Obsolete powerpc*-*-*spe*
Hello Segher, On 14/02/17 04:07, Segher Boessenkool wrote: 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. the SPE unit is still used in the embedded PowerPC processors from Freescale/NXP/Qualcomm, for example QorIQ P1020. These products are not obsolete or even not recommended for new designs. These chips have a long product life-cycle. Its a pity that Freescale/NXP/Qualcomm stopped to support GCC development and IBM is burdened to take care of this. I can understand your reasoning, however, its not true that there are no users of the SPE unit. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: Obsolete powerpc*-*-*spe*
On Mon, Feb 13, 2017 at 10:07 PM, Segher Boessenkool wrote: > 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. LGTM. Thanks, David
Re: Obsolete powerpc*-*-*spe*
On 14/02/17 12:55, Sebastian Huber wrote: > Hello Segher, > > On 14/02/17 04:07, Segher Boessenkool wrote: >> 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. > > the SPE unit is still used in the embedded PowerPC processors from > Freescale/NXP/Qualcomm, for example QorIQ P1020. These products are not > obsolete or even not recommended for new designs. These chips have a > long product life-cycle. It is also used in many PPC based microcontrollers, which are used in the automotive industry and other places where you need highly reliable and robust but powerful microcontrollers. However, gcc support for these has traditionally been poor - there is little support for the variety of cores and configurations available from Freescale/NXP. I believe there is a chicken-and-egg situation here - few people use gcc with these devices because there is poorer device support compared to Freescale CodeWarrior or Green Hills, and there is little incentive for gcc developers (such as the CodeSourcery or IBM PPC folks) to support devices in gcc if no one uses that combination. > > Its a pity that Freescale/NXP/Qualcomm stopped to support GCC > development and IBM is burdened to take care of this. I can understand > your reasoning, however, its not true that there are no users of the SPE > unit. > I think what would be needed would be for Freescale/NXP/Qualcomm to put some money and effort in here, with the aim of making gcc their standard compiler for these targets (as they have done for ARM, replacing the old CodeWarrior compiler). Failing that, it is of course better to have no SPE support than broken SPE support, especially if it makes development harder for other devices.
Re: Obsolete powerpc*-*-*spe*
On 14/02/17 15:09, David Brown wrote: On 14/02/17 12:55, Sebastian Huber wrote: Hello Segher, On 14/02/17 04:07, Segher Boessenkool wrote: 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. the SPE unit is still used in the embedded PowerPC processors from Freescale/NXP/Qualcomm, for example QorIQ P1020. These products are not obsolete or even not recommended for new designs. These chips have a long product life-cycle. It is also used in many PPC based microcontrollers, which are used in the automotive industry and other places where you need highly reliable and robust but powerful microcontrollers. However, gcc support for these has traditionally been poor - there is little support for the variety of cores and configurations available from Freescale/NXP. I believe there is a chicken-and-egg situation here - few people use gcc with these devices because there is poorer device support compared to Freescale CodeWarrior or Green Hills, and there is little incentive for gcc developers (such as the CodeSourcery or IBM PPC folks) to support devices in gcc if no one uses that combination. Yes, we use GCC also one these chips, however, due to the lack of VLE support the situation is even worse. Looks like support for the non-IBM PowerPC is dead in GCC. I can understand this pretty well. With the Qualcomm takeover of Freescale/NXP I guess the PowerPC has no future in this area and they will move to ARM for the processor cores. Its a pity that Freescale/NXP/Qualcomm stopped to support GCC development and IBM is burdened to take care of this. I can understand your reasoning, however, its not true that there are no users of the SPE unit. I think what would be needed would be for Freescale/NXP/Qualcomm to put some money and effort in here, with the aim of making gcc their standard compiler for these targets (as they have done for ARM, replacing the old CodeWarrior compiler). Failing that, it is of course better to have no SPE support than broken SPE support, especially if it makes development harder for other devices. Yes, in case Qualcomm shows no interest to support their PowerPC stuff in GCC its quite understandable to remove the support for it eventually. IBM already did a great job in keeping it up and running for a long time. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: Obsolete powerpc*-*-*spe*
On Tue, Feb 14, 2017 at 03:26:09PM +0100, Sebastian Huber wrote: > >>>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. > >>the SPE unit is still used in the embedded PowerPC processors from > >>Freescale/NXP/Qualcomm, for example QorIQ P1020. These products are not > >>obsolete or even not recommended for new designs. These chips have a > >>long product life-cycle. Yes. SPE is part of some e500 and some e200 CPUs I think (but only some, in both cases). > >It is also used in many PPC based microcontrollers, which are used in > >the automotive industry and other places where you need highly reliable > >and robust but powerful microcontrollers. However, gcc support for > >these has traditionally been poor - there is little support for the > >variety of cores and configurations available from Freescale/NXP. I > >believe there is a chicken-and-egg situation here - few people use gcc > >with these devices because there is poorer device support compared to > >Freescale CodeWarrior or Green Hills, and there is little incentive for > >gcc developers (such as the CodeSourcery or IBM PPC folks) to support > >devices in gcc if no one uses that combination. > > Yes, we use GCC also one these chips, however, due to the lack of VLE > support the situation is even worse. Looks like support for the non-IBM > PowerPC is dead in GCC. I can understand this pretty well. It's not true though; we still support all those cores, just not the VLE extension (we never have), and I propose GCC 7 will drop the SPE extension as well -- not all other support we have for those cores. They will have to use soft float, alas. We also still support all non-IBM non-FSL cores. > With the Qualcomm takeover of Freescale/NXP I guess the PowerPC has no > future in this area and they will move to ARM for the processor cores. That is my understanding as well, yes. > >>Its a pity that Freescale/NXP/Qualcomm stopped to support GCC > >>development and IBM is burdened to take care of this. I can understand > >>your reasoning, however, its not true that there are no users of the SPE > >>unit. (I never said there are no users, I'm well aware). The burden is not just IBM's, also all other GCC developers and users. > >I think what would be needed would be for Freescale/NXP/Qualcomm to put > >some money and effort in here, with the aim of making gcc their standard > >compiler for these targets (as they have done for ARM, replacing the old > >CodeWarrior compiler). > > > >Failing that, it is of course better to have no SPE support than broken > >SPE support, especially if it makes development harder for other devices. > > Yes, in case Qualcomm shows no interest to support their PowerPC stuff > in GCC its quite understandable to remove the support for it eventually. > IBM already did a great job in keeping it up and running for a long time. That is the unfortunate reality. Segher
Re: Obsolete powerpc*-*-*spe*
Hi Segher, > On Feb 14, 2017, at 04:07 , Segher Boessenkool > wrote: > > 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. While I understand you already know of existing users and I see the background of your move, I believe it would be a real loss. Here are a few datpoints from here: We have quite a few active users of spe based ports, some big, on both bare-metal and VxWorks configurations, including the recent VxWorks 7 series that we're planning to contribute when stage1 reopens. We are running a fair amount of tests nightly in-house, ACATS for Ada + various batches of regression tests, so keep a constant eye on the state of these ports. We are actually discussing running dejagnu testsuites as well, and we could post test results as soon as we have them. We have participated in the port maintenance in the past and are willing to keep helping as much as we can. We don't have the manpower of chip makers for new versions or extensions of course. With Kind Regards, Olivier
gcc-5-20170214 is now available
Snapshot gcc-5-20170214 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/5-20170214/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-5-branch revision 245459 You'll find: gcc-5-20170214.tar.bz2 Complete GCC MD5=f70fd7c7835d37a0519608f4a3c3d3a2 SHA1=19d76154e36d9de8bf7ffb9527a6987d9f0763c7 Diffs from 5-20170207 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-5 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
PowerPC -many
Since we've been talking about obsoleting cpu support, how about getting rid of -many in ASM_CPU_SPEC for gcc-8? It's a horrible hack of mine to work around gcc -mcpu option handling bugs which I think have been fixed, and to silence complaints from gas about asm() written for multiple cpus (with presumably run-time selection of which block of code gets executed depending on cpu). It used to be just a linux hack, but I see David uses it in aix61.h and aix71.h too? -- Alan Modra Australia Development Lab, IBM
Re: PowerPC -many
On Wed, Feb 15, 2017 at 10:36:02AM +1030, Alan Modra wrote: > Since we've been talking about obsoleting cpu support, how about > getting rid of -many in ASM_CPU_SPEC for gcc-8? Sure, but that doesn't need advance warning to the users, does it? Things worked before and stay working, nothing user-visible? Segher
Re: PowerPC -many
On Tue, Feb 14, 2017 at 06:38:40PM -0600, Segher Boessenkool wrote: > On Wed, Feb 15, 2017 at 10:36:02AM +1030, Alan Modra wrote: > > Since we've been talking about obsoleting cpu support, how about > > getting rid of -many in ASM_CPU_SPEC for gcc-8? > > Sure, but that doesn't need advance warning to the users, does it? Probably not. > Things worked before and stay working, nothing user-visible? Except for bad user asm() that ought to be true. Oh, and gcc bugs like emitting power9 insns when -mcpu=power8. You'd have some chance that the assembler would complain rather than getting sigill at run-time. -- Alan Modra Australia Development Lab, IBM
Re: PowerPC -many
On 2/14/17 6:06 PM, Alan Modra wrote: Since we've been talking about obsoleting cpu support, how about getting rid of -many in ASM_CPU_SPEC for gcc-8? +1 Peter
Re: PowerPC -many
On Wed, Feb 15, 2017 at 11:34:26AM +1030, Alan Modra wrote: > On Tue, Feb 14, 2017 at 06:38:40PM -0600, Segher Boessenkool wrote: > > On Wed, Feb 15, 2017 at 10:36:02AM +1030, Alan Modra wrote: > > > Since we've been talking about obsoleting cpu support, how about > > > getting rid of -many in ASM_CPU_SPEC for gcc-8? > > > > Sure, but that doesn't need advance warning to the users, does it? > > Probably not. > > > Things worked before and stay working, nothing user-visible? > > Except for bad user asm() that ought to be true. Oh, and gcc bugs > like emitting power9 insns when -mcpu=power8. You'd have some chance > that the assembler would complain rather than getting sigill at > run-time. What does gcc do when using target attribute, where one function is power7, another power9, then another power8? Jakub
