I have looked into this bug and I think it is an HP math lib bug.  The 64 bit
powf function is using %fr12R but not saving/restoring it the way it is supposed to.  I have a query in to the math lib folks to see if they can verify my finding.

Here is a smaller test case that prints different values at -O1 or -O2 than at -O0.

program test
  real a
  call run_me (-1.1, -1)
  a = -1.1
end program test

subroutine run_me(a, i)
  implicit none

  real, intent(in) :: a
  integer, intent(in) :: i
  print *, a**-2.0
  print *, (1/a)*(1/a)
  call check_equal_r (a**-2.0, (1/a)*(1/a))
end subroutine run_me

subroutine check_equal_r (a, b)
  real, intent(in) :: a, b
  print *, a
  print *, b
end subroutine check_equal_r

To implement PR32239, integer exponention was changed recently:

2007-07-01  Janne Blomqvist  <jb@gcc.gnu.org>

        PR fortran/32239
        * trans-expr.c (gfc_conv_power_op): Use builtin_powi for
        real**int4 powers.
        * f95-lang.c (gfc_init_builtin_functions): Add builtin_powi to the
        builtins table.

By any chance, does it make any differences for this testcase?

I don't know.  I haven't been able to bootstrap hppa64-hp-hpux11.11 since
the dataflow merge.  The following two tests are failing on hppa2.0w-hp-hpux11.11 (revision 126397):

FAIL: gfortran.dg/integer_exponentiation_2.f90  -O3 -fomit-frame-pointer -funrol
l-loops  execution test
FAIL: gfortran.dg/integer_exponentiation_2.f90  -O3 -fomit-frame-pointer -funrol
l-all-loops -finline-functions  execution test

(In reply to comment #1)
> I have looked into this bug and I think it is an HP math lib bug.  The 64 bit
> powf function is using %fr12R but not saving/restoring it the way it is
> supposed to.  I have a query in to the math lib folks to see if they can verify
> my finding.

Any results? I cannot reproduce this on hppa2.0w-hp-hpux11.31 (neither the original bug nor your testcase that gives different results depending on optimization level).

Subject: Re:  FAIL: gfortran.dg/integer_exponentiation_2.f90 at -O1 and above

> Any results? I cannot reproduce this on hppa2.0w-hp-hpux11.31 (neither the
> original bug nor your testcase that gives different results depending on
> optimization level).

To reproduce the original bug, you would need to build for
hppa64-hp-hpux11.31 target.  If you bootstrap with an HP compiler,
you would need to add +DA2.0W to the stage1 CFLAGS.  The two targets
use different math libraries.

The hppa64 problem was still present in my last build prior to
the lroundl issue.  Somewhere between August 4 and 8 bootstrap
started to fail on this target.

I also still see the fails mentioned in comment #3.  See
http://gcc.gnu.org/ml/gcc-testresults/2007-08/msg00236.html
This might be a different bug.

Dave

I agree with Steve that this is a HP math lib bug.  For Steve's test
program, we have the following code at -O1:

        fldw 0(%r3),%fr12R
        fcpy,sgl %fr12R,%fr4R
        fcpy,sgl %fr13R,%fr5R
        ldo -48(%r30),%r29
        b,l powf,%r2
        copy %r27,%r4
        copy %r4,%r27
        fstw %fr4R,-1176(%r30)
        fdiv,sgl %fr14R,%fr12R,%fr12R
        fmpy,sgl %fr12R,%fr12R,%fr12R
        fstw %fr12R,-1172(%r30)
        ldo -1176(%r30),%r26
        ldo -48(%r30),%r29
        b,l check_equal_r_,%r2
        ldo -1172(%r30),%r25

Checking the value of fr12R before and after the call to powf, I see the values
differ.  The runtime specification states on page 14 that FRs 12-21 are preserved across calls.

I think this bug can be worked around by providing powf in libgfortran on this
target.

Patch here:
http://gcc.gnu.org/ml/fortran/2008-12/msg00315.html

Subject: Bug 31832

Author: danglin
Date: Mon Dec 29 20:10:00 2008
New Revision: 142952

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142952
Log:
	PR fortran/31832
	* acinclude.m4 (LIBGFOR_CHECK_FOR_BROKEN_POWF): New autoconf check for
	broken powf.
	* configure.ac (LIBGFOR_CHECK_FOR_BROKEN_POWF): Use it.
	* intrinsics/c99_functions.c: Use internal powf implementation if
	HAVE_BROKEN_POWF is defined.
	* configure: Rebuilt.
	* config.h.in: Rebuilt.


Modified:
    trunk/libgfortran/ChangeLog
    trunk/libgfortran/acinclude.m4
    trunk/libgfortran/config.h.in
    trunk/libgfortran/configure
    trunk/libgfortran/configure.ac
    trunk/libgfortran/intrinsics/c99_functions.c

Subject: Bug 31832

Author: danglin
Date: Wed Dec 31 15:42:12 2008
New Revision: 142984

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142984
Log:
	PR fortran/31832
	* acinclude.m4 (LIBGFOR_CHECK_FOR_BROKEN_POWF): New autoconf check for
	broken powf.
	* configure.ac (LIBGFOR_CHECK_FOR_BROKEN_POWF): Use it.
	* intrinsics/c99_functions.c: Use internal powf implementation if
	HAVE_BROKEN_POWF is defined.
	* configure: Rebuilt.
	* config.h.in: Rebuilt.


Modified:
    branches/gcc-4_3-branch/libgfortran/ChangeLog
    branches/gcc-4_3-branch/libgfortran/acinclude.m4
    branches/gcc-4_3-branch/libgfortran/config.h.in
    branches/gcc-4_3-branch/libgfortran/configure
    branches/gcc-4_3-branch/libgfortran/configure.ac
    branches/gcc-4_3-branch/libgfortran/intrinsics/c99_functions.c

Fixed.