Executing on host: /test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../gfortran -B /test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../ /test/gnu/gcc/gcc/gcc/testsui te/gfortran.dg/integer_exponentiation_2.f90 -O1 -L/test/gnu/gcc/objdir/hppa 64-hp-hpux11.11/./libgfortran/.libs -L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/. /libgfortran/.libs -L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libiberty -lm -o ./integer_exponentiation_2.exe (timeout = 300) PASS: gfortran.dg/integer_exponentiation_2.f90 -O1 (test for excess errors) Setting LD_LIBRARY_PATH to .:/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgfort ran/.libs:/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgfortran/.libs:/test/gnu /gcc/objdir/gcc:.:/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgfortran/.libs:/ test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libgfortran/.libs:/test/gnu/gcc/objdir /gcc FAIL: gfortran.dg/integer_exponentiation_2.f90 -O1 execution test
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.