On Mon, 2015-12-21 at 15:22 +0000, Alan Lawrence wrote:
> On 21/12/15 14:59, Bill Schmidt wrote:
> >>>
> >>> On powerpc64, the test passes with -mcpu=power8 (the loop is vectorized
> >>> as a
> >>> reduction); however, without that, similar code is generated to Alpha (the
> >>> vectorizer decides the reduction is not worthwhile without SIMD support),
> >>> and
> >>> the test fails; hence, I've XFAILed for powerpc, but I think I could
> >>> condition
> >>> the XFAIL on powerpc64 && !check_p8vector_hw_available, if preferred?
> >>
> >> Fun.
> >>
> >> Does it work with -mcpu=power7?
>
> Yes, it works with -mcpu=power7, as well as -mcpu=power8, but not e.g.
> -mcpu=power6.
>
> >> Bill: What GCC DejaGNU incantation would you like to see?
> >
> > This sounds like more fallout from unaligned accesses being faster on
> > POWER8 than previous hardware. What about conditioning the XFAIL on
> >
> > { powerpc*-*-* && { ! vect_hw_misalign } }
> >
> > -- does this work properly?
>
> Not on a stage1 compiler - check_p8vector_hw_available itself requires being
> able to run executables - I'll check on gcc112. However, both look like
> they're
> really about the host (ability to execute an asm instruction), not the target
> (/ability for gcc to output such an instruction)....
Hm, that looks like a pervasive problem for powerpc. There are a number
of things that are supposed to be testing effective target but rely on
check_p8vector_hw_available, which as you note requires executing an
instruction and is really about the host. We need to clean that up; I
should probably open a bug. Kind of amazed this has gotten past us for
a couple of years.
For now, just XFAILing for powerpc seems the best alternative for this
test.
Thanks,
Bill
>
> --Alan
>
