Re: [PATCH] Delete powerpcspe

[Iain Sandoe <idsandoe@googlemail.com>]

> On 14 Dec 2018, at 08:20, Segher Boessenkool <segher@kernel.crashing.org> 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 <law@redhat.com> 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