[Bug fortran/31215] ICE on valid code with gfortran
--- Comment #4 from pault at gcc dot gnu dot org 2007-03-24 12:31 --- Subject: Bug 31215 Author: pault Date: Sat Mar 24 12:30:58 2007 New Revision: 123183 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123183 Log: 2007-03-24 Paul Thomas [EMAIL PROTECTED] PR fortran/31215 * trans-expr.c (gfc_apply_interface_mapping_to_expr): Return int result that is non-zero if the expression is the function result. Only the characteristics of the result expression can be used in a procedure interface, so simplify LEN in situ using its character length. PR fortran/31219 PR fortran/31200 * trans-expr.c (gfc_conv_function_call): Do not use gfc_conv_expr_reference for actual pointer function with formal target because a temporary is created that does not transfer the reference correctly. Do not indirect formal pointer functions since it is the function reference that is needed. 2007-03-24 Paul Thomas [EMAIL PROTECTED] PR fortran/31219 * gfortran.dg/pointer_function_actual_1.f90: New test. PR fortran/31200 * gfortran.dg/pointer_function_actual_2.f90: New test. PR fortran/31215 * gfortran.dg/result_in_spec_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pointer_function_actual_1.f90 trunk/gcc/testsuite/gfortran.dg/pointer_function_actual_2.f90 trunk/gcc/testsuite/gfortran.dg/result_in_spec_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31215
[Bug fortran/31215] ICE on valid code with gfortran
--- Comment #5 from pault at gcc dot gnu dot org 2007-03-24 13:57 --- Fixed on trunk Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31215
[Bug fortran/31215] ICE on valid code with gfortran
--- Comment #6 from pault at gcc dot gnu dot org 2007-03-24 14:17 --- Subject: Bug 31215 Author: pault Date: Sat Mar 24 14:17:34 2007 New Revision: 123184 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123184 Log: 2007-03-24 Paul Thomas [EMAIL PROTECTED] PR fortran/31215 * trans-expr.c (gfc_apply_interface_mapping_to_expr): Return int result that is non-zero if the expression is the function result. Only the characteristics of the result expression can be used in a procedure interface, so simplify LEN in situ using its character length. PR fortran/31219 PR fortran/31200 * trans-expr.c (gfc_conv_function_call): Do not use gfc_conv_expr_reference for actual pointer function with formal target because a temporary is created that does not transfer the reference correctly. Do not indirect formal pointer functions since it is the function reference that is needed. 2007-03-24 Paul Thomas [EMAIL PROTECTED] PR fortran/31219 * gfortran.dg/pointer_function_actual_1.f90: New test. PR fortran/31200 * gfortran.dg/pointer_function_actual_2.f90: New test. PR fortran/31215 * gfortran.dg/result_in_spec_1.f90: New test. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/pointer_function_actual_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31215
[Bug fortran/31215] ICE on valid code with gfortran
--- Comment #3 from pault at gcc dot gnu dot org 2007-03-20 10:09 --- All compilers I know reject this code, except g95. The list includes Lahey, which is a reason for me to doubt whether this code is legal or not. The code is legal because the interface to test2 only needs the characteristics of the result to convert the actual arguments and to allocate space for the temporary. In any case, an ICE is an error. Yes indeed! This is one of the most difficult diagnostic problems that I have faced with gfortran. It should be noted that character(10) :: ch(3) ... ch = test2(0) compiles and runs correctly. After a lot of head scratching and adding diagnostics all over the place, I found that the reason for this is that the compiler is able to take the lhs to determine the scalarization loop size, whereas this is not possible for write(*,*) len(test2(10)) The compiler is failing in trans-array.c (gfc_set_loop_bounds_from_array_spec), during the calls to gfc_apply_interface_mapping. If the block for upper is substituted by upper = gfc_index_one_node, the code compiles; it cannot run correctly because the temporary descriptor does not have the right bounds and the data allocation is incorrect. Apparently, the interface mapping is failing to substitute the actual values correctly and should, in any case treat LEN as a special case by substituting LEN (arg) by the expression for the character length of the argument. I am on to it! Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added CC||pault at gcc dot gnu dot org AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-20 10:09:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31215
[Bug fortran/31215] ICE on valid code with gfortran
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-03-16 15:37 --- All compilers I know reject this code, except g95. The list includes Lahey, which is a reason for me to doubt whether this code is legal or not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31215
[Bug fortran/31215] ICE on valid code with gfortran
--- Comment #2 from burnus at gcc dot gnu dot org 2007-03-16 15:56 --- (In reply to comment #1) All compilers I know reject this code, except g95. The list includes Lahey, which is a reason for me to doubt whether this code is legal or not. NAG f95 and g95 compile it and output: 21 ABCDEFGHIJKLMNOPQRSTUABCDEFGHIJKLMNOPQRSTUABCDEFGHIJKLMNOPQRSTU (ifort, sunf95 write: dimension r(modulo(len(r)-1,3)+1) ^ fortcom: Error: foo.f90, line 6: The data types of the argument(s) are invalid. [LEN] dimension r(modulo(len(r)-1,3)+1) ^ foo.f90, Line = 6, Column = 33: ERROR: Array R is used recursively to declare its own bounds. In any case, an ICE is an error. -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31215
