Hi Thomas, That's OK for 7- through 9-branches.
Thanks for the fix. Paul On Sun, 16 Dec 2018 at 22:01, Thomas Koenig <tkoe...@netcologne.de> wrote: > > Hello world, > > the PR pointed out an old regression because the front-end optimization > pass was substituting 2**n with ishift(1,n), where n was an array. > > Simply removing the optimization for that case would have been easy, > but also introduced a performance regression. > > So, for this, I moved the optimization to trans-*, where it makes more > sense. > > Regression-tested. This turned up that one of our tests, mvbits_1.f90, > depends on the behavior that 2**32 is zero. This is certainly not > guaranteed by the standard, but I chose to keep the behavior as not > to introduce any changes in behavior. > > This fixes a regression, so I would like to backport to all active > branches if this if possible. > > Oh yes, if anybody feels strongly that we should also optimize 32**n > and powers of other powers to two, now is the time to speak up :-) > > OK for affected branches? > > Regards > > Thomas > > 2018-12-16 Thomas Koenig <tkoe...@gcc.gnu.org> > > PR fortran/85544 > * frontend-passes.c (optimize_power): Remove. > (optimize_op): Remove call to optimize_power. > * trans-expr.c (gfc_conv_power_op): Handle cases of 1**integer, > (2|4|8|16) ** integer and (-1) ** integer. > > 2018-12-16 Thomas Koenig <tkoe...@gcc.gnu.org> > > PR fortran/85544 > * gfortran.dg/power_7.f90: New test. -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein