[Bug fortran/38822] Compile-time simplification of x**(real) / ICE in in gfc_target_encode_expr
--- Comment #9 from kargl at gcc dot gnu dot org 2009-03-29 20:41 --- The ICE is fixed by revision 145261. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38822
[Bug fortran/38822] Compile-time simplification of x**(real) / ICE in in gfc_target_encode_expr
--- Comment #7 from kargl at gcc dot gnu dot org 2009-01-20 19:22 --- I have a patch that not only fixes the ICE, but it will issue an error for a program of the form troutmask:sgk[203] cat a.f90 program a real z(int(transfer(2.e0**2.e0, 1.e0)) + 1) z = 1. print '(5ES12.5)', z end program a troutmask:sgk[204] gfc4x -o z a.f90 troutmask:sgk[205] ./z 1.0E+00 1.0E+00 1.0E+00 1.0E+00 1.0E+00 troutmask:sgk[206] gfc4x -o z -std=f95 a.f90 a.f90:2.32: real z(int(transfer(2.e0**2.e0, 1.e0)) + 1) 1 Error: Fortran 2003: Noninteger exponent in an initialization expression at (1) Note, I plan to change the word initialization to restricted. -- kargl at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |kargl at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Priority|P3 |P4 Last reconfirmed|-00-00 00:00:00 |2009-01-20 19:22:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38822
[Bug fortran/38822] Compile-time simplification of x**(real) / ICE in in gfc_target_encode_expr
--- Comment #8 from kargl at gcc dot gnu dot org 2009-01-20 19:41 --- (In reply to comment #7) I have a patch that not only fixes the ICE, but it will issue an error for a program of the form troutmask:sgk[203] cat a.f90 program a real z(int(transfer(2.e0**2.e0, 1.e0)) + 1) z = 1. print '(5ES12.5)', z end program a troutmask:sgk[204] gfc4x -o z a.f90 troutmask:sgk[205] ./z 1.0E+00 1.0E+00 1.0E+00 1.0E+00 1.0E+00 troutmask:sgk[206] gfc4x -o z -std=f95 a.f90 a.f90:2.32: real z(int(transfer(2.e0**2.e0, 1.e0)) + 1) 1 Error: Fortran 2003: Noninteger exponent in an initialization expression at (1) Note, I plan to change the word initialization to restricted. Dang, I got this wrong. There is a distinction between an initialization and specification expressions where a non-integer exponent is indeed allowed in the latter and prohibited in the former. I, at least, still have the ICE fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38822
[Bug fortran/38822] Compile-time simplification of x**(real) / ICE in in gfc_target_encode_expr
--- Comment #3 from kargl at gcc dot gnu dot org 2009-01-16 00:55 --- (In reply to comment #2) Before closing, please also check the two longer cases: http://groups.google.com/group/comp.lang.fortran/msg/97c3ce6e98432ae9 and the older (partially incorrect?) one at http://groups.google.com/group/comp.lang.fortran/msg/c71f697c3e21e3f2 Well, both programs compile with my patch that allows 2.e0**2.e0 to compile. troutmask:sgk[220] gfc4x -o z j2.f90 troutmask:sgk[221] ./z T T troutmask:sgk[222] gfc4x -o z -std=f95 j1.f90 troutmask:sgk[223] ./z T T I haven't unraveled James' argument that the correct answer is T F. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38822
[Bug fortran/38822] Compile-time simplification of x**(real) / ICE in in gfc_target_encode_expr
--- Comment #4 from kargl at gcc dot gnu dot org 2009-01-16 02:47 --- I think I know how to fix this. I'll note that James' clever programs may be invoking processor defined behavior due to the multiplication by 0 in his specification statements. See 7.1.8.1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38822
[Bug fortran/38822] Compile-time simplification of x**(real) / ICE in in gfc_target_encode_expr
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2009-01-16 02:57 --- ifort (IFORT) 10.1 20080801 Copyright (C) 1985-2008 Intel Corporation. All rights reserved. $ ./a.out T F I want to get my head around this too. :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38822
[Bug fortran/38822] Compile-time simplification of x**(real) / ICE in in gfc_target_encode_expr
--- Comment #6 from kargl at gcc dot gnu dot org 2009-01-16 05:26 --- (In reply to comment #5) ifort (IFORT) 10.1 20080801 Copyright (C) 1985-2008 Intel Corporation. All rights reserved. $ ./a.out T F I want to get my head around this too. :) Note, there are 2 separate programs. Both should give 'T F' according to James. He had a bug in the first program that gives the 'correct' answer with several compilers. His corrected program shows that Intel gets the wrong answer 'T T'. The gist of his argument is that in F95 a REAL exponent is not permitted in an initialization expression. This then means that the array 'z(0*transfer(2.d0**2.)+2)' is an automatic array. An automatic array is not saved with a blank SAVE statement, and so it can't retain its values when the routine returns. There may be some processor-dependent behavior here. A Fortran processor does not have to evaluate the transfer() and its arguments because the multiplication by 0 will always result in zero. See 7.1.8.1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38822
[Bug fortran/38822] Compile-time simplification of x**(real) / ICE in in gfc_target_encode_expr
--- Comment #2 from burnus at gcc dot gnu dot org 2009-01-14 15:30 --- Before closing, please also check the two longer cases: http://groups.google.com/group/comp.lang.fortran/msg/97c3ce6e98432ae9 and the older (partially incorrect?) one at http://groups.google.com/group/comp.lang.fortran/msg/c71f697c3e21e3f2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38822
[Bug fortran/38822] Compile-time simplification of x**(real) / ICE in in gfc_target_encode_expr
--- Comment #1 from burnus at gcc dot gnu dot org 2009-01-13 16:33 --- The problem is the following in arith.c: if (op == INTRINSIC_POWER op2-ts.type != BT_INTEGER) goto runtime; Thus it is only run-time evaluated. gfc_arith_power deals so far only with (numeric_type)**(integer). We need to handle (complex)**(complex) and (real)**(real). I think Fortran 2003 allows ** in initialization expressions (at least I could not find anything else) and thus one needs this. See also PR 38823. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Summary|ICE in in |Compile-time simplification |gfc_target_encode_expr |of x**(real) / ICE in in ||gfc_target_encode_expr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38822
