On Wed, 1 Aug 2018 at 11:40, Segher Boessenkool <seg...@kernel.crashing.org> wrote: > > On Wed, Aug 01, 2018 at 10:27:31AM +0200, Christophe Lyon wrote: > > On Tue, 31 Jul 2018 at 15:57, Segher Boessenkool > > <seg...@kernel.crashing.org> wrote: > > > On Tue, Jul 31, 2018 at 02:34:06PM +0200, Christophe Lyon wrote: > > > > Since this was committed, I've noticed regressions > > > > on aarch64: > > > > FAIL: gcc.dg/zero_bits_compound-1.c scan-assembler-not \\(and: > > > > > > This went from > > > and w0, w0, 255 > > > lsl w1, w0, 8 > > > orr w0, w1, w0, lsl 20 > > > ret > > > to > > > and w1, w0, 255 > > > ubfiz w0, w0, 8, 8 > > > orr w0, w0, w1, lsl 20 > > > ret > > > so it's neither an improvement nor a regression, just different code. > > > The testcase wants no ANDs in the RTL. > > > > I didn't try to manually regenerate the code before and after the patch, > > but if there was "and w0, w0, 255" before the patch, why did the test > > pass? > > It wasn't an AND in RTL (it was a ZERO_EXTEND). >
Indeed, I missed the -dP in the options. > > > > on arm-none-linux-gnueabi > > > > FAIL: gfortran.dg/actual_array_constructor_1.f90 -O1 execution test > > > > > > That sounds bad. Open a PR, maybe? > > > > > I've just filed PR86771 > > Thanks. > > > Segher
