http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61114
--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #6)
> (In reply to Tejas Belagod from comment #5)
> > So, does that mean the folded value 120 is in the wrong place? The fix that
> > I'm testing swaps the first and last elements of the const vector {120, 0,
> > 0, 0}.
> >
> > PS: Sorry, my statement "The final folded value is extracted from the LSB
> > which are bits 32:96 on BE systems" should have read "The final folded value
> > is extracted from the LSB which are bits 96..127 on BE systems" if that
> > caused confusion.
>
> But that's the bug. The final value should _always_ be extracted from
> 0..31. That is, the folding is perfectly ok given the description of
> REDUC_PLUS_EXPR.
>
> So - it looks like the target does something wrong for expansion of
> REDUC_PLUS_EXPR.
That is, all code conditional on BYTES/WORDS_BIG_ENDIAN in tree-vect* is
suspicious.
