Re: [PATCH] Delete powerpcspe
On 12/14/18 11:41 AM, Joseph Myers wrote: > On Fri, 14 Dec 2018, Jeff Law wrote: > >>> I wonder if we could set up auto-(simulator)-testing for all supported >>> archs (and build testing for all supported configs) on the CF >>> (with the required scripting in contrib/ so it's easy to replicate). I'd >>> simply test only released snapshots to keep the load reasonable >>> and besides posting to gcc-testresults also post testresults >>> differences to gcc-regression? >> It's certainly possible. Though I've found that managing this kind of >> thing with Jenkins is far easier than rolling our own. I'd be happy to >> move an instance out into the CF. > > On the other hand, in glibc having a single script build-many-glibcs.py > that does everything (rather than some external piece of software to > orchestrate builds) serves to make it easy for people making changes with > cross-architecture risks to run the compilation tests for all > architectures - although doing so is slow unless you have lots of CPU > cores. Yup. What I've been playing with to deal with that is the ability for the tester to monitor a per-user branch in a special repository. When a change on that branch is detected, it fires up builds with and without the patches on that branch and compares the results. Right now it's just native x86, but the idea is to include a control file on the branch that would allow it to cycle through specific targets or groups of targets and any special flags (like additional C++ language variants to test). It's a fairly simple extension since I already had the ability to drop patches into a special github repo and the tester would automatically use them. jeff
Re: [PATCH] Delete powerpcspe
On Fri, 14 Dec 2018, Jeff Law wrote: > > I wonder if we could set up auto-(simulator)-testing for all supported > > archs (and build testing for all supported configs) on the CF > > (with the required scripting in contrib/ so it's easy to replicate). I'd > > simply test only released snapshots to keep the load reasonable > > and besides posting to gcc-testresults also post testresults > > differences to gcc-regression? > It's certainly possible. Though I've found that managing this kind of > thing with Jenkins is far easier than rolling our own. I'd be happy to > move an instance out into the CF. On the other hand, in glibc having a single script build-many-glibcs.py that does everything (rather than some external piece of software to orchestrate builds) serves to make it easy for people making changes with cross-architecture risks to run the compilation tests for all architectures - although doing so is slow unless you have lots of CPU cores. -- Joseph S. Myers jos...@codesourcery.com
Re: [PATCH] Delete powerpcspe
On 12/14/18 1:20 AM, Segher Boessenkool wrote:
> On Thu, Dec 13, 2018 at 09:49:51AM -0700, Jeff Law wrote:
>> On 12/12/18 10:33 AM, Segher Boessenkool wrote:
>>> On Wed, Dec 12, 2018 at 11:36:29AM +0100, Richard Biener wrote:
On Tue, Dec 11, 2018 at 2:37 PM Jeff Law wrote:
> 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.
I think it would be more useful if the execute testing would be
reported as UNSUPPORTED rather than simply PASS w/o being
sure it does.
>>>
>>> Yes.
>> Yes, but I don't think we've got a reasonable way to do that in the
>> existing dejagnu framework.
>
> I think you can have your board's ${board}_load just do
> return [list "unresolved" ""]
> or something like that.
That's easy 'nuff to try. My dejagnu days are so far back in the past
any tricks have been dropped into the bit bucket of my mind.
>
>
>>> If results are posted to gcc-testresults then other people can get a
>>> feel whether the port is detoriating, and at what rate. If no results
>>> are posted we just have to assume the worst. Most people do not have
>>> the time (or setup) to test it for themselves.
>> Yup. I wish I had the time to extract more of the data the tester is
>> gathering and produce this kind of info.
>>
>> I have not made it a priority to try and address all the issues I've
>> seen in the tester. We have some ports that are incredibly flaky
>> (epiphany for example), and many that have a lot of failures, but are
>> stable in their set of failures.
>>
>> My goal to date has mostly been to identify regressions. I'm not even
>> able to keep up with that. For example s390/s390x have been failing for
>> about a week with their kernel builds.sparc, i686, aarch64 are
>> consistently tripping over regressions. ia64 hasn't worked since we put
>> in qsort consistency checking, etc etc.
>
> About a third of kernel builds have failed (for my configs) this whole
> stage 1 and stage 3... Hopefully it will be better in stage 4.
I'm not seeing as many, though I do have some patches to avoid known
issues that are on the kernel side. Broken s390 asms, missing includes
is the mellanox drivers, whatever.
It's also the case that there's targets where I could cover a kernel
build, but don;t at the moment. A great example would be the H8, but
there's others. The common thread is if there isn't a glibc port, then
I'm not covering the kernel.
Jeff
Re: [PATCH] Delete powerpcspe
On 12/14/18 2:52 AM, Richard Biener wrote: > On Thu, Dec 13, 2018 at 5:49 PM Jeff Law wrote: >> >> On 12/12/18 10:33 AM, Segher Boessenkool wrote: >>> On Wed, Dec 12, 2018 at 11:36:29AM +0100, Richard Biener wrote: On Tue, Dec 11, 2018 at 2:37 PM Jeff Law wrote: > 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. I think it would be more useful if the execute testing would be reported as UNSUPPORTED rather than simply PASS w/o being sure it does. >>> >>> Yes. >> Yes, but I don't think we've got a reasonable way to do that in the >> existing dejagnu framework. >> >> >>> But while posting to gcc-testresults is a sign of testing tracking regressions (and progressions!) in bugzilla and caring for those bugs is far more important... >>> >>> If results are posted to gcc-testresults then other people can get a >>> feel whether the port is detoriating, and at what rate. If no results >>> are posted we just have to assume the worst. Most people do not have >>> the time (or setup) to test it for themselves. >> Yup. I wish I had the time to extract more of the data the tester is >> gathering and produce this kind of info. >> >> I have not made it a priority to try and address all the issues I've >> seen in the tester. We have some ports that are incredibly flaky >> (epiphany for example), and many that have a lot of failures, but are >> stable in their set of failures. >> >> My goal to date has mostly been to identify regressions. I'm not even >> able to keep up with that. For example s390/s390x have been failing for >> about a week with their kernel builds.sparc, i686, aarch64 are >> consistently tripping over regressions. ia64 hasn't worked since we put >> in qsort consistency checking, etc etc. > > Yeah :/ > > I wonder if we could set up auto-(simulator)-testing for all supported > archs (and build testing for all supported configs) on the CF > (with the required scripting in contrib/ so it's easy to replicate). I'd > simply test only released snapshots to keep the load reasonable > and besides posting to gcc-testresults also post testresults > differences to gcc-regression? It's certainly possible. Though I've found that managing this kind of thing with Jenkins is far easier than rolling our own. I'd be happy to move an instance out into the CF. > > That said, can we document how to simulator-test $target in > a structural way somewhere? Either my means of (a) script(s) > in contrib/ or by simple documentation in a new gcc/testing.texi > or on the wiki? It should be possible. Sometimes it's just using the right --target_board.Other times there isn't one so you write your own glue code :( That glue code is part of dejagnu. > > You at least seem to have some sort of scripting for some targets? > Esp. having target boards and simulator configs would be nice > (and pointers where to look for simulators). Well, since I'm using a fake simulator no mapping is needed. Though I've got plumbing in to use the simulator from gdb in place. The plan was to turn that on once things using the fake simulator were stable. Jeff
Re: [PATCH] Delete powerpcspe
On Thu, Dec 13, 2018 at 5:49 PM Jeff Law wrote: > > On 12/12/18 10:33 AM, Segher Boessenkool wrote: > > On Wed, Dec 12, 2018 at 11:36:29AM +0100, Richard Biener wrote: > >> On Tue, Dec 11, 2018 at 2:37 PM Jeff Law wrote: > >>> 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. > >> > >> I think it would be more useful if the execute testing would be > >> reported as UNSUPPORTED rather than simply PASS w/o being > >> sure it does. > > > > Yes. > Yes, but I don't think we've got a reasonable way to do that in the > existing dejagnu framework. > > > > > >> But while posting to gcc-testresults is a sign of testing tracking > >> regressions (and progressions!) in bugzilla and caring for those > >> bugs is far more important... > > > > If results are posted to gcc-testresults then other people can get a > > feel whether the port is detoriating, and at what rate. If no results > > are posted we just have to assume the worst. Most people do not have > > the time (or setup) to test it for themselves. > Yup. I wish I had the time to extract more of the data the tester is > gathering and produce this kind of info. > > I have not made it a priority to try and address all the issues I've > seen in the tester. We have some ports that are incredibly flaky > (epiphany for example), and many that have a lot of failures, but are > stable in their set of failures. > > My goal to date has mostly been to identify regressions. I'm not even > able to keep up with that. For example s390/s390x have been failing for > about a week with their kernel builds.sparc, i686, aarch64 are > consistently tripping over regressions. ia64 hasn't worked since we put > in qsort consistency checking, etc etc. Yeah :/ I wonder if we could set up auto-(simulator)-testing for all supported archs (and build testing for all supported configs) on the CF (with the required scripting in contrib/ so it's easy to replicate). I'd simply test only released snapshots to keep the load reasonable and besides posting to gcc-testresults also post testresults differences to gcc-regression? That said, can we document how to simulator-test $target in a structural way somewhere? Either my means of (a) script(s) in contrib/ or by simple documentation in a new gcc/testing.texi or on the wiki? You at least seem to have some sort of scripting for some targets? Esp. having target boards and simulator configs would be nice (and pointers where to look for simulators). Richard. > Jeff
Re: [PATCH] Delete powerpcspe
> On 14 Dec 2018, at 08:20, Segher Boessenkool
> wrote:
>
> On Thu, Dec 13, 2018 at 09:49:51AM -0700, Jeff Law wrote:
>> On 12/12/18 10:33 AM, Segher Boessenkool wrote:
>>> On Wed, Dec 12, 2018 at 11:36:29AM +0100, Richard Biener wrote:
On Tue, Dec 11, 2018 at 2:37 PM Jeff Law wrote:
> 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.
I think it would be more useful if the execute testing would be
reported as UNSUPPORTED rather than simply PASS w/o being
sure it does.
>>>
>>> Yes.
>> Yes, but I don't think we've got a reasonable way to do that in the
>> existing dejagnu framework.
+1 for this idea
>
> I think you can have your board's ${board}_load just do
> return [list "unresolved" ""]
> or something like that.
Would it not be possible to have a "target-supports" test that determines
that a trivial exe will run, and then have "dg-do run” fall back to only the
build phase and set UNSUPPORTED for everything past that?
(of course, this test would be in the dg-init and friends, not per test!)
Alternately, perhaps Jeff's dummy exe could produce a "Well Known" output
that could be pre-pruned => UNSUPPORTED?
>>> If results are posted to gcc-testresults then other people can get a
>>> feel whether the port is detoriating, and at what rate. If no results
>>> are posted we just have to assume the worst. Most people do not have
>>> the time (or setup) to test it for themselves.
>> Yup. I wish I had the time to extract more of the data the tester is
>> gathering and produce this kind of info.
>>
>> I have not made it a priority to try and address all the issues I've
>> seen in the tester. We have some ports that are incredibly flaky
>> (epiphany for example), and many that have a lot of failures, but are
>> stable in their set of failures.
>>
>> My goal to date has mostly been to identify regressions. I'm not even
>> able to keep up with that. For example s390/s390x have been failing for
>> about a week with their kernel builds.sparc, i686, aarch64 are
>> consistently tripping over regressions. ia64 hasn't worked since we put
>> in qsort consistency checking, etc etc.
>
> About a third of kernel builds have failed (for my configs) this whole
> stage 1 and stage 3... Hopefully it will be better in stage 4.
>
>
> Segher
Re: [PATCH] Delete powerpcspe
On Thu, Dec 13, 2018 at 09:49:51AM -0700, Jeff Law wrote:
> On 12/12/18 10:33 AM, Segher Boessenkool wrote:
> > On Wed, Dec 12, 2018 at 11:36:29AM +0100, Richard Biener wrote:
> >> On Tue, Dec 11, 2018 at 2:37 PM Jeff Law wrote:
> >>> 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.
> >>
> >> I think it would be more useful if the execute testing would be
> >> reported as UNSUPPORTED rather than simply PASS w/o being
> >> sure it does.
> >
> > Yes.
> Yes, but I don't think we've got a reasonable way to do that in the
> existing dejagnu framework.
I think you can have your board's ${board}_load just do
return [list "unresolved" ""]
or something like that.
> > If results are posted to gcc-testresults then other people can get a
> > feel whether the port is detoriating, and at what rate. If no results
> > are posted we just have to assume the worst. Most people do not have
> > the time (or setup) to test it for themselves.
> Yup. I wish I had the time to extract more of the data the tester is
> gathering and produce this kind of info.
>
> I have not made it a priority to try and address all the issues I've
> seen in the tester. We have some ports that are incredibly flaky
> (epiphany for example), and many that have a lot of failures, but are
> stable in their set of failures.
>
> My goal to date has mostly been to identify regressions. I'm not even
> able to keep up with that. For example s390/s390x have been failing for
> about a week with their kernel builds.sparc, i686, aarch64 are
> consistently tripping over regressions. ia64 hasn't worked since we put
> in qsort consistency checking, etc etc.
About a third of kernel builds have failed (for my configs) this whole
stage 1 and stage 3... Hopefully it will be better in stage 4.
Segher
Re: [PATCH] Delete powerpcspe
On 12/12/18 10:33 AM, Segher Boessenkool wrote: > On Wed, Dec 12, 2018 at 11:36:29AM +0100, Richard Biener wrote: >> On Tue, Dec 11, 2018 at 2:37 PM Jeff Law wrote: >>> 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. >> >> I think it would be more useful if the execute testing would be >> reported as UNSUPPORTED rather than simply PASS w/o being >> sure it does. > > Yes. Yes, but I don't think we've got a reasonable way to do that in the existing dejagnu framework. > >> But while posting to gcc-testresults is a sign of testing tracking >> regressions (and progressions!) in bugzilla and caring for those >> bugs is far more important... > > If results are posted to gcc-testresults then other people can get a > feel whether the port is detoriating, and at what rate. If no results > are posted we just have to assume the worst. Most people do not have > the time (or setup) to test it for themselves. Yup. I wish I had the time to extract more of the data the tester is gathering and produce this kind of info. I have not made it a priority to try and address all the issues I've seen in the tester. We have some ports that are incredibly flaky (epiphany for example), and many that have a lot of failures, but are stable in their set of failures. My goal to date has mostly been to identify regressions. I'm not even able to keep up with that. For example s390/s390x have been failing for about a week with their kernel builds.sparc, i686, aarch64 are consistently tripping over regressions. ia64 hasn't worked since we put in qsort consistency checking, etc etc. Jeff
Re: [PATCH] Delete powerpcspe
On Wed, Dec 12, 2018 at 11:36:29AM +0100, Richard Biener wrote: > On Tue, Dec 11, 2018 at 2:37 PM Jeff Law wrote: > > 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. > > I think it would be more useful if the execute testing would be > reported as UNSUPPORTED rather than simply PASS w/o being > sure it does. Yes. > But while posting to gcc-testresults is a sign of testing tracking > regressions (and progressions!) in bugzilla and caring for those > bugs is far more important... If results are posted to gcc-testresults then other people can get a feel whether the port is detoriating, and at what rate. If no results are posted we just have to assume the worst. Most people do not have the time (or setup) to test it for themselves. Segher
Re: [PATCH] Delete powerpcspe
On Tue, Dec 11, 2018 at 2:37 PM Jeff Law wrote: > > On 12/11/18 1:44 AM, Richard Biener wrote: > > On Mon, Dec 10, 2018 at 9:13 PM Segher Boessenkool > > wrote: > >> > >> On Mon, Dec 10, 2018 at 06:25:31PM +, 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. I think it would be more useful if the execute testing would be reported as UNSUPPORTED rather than simply PASS w/o being sure it does. But while posting to gcc-testresults is a sign of testing tracking regressions (and progressions!) in bugzilla and caring for those bugs is far more important... Richard. > jeff
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 > wrote: >> >> On Mon, Dec 10, 2018 at 06:25:31PM +, 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
Re: [PATCH] Delete powerpcspe
On Mon, Dec 10, 2018 at 9:13 PM Segher Boessenkool wrote: > > On Mon, Dec 10, 2018 at 06:25:31PM +, 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. Richard. > > Segher
Re: [PATCH] Delete powerpcspe
On Mon, Dec 10, 2018 at 06:25:31PM +, 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. Segher
Re: [PATCH] Delete powerpcspe
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 - 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. Thanks, Andrew
Re: [PATCH] Delete powerpcspe
On Mon, Dec 03, 2018 at 02:40:12PM -0700, Jeff Law wrote: > > 2018-12-03 Segher Boessenkool > > > > * contrib/config-list.mk: Remove powerpc-eabispe and powerpc-linux_spe. > > * gcc/config.gcc (Obsolete configurations): Delete powerpc*-*-*spe*. > > (Unsupported targets): Add powerpc*-*-*spe*. > > (powerpc*-*-*spe*): Delete. > > (powerpc-*-eabispe*): Delete. > > (powerpc-*-rtems*spe*): Delete. > > (powerpc*-*-linux*spe*): Delete. > > (powerpc*-*-linux*): Do not handle the linux*spe* targets. > > (powerpc-wrs-vxworks*spe): Delete. > > (with_cpu setting code): Delete powerpc*-*-*spe* handling. > > * gcc/config.host (target powerpc*-*-*spe*): Delete. > > * gcc/doc/invoke.texi (PowerPC SPE Options): Delete. > > (PowerPC SPE Options): Delete. > > * gcc/config/powerpcspe: Delete. > I'm all for it. Let's give Jakub and Richi and chance to chime in though. 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. Jakub
Re: [PATCH] Delete powerpcspe
On 12/3/18 1:50 PM, Segher Boessenkool wrote: > This deletes powerpcspe, which was deprecated for GCC 8. > > I'm not including the rm -r gcc/config/powerpcspe part in the patch, > see the diffstat summary for why. > > This does not change the testsuite, or libgcc for rs6000 (which still > is shared code with powerpcspe, so can use some cleanup after this). > > Tested building a powerpc-linux_spe target; it now is refused. > > Is this okay for trunk? > > > Segher > > > 2018-12-03 Segher Boessenkool > > * contrib/config-list.mk: Remove powerpc-eabispe and powerpc-linux_spe. > * gcc/config.gcc (Obsolete configurations): Delete powerpc*-*-*spe*. > (Unsupported targets): Add powerpc*-*-*spe*. > (powerpc*-*-*spe*): Delete. > (powerpc-*-eabispe*): Delete. > (powerpc-*-rtems*spe*): Delete. > (powerpc*-*-linux*spe*): Delete. > (powerpc*-*-linux*): Do not handle the linux*spe* targets. > (powerpc-wrs-vxworks*spe): Delete. > (with_cpu setting code): Delete powerpc*-*-*spe* handling. > * gcc/config.host (target powerpc*-*-*spe*): Delete. > * gcc/doc/invoke.texi (PowerPC SPE Options): Delete. > (PowerPC SPE Options): Delete. > * gcc/config/powerpcspe: Delete. I'm all for it. Let's give Jakub and Richi and chance to chime in though. Jeff
[PATCH] Delete powerpcspe
This deletes powerpcspe, which was deprecated for GCC 8.
I'm not including the rm -r gcc/config/powerpcspe part in the patch,
see the diffstat summary for why.
This does not change the testsuite, or libgcc for rs6000 (which still
is shared code with powerpcspe, so can use some cleanup after this).
Tested building a powerpc-linux_spe target; it now is refused.
Is this okay for trunk?
Segher
2018-12-03 Segher Boessenkool
* contrib/config-list.mk: Remove powerpc-eabispe and powerpc-linux_spe.
* gcc/config.gcc (Obsolete configurations): Delete powerpc*-*-*spe*.
(Unsupported targets): Add powerpc*-*-*spe*.
(powerpc*-*-*spe*): Delete.
(powerpc-*-eabispe*): Delete.
(powerpc-*-rtems*spe*): Delete.
(powerpc*-*-linux*spe*): Delete.
(powerpc*-*-linux*): Do not handle the linux*spe* targets.
(powerpc-wrs-vxworks*spe): Delete.
(with_cpu setting code): Delete powerpc*-*-*spe* handling.
* gcc/config.host (target powerpc*-*-*spe*): Delete.
* gcc/doc/invoke.texi (PowerPC SPE Options): Delete.
(PowerPC SPE Options): Delete.
* gcc/config/powerpcspe: Delete.
---
151 files changed, 3 insertions(+), 112988 deletions(-)
diff --git a/contrib/config-list.mk b/contrib/config-list.mk
index cbb9e28b..5acd766 100644
--- a/contrib/config-list.mk
+++ b/contrib/config-list.mk
@@ -73,9 +73,9 @@ LIST = aarch64-elf aarch64-linux-gnu aarch64-rtems \
pdp11-aout \
powerpc-darwin8 \
powerpc-darwin7 powerpc64-darwin powerpc-freebsd6 powerpc-netbsd \
- powerpc-eabispe powerpc-eabisimaltivec powerpc-eabisim ppc-elf \
+ powerpc-eabisimaltivec powerpc-eabisim ppc-elf \
powerpc-eabialtivec powerpc-xilinx-eabi powerpc-eabi \
- powerpc-rtems powerpc-linux_spe \
+ powerpc-rtems \
powerpc64-linux_altivec \
powerpc-wrs-vxworks powerpc-wrs-vxworksae powerpc-wrs-vxworksmils \
powerpc-lynxos powerpcle-elf \
diff --git a/gcc/config.gcc b/gcc/config.gcc
index cbabd21..d35103e 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -248,7 +248,6 @@ md_file=
# Obsolete configurations.
case ${target} in
*-*-solaris2.10* \
- | powerpc*-*-*spe* \
| tile*-*-* \
)
if test "x$enable_obsolete" != xyes; then
@@ -279,6 +278,7 @@ case ${target} in
| mips64orion*-*-rtems* \
| pdp11-*-bsd \
| powerpc*-*-linux*paired*\
+ | powerpc*-*-*spe*\
| sparc-hal-solaris2* \
| thumb-*-* \
| *-*-freebsd[12] | *-*-freebsd[1234].* \
@@ -488,16 +488,6 @@ nvptx-*-*)
or1k*-*-*)
cpu_type=or1k
;;
-powerpc*-*-*spe*)
- cpu_type=powerpcspe
- extra_headers="ppc-asm.h altivec.h spe.h ppu_intrinsics.h paired.h
spu2vmx.h vec_types.h si2vmx.h htmintrin.h htmxlintrin.h"
- case x$with_cpu in
-
xpowerpc64|xdefault64|x6[23]0|x970|xG5|xpower[3456789]|xpower6x|xrs64a|xcell|xa2|xe500mc64|xe5500|xe6500)
- cpu_is_64bit=yes
- ;;
- esac
- extra_options="${extra_options} g.opt fused-madd.opt
powerpcspe/powerpcspe-tables.opt"
- ;;
powerpc*-*-*)
cpu_type=rs6000
extra_objs="rs6000-string.o rs6000-p8swap.o"
@@ -2588,12 +2578,6 @@ powerpc-*-netbsd*)
tmake_file="${tmake_file} rs6000/t-netbsd"
extra_options="${extra_options} rs6000/sysv4.opt"
;;
-powerpc-*-eabispe*)
- tm_file="${tm_file} dbxelf.h elfos.h freebsd-spec.h newlib-stdint.h
${cpu_type}/sysv4.h ${cpu_type}/eabi.h ${cpu_type}/e500.h ${cpu_type}/eabispe.h"
- extra_options="${extra_options} ${cpu_type}/sysv4.opt"
- tmake_file="${cpu_type}/t-spe ${cpu_type}/t-ppccomm"
- use_gcc_stdint=wrap
- ;;
powerpc-*-eabisimaltivec*)
tm_file="${tm_file} dbxelf.h elfos.h gnu-user.h freebsd-spec.h
newlib-stdint.h rs6000/sysv4.h rs6000/eabi.h rs6000/eabisim.h
rs6000/eabialtivec.h"
extra_options="${extra_options} rs6000/sysv4.opt"
@@ -2623,26 +2607,11 @@ powerpc-*-eabi*)
tmake_file="rs6000/t-fprules rs6000/t-ppcgas rs6000/t-ppccomm"
use_gcc_stdint=wrap
;;
-powerpc-*-rtems*spe*)
- tm_file="${tm_file} dbxelf.h elfos.h freebsd-spec.h newlib-stdint.h
powerpcspe/sysv4.h powerpcspe/eabi.h powerpcspe/e500.h powerpcspe/rtems.h
rtems.h"
- extra_options="${extra_options} powerpcspe/sysv4.opt"
- tmake_file="${tmake_file} powerpcspe/t-fprules powerpcspe/t-rtems
powerpcspe/t-ppccomm"
- ;;
powerpc-*-rtems*)
tm_file="rs6000/biarch64.h ${tm_file} dbxelf.h elfos.h gnu-user.h
freebsd-spec.h newlib-stdint.h rs6000/sysv4.h rs6000/rtems.h rtems.h"
extra_options="${extra_options} rs6000/sysv4.opt rs6000/linux64.opt"
tmake_file="${tmake_file} rs6000/t-fprules rs6000/t-rtems
rs6000/t-ppccomm"
;;
-powerpc*-*-linux*spe*)
- tm_file="${tm_file} dbxelf.h elfos.h gnu-user.h freebsd-spec.h
po
