[Bug fortran/30834] ICE with kind=8 exponentiaton
--- Comment #15 from fxcoudert at gcc dot gnu dot org 2007-03-23 07:01 --- Subject: Bug 30834 Author: fxcoudert Date: Fri Mar 23 07:00:56 2007 New Revision: 123154 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123154 Log: PR fortran/30834 * arith.c (complex_pow): Rewrite to handle large power. (gfc_arith_power): Handle large power in the real and integer cases. * gfortran.dg/integer_exponentiation_3.F90: New test. * gfortran.dg/integer_exponentiation_4.f90: New test. * gfortran.dg/integer_exponentiation_5.F90: New test. Added: trunk/gcc/testsuite/gfortran.dg/integer_exponentiation_3.F90 trunk/gcc/testsuite/gfortran.dg/integer_exponentiation_4.f90 trunk/gcc/testsuite/gfortran.dg/integer_exponentiation_5.F90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/arith.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30834
[Bug fortran/30834] ICE with kind=8 exponentiaton
--- Comment #16 from fxcoudert at gcc dot gnu dot org 2007-03-23 07:02 --- Fixed on mainline, will not backport to 4.2 as it's not a regression. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30834
[Bug fortran/30834] ICE with kind=8 exponentiaton
--- Comment #14 from fxcoudert at gcc dot gnu dot org 2007-03-21 09:13 --- Yet another wrinkle found (with -fno-range-check and crazily large integers), yet another patch: http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01398.html This one looks final to me, though :) -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||03/msg01398.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30834
[Bug fortran/30834] ICE with kind=8 exponentiaton
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-02-17 18:36:03 |2007-03-19 08:29:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30834
[Bug fortran/30834] ICE with kind=8 exponentiaton
--- Comment #11 from fxcoudert at gcc dot gnu dot org 2007-03-18 09:36 --- (In reply to comment #10) Looking at your patch, I have identified one compile-time hog in complex_pow_ui: $ time gfortran complex.f90 I identified the same after some more thinking. The fast exponentiation algorithm in the library seems fine. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30834
[Bug fortran/30834] ICE with kind=8 exponentiaton
--- Comment #12 from fxcoudert at gcc dot gnu dot org 2007-03-18 14:29 --- Created an attachment (id=13227) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13227action=view) New patch New patch, without the compile-time hog for complex. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Attachment #13222|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30834
[Bug fortran/30834] ICE with kind=8 exponentiaton
--- Comment #13 from tkoenig at gcc dot gnu dot org 2007-03-18 19:46 --- (In reply to comment #12) Created an attachment (id=13227) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13227action=view) [edit] New patch New patch, without the compile-time hog for complex. This is looking really good. It survived everything I could think of throwing at it. If you want to, you could use mpz_congruent_2exp_p and mpz_cdiv_q_2exp for checking for an even number and for dividing by two for a (probaly very minor) gain in efficiency. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30834
[Bug fortran/30834] ICE with kind=8 exponentiaton
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2007-03-17 18:45 --- Created an attachment (id=13222) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13222action=view) Proposed patch I think the attached patch would fix this bug. It's a significant rewrite of the arith.c code to: * handle the case of large integer exponents for both complex and real; I do it by not extracting an int from the exponent, but simply handle the mpz_t throughout * rewrite completely the integer**integer case, because it had other problems, such as the following: $ cat c.f90 print *, 0**(-1) end $ gfortran c.f90 c.f90:0: internal compiler error: Floating point exception All testcases reported are fixed. I don't have any more time to work on this now, if one of you want to try the patch on the corner cases you can imagine, I'd appreciate that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30834
[Bug fortran/30834] ICE with kind=8 exponentiaton
--- Comment #10 from tkoenig at gcc dot gnu dot org 2007-03-17 22:06 --- Hi FX, I'll look at this. Looking at your patch, I have identified one compile-time hog in complex_pow_ui: $ time gfortran complex.f90 real3m35.506s user3m35.329s sys 0m0.156s $ cat complex.f90 program main print *,(1.0, 0.0)**(2**30) end program main We should use the same algorithm as in the library (in pow.m4). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30834
[Bug fortran/30834] ICE with kind=8 exponentiaton
--- Comment #7 from tkoenig at gcc dot gnu dot org 2007-02-19 21:11 --- (In reply to comment #6) Feel free to create a gfc_extract_long_long and document that e is constrained to be within [LONG_LONG_MIN, LONG_LONG_MAX]. Suppose we don't simplify if gfc_extract_int fails. Would that cause anything bad (like an ICE further down thr road)? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30834
[Bug fortran/30834] ICE with kind=8 exponentiaton
--- Comment #8 from sgk at troutmask dot apl dot washington dot edu 2007-02-19 21:49 --- Subject: Re: ICE with kind=8 exponentiaton On Mon, Feb 19, 2007 at 09:11:45PM -, tkoenig at gcc dot gnu dot org wrote: Feel free to create a gfc_extract_long_long and document that e is constrained to be within [LONG_LONG_MIN, LONG_LONG_MAX]. Suppose we don't simplify if gfc_extract_int fails. Would that cause anything bad (like an ICE further down thr road)? gfc_arith_power is expected to return one of ARITH_OK, ARITH_OVERFLOW, ARITH_UNDERFLOW, ARITH_NAN, ARITH_DIV0, ARITH_INCOMMENSURATE, or ARITH_ASYMMETRIC. We would need to prevent the call to gfc_arith_power in the special case of e not in [INT_MIN, INT_MAX]. A quick grep shows that gfc_arith_power is called from gfc_power, and laptop:kargl[261] grep gfc_power *c arith.c:gfc_power (gfc_expr *op1, gfc_expr *op2) expr.c: result = gfc_power (op1, op2); matchexp.c: r = gfc_power (e, exp); A glance at expr.c and matchexp.c suggests that a change to potentially call one of libgfortran's pow_* function would be nontrivial. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30834
[Bug fortran/30834] ICE with kind=8 exponentiaton
--- Comment #1 from tkoenig at gcc dot gnu dot org 2007-02-17 15:22 --- The test case was missing :-) Here it is: $ cat pow.f90 program pow print *,1.0**(2_8**33_8) end program pow -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30834
[Bug fortran/30834] ICE with kind=8 exponentiaton
--- Comment #2 from pault at gcc dot gnu dot org 2007-02-17 17:55 --- Yup! Does it for me too. Thanks, Thomas Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-02-17 17:55:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30834
[Bug fortran/30834] ICE with kind=8 exponentiaton
--- Comment #3 from kargl at gcc dot gnu dot org 2007-02-17 18:36 --- Yup, these lines in gfc_arith_power make the assumption that we'll never have an integer exponent outside the range INT_MIN to INT_MAX. if (gfc_extract_int (op2, power) != NULL) gfc_internal_error (gfc_arith_power(): Bad exponent); -- kargl at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2007-02-17 17:55:42 |2007-02-17 18:36:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30834
[Bug fortran/30834] ICE with kind=8 exponentiaton
--- Comment #4 from kargl at gcc dot gnu dot org 2007-02-17 21:10 --- After looking at this a little bit, I think we may want to change the error message to report the invalid integer exponent value and document that INT_MIN = e = INT_MAX. Why? Well, other than the special values of 1 and 0, the evaluation of x**e will exceed the range of x. -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||kargl at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30834
[Bug fortran/30834] ICE with kind=8 exponentiaton
--- Comment #5 from tkoenig at gcc dot gnu dot org 2007-02-17 21:27 --- After looking at this a little bit, I think we may want to change the error message to report the invalid integer exponent value and document that INT_MIN = e = INT_MAX. Why? Well, other than the special values of 1 and 0, the evaluation of x**e will exceed the range of x. I don't think this is the case: $ cat foo.f90 program main real(kind=8) :: a integer(kind=8) :: n n = 2_8**32 a = 1_8 + epsilon(a) print *,a**n end program main $ gfortran foo.f90 $ ./a.out 1.0095367477 I do admit this is a corner case, though :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30834
[Bug fortran/30834] ICE with kind=8 exponentiaton
--- Comment #6 from sgk at troutmask dot apl dot washington dot edu 2007-02-17 21:51 --- Subject: Re: ICE with kind=8 exponentiaton On Sat, Feb 17, 2007 at 09:27:07PM -, tkoenig at gcc dot gnu dot org wrote: After looking at this a little bit, I think we may want to change the error message to report the invalid integer exponent value and document that INT_MIN = e = INT_MAX. Why? Well, other than the special values of 1 and 0, the evaluation of x**e will exceed the range of x. I don't think this is the case: $ cat foo.f90 program main real(kind=8) :: a integer(kind=8) :: n n = 2_8**32 a = 1_8 + epsilon(a) print *,a**n end program main $ gfortran foo.f90 $ ./a.out 1.0095367477 I do admit this is a corner case, though :-) OK, for numbers outside the nominal range of x in (1_8 - 1.651e-7_8, 1_8 + 1.651e-7_8), then x**e and e = INT_MAX you have problems. There is also a range (-f,f) with f 1 where e could exceed the range [INT_MIN, INT_MAX]. I'm too lazy to determin f. Feel free to create a gfc_extract_long_long and document that e is constrained to be within [LONG_LONG_MIN, LONG_LONG_MAX]. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30834
