[Bug fortran/31215] New: ICE on valid code with gfortran

[Bug fortran/31215] New: ICE on valid code with gfortran

[jv244 at cam dot ac dot uk]

A recent gfortran ICEs on the following code:

module test1
   implicit none
   contains
      character(f(x)) function test2(x) result(r)
         implicit integer (x)
         dimension r(modulo(len(r)-1,3)+1)
         integer, intent(in) :: x
         interface
            pure function f(x)
               integer, intent(in) :: x
               integer f
            end function f
         end interface
         integer i

         do i = 1, len(r)
            r(:)(i:i) = achar(mod(i,32)+iachar('@'))
         end do
      end function test2
end module test1

program test
   use test1
   implicit none

   write(*,*) len(test2(10))
   write(*,*) test2(10)
end program test

pure function f(x)
   integer, intent(in) :: x
   integer f

   f = 2*x+1
end function f


-- 
           Summary: ICE on valid code with gfortran
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: jv244 at cam dot ac dot uk


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31215

[Bug fortran/31215] ICE on valid code with gfortran

[fxcoudert at gcc dot gnu dot org]

------- 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

[burnus at gcc dot gnu dot org]

------- 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

[Bug fortran/31215] ICE on valid code with gfortran

[pault at gcc dot gnu dot org]

------- 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|0000-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

[pault at gcc dot gnu dot org]

------- 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=gcc&view=rev&rev=123183
Log:
2007-03-24  Paul Thomas  <pault@gcc.gnu.org>

        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  <pault@gcc.gnu.org>

        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

[pault at gcc dot gnu dot org]

------- 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

[pault at gcc dot gnu dot org]

------- 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=gcc&view=rev&rev=123184
Log:
2007-03-24  Paul Thomas  <pault@gcc.gnu.org>

        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  <pault@gcc.gnu.org>

        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