On Wed, Nov 21, 2018 at 08:12:44PM +0100, Jakub Jelinek wrote:
> On Wed, Nov 21, 2018 at 12:07:51PM -0600, Segher Boessenkool wrote:
> > > Admittedly, it might be better if the initializer was 0x1010101 or say
> > > 0x4030201 because on big endian in particular 0x10101 has the top 15 bits
> > > all zero and thus that is what is in u.f1, so if the bug can be reproduced
> > > with the combine.c + rtlanal.c fix reverted with 0x4030201, it would be
> > > better to use that value (in both spots).
> >
> > Yeah good point.
>
> I've now managed to test this with a cross to armv7hl (scped to an arm box)
> with and without the rtlanal.c + combine.c change reverted and on
> powerpc64-linux as example of big-endian, on armv7hl it still fails with
> the changes reverted, otherwise it succeeds on both. The test also needs
> 32-bit int target (previously just 17-bit or more, so I've added effective
> target).
It fixes the problem on powerpc64-linux {-m32,-m64}. Thanks :-)
Segher
