[Bug fortran/21104] New: Segmentation fault on correct code

[Bug fortran/21104] New: Segmentation fault on correct code

[paulthomas2 at wanadoo dot fr]

The following reduced program causes a segmentation fault at runtime.  It runs 
correctly if the *x on line 11 is removed.  From this, I would surmise that 
something is not right with the allocation of space for the temporary.  Further 
simplification of the structure of the program eliminates the fault; eg. making 
the function public and moving the expression from the subroutine to the main 
program works correctly.

A quick look with -fdump-tree-original indicates that, in the faulty case, no 
memory is allocated to the function output and its pointer remains NULL.

I have tried putting an explicit interface for generalized_hookes_law in the 
subroutine perdida but this has no effect.

$ cat test_intr.f90
!
!      Copyright (C) 1997 by Quetzal Computational Associates, Inc.
!
module perdida_m
    private :: generalized_hookes_law
    public  :: perdida
    integer, parameter, private  :: LONGreal = selected_real_kind (15, 90)

contains

  subroutine perdida (z, x)
    real (kind = LONGreal), dimension (:,:), intent (inOUT) :: z
    real (kind = LONGreal), dimension (:,:), intent (inOUT) :: x
    z = generalized_hookes_law (x) * x
  end subroutine perdida

  function generalized_hookes_law (x) result (z)
    real (kind = LONGreal), dimension (3,3) :: z
    real (kind = LONGreal), dimension (:,:), intent (in) :: x
    z = x
  end function generalized_hookes_law

end module perdida_m

program iztaccihuatl
  use perdida_m
  integer, parameter  :: LONGreal = selected_real_kind (15, 90)
  real (kind = LONGreal)   ::  x(3,3) = 42.0_LONGreal
  real (kind = LONGreal)   ::  y(3,3)
  call perdida (y, x)
end program iztaccihuatl
THOMASP@PC-THOMAS-P /cygdrive/d/gfortran
$ d:/check/bin/gfortran -std=f95 test_intr.f90

THOMASP@PC-THOMAS-P /cygdrive/d/gfortran
$ ./a
Segmentation fault (core dumped)

-- 
           Summary: Segmentation fault on correct code
           Product: gcc
           Version: 4.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: paulthomas2 at wanadoo dot fr
                CC: Thomas dot Koenig at online dot de,gcc-bugs at gcc dot
                    gnu dot org


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

[Bug fortran/21104] Segmentation fault on correct code

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-19 12:21 -------
I don't think this is correct code.  See PR 20960.  Yes ICC does not seg fault on it.  I will note that XLC 
does the same thing as gfortran.

I also think this is a dup of bug 18197.

-- 


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

[Bug fortran/21104] Segmentation fault on correct code

[paulthomas2 at wanadoo dot fr]

------- Additional Comments From paulthomas2 at wanadoo dot fr  2005-04-19 13:31 -------
Subject: Re:  Segmentation fault on correct code

>
> ------- Additional Comments From pinskia at gcc dot gnu dot org 
> 2005-04-19 12:21 -------
> I don't think this is correct code.  See PR 20960.  Yes ICC does not seg 
> fault on it.  I will note that XLC
> does the same thing as gfortran.
>
I am not sure if it is correct or not; probably not - see below.  This PR, 
20960 and 18197 are clearly related - I did not find them because I looked 
in the summary for segmentation fault rather than bus error.

The difference with 20960 is that an interface for the function, in the 
subroutine, did not fix the problem.  At module level, the private 
declaration prohibits the interface.

> I also think this is a dup of bug 18197.

I agree.  I am just out of the door and on the road for a couple of days. 
As soon as I am back, I willl run these by the Digital compiler, with 
/strict set.  These usually sorts out the wolves in sheep's clothing. 




-- 


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

[Bug fortran/21104] Segmentation fault on correct code

[fxcoudert at gcc dot gnu dot org]

------- Additional Comments From fxcoudert at gcc dot gnu dot org  2005-04-19 16:15 -------
Further reduced testcase:

module perdida_m
contains
  subroutine perdida (z, x)
    real, dimension (:) :: x, z
    z = generalized_hookes_law (x) + 1.0
  end subroutine perdida

  function generalized_hookes_law (x) result (z)
    real, dimension (3) :: z, x
    z = x
  end function generalized_hookes_law
end module perdida_m

program test
  use perdida_m
  real ::  x(3) = 42.0
  real ::  y(3)
  call perdida (y, x)
  print *, y
end


Lahey/Fujitsu Fortran 95 Source Check Output

Compiling program unit perdida_m at line 1:
Compiling program unit test at line 13:
Encountered 0 errors, 0 warnings, 0 informations in file SOURCE.F90.
Compiling file SOURCE.F90.

-- 


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

[Bug fortran/21104] Segmentation fault on correct code

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-19 19:23 -------
(In reply to comment #3)
> Further reduced testcase:
> Lahey/Fujitsu Fortran 95 Source Check Output

I think everyone should read <http://www.cs.rpi.edu/~szymansk/OOF90/bugs.html#6> which David E. 
send me to show why PR 20960 was undefined/invalid code.

-- 


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

[Bug fortran/21104] Segmentation fault on correct code

[pault at gcc dot gnu dot org]

------- Additional Comments From pault at gcc dot gnu dot org  2005-04-23 16:47 -------
It is my belief that this is correct code, after all.

An explicit interface is REQUIRED to invoke a procedure with a pointer or 
target dummy argument or a pointer function result. 

In other circumstances it is advised, as good practice.

Here the compiler can resolve the interface because the result has explicit 
shape.  It should therefore be able to deal with it and produce executable 
code.  At very least, it should emit a message demanding an explicit interface 
and give in gracefully.

PS Andrew, for someone who claims not to know fortran, you seem to get into 
some of its murkier corners!  We'll have you writing fortran code yet...

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2005-04-23 16:47:32
               date|                            |


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

[Bug fortran/21104] Segmentation fault on correct code

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-23 16:58 -------
(In reply to comment #5)
> PS Andrew, for someone who claims not to know fortran, you seem to get into 
> some of its murkier corners!  We'll have you writing fortran code yet...

I get help from people who can try other compilers and from people who actually know fortran.

-- 


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

[Bug fortran/21104] Segmentation fault on correct code

[paulthomas2 at wanadoo dot fr]

------- Additional Comments From paulthomas2 at wanadoo dot fr  2005-04-27 16:03 -------
This is a bug for the following reasons:

A] From the standard, we have:
12.3.1.1 Explicit interface
A procedure other than a statement function shall have an explicit interface if
......
(2) The procedure has
......
   (c) An array-valued result (functions only),
......
(3) The procedure is elemental.
......
HOWEVER....
NOTE 12.3
An interface block cannot be used to describe the interface of an internal 
procedure, a module procedure, or an intrinsic procedure because the 
interfaces of such procedures are already
explicit..........

B] DF f90 says that it is standard conforming.
Sorry, the option is /stand:f95 and not /strict.  Anyway it goes through.
$ f90 /stand:f95 /compile_only /nologo test_intr.f90
test_intr.f90

In conclusion, this is correct code.  Inserting an explicit interface in the 
module fails, correctly, but is allowed, correctly, in the subroutine perdida.




-- 


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

[Bug fortran/21104] Segmentation fault on correct code

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
   Last reconfirmed|2005-04-23 16:47:32         |2005-07-23 06:01:08
               date|                            |


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

[Bug fortran/21104] Segmentation fault on correct code

[rsandifo at gcc dot gnu dot org]

------- Additional Comments From rsandifo at gcc dot gnu dot org  2005-09-05 13:20 -------
Working on a patch.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |rsandifo at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2005-07-23 06:01:08         |2005-09-05 13:20:15
               date|                            |


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

[Bug fortran/21104] Segmentation fault on correct code

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-09-09 06:22 -------
Subject: Bug 21104

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	rsandifo@gcc.gnu.org	2005-09-09 06:22:29

Modified files:
	gcc/fortran    : ChangeLog trans.h trans-array.h trans-array.c 
	                 trans-expr.c 
	gcc/testsuite  : ChangeLog 
Added files:
	gcc/testsuite/gfortran.dg: array_alloc_1.f90 array_alloc_2.f90 
	                           array_alloc_3.f90 

Log message:
	PR fortran/21104
	* trans.h (gfc_interface_sym_mapping, gfc_interface_mapping): Moved
	from trans-expr.c.
	(gfc_init_interface_mapping, gfc_free_interface_mapping)
	(gfc_add_interface_mapping, gfc_finish_interface_mapping)
	(gfc_apply_interface_mapping): Declare.
	* trans-array.h (gfc_set_loop_bounds_from_array_spec): Declare.
	(gfc_trans_allocate_temp_array): Add pre and post block arguments.
	* trans-array.c (gfc_set_loop_bounds_from_array_spec): New function.
	(gfc_trans_allocate_array_storage): Replace loop argument with
	separate pre and post blocks.
	(gfc_trans_allocate_temp_array): Add pre and post block arguments.
	Update call to gfc_trans_allocate_array_storage.
	(gfc_trans_array_constructor, gfc_conv_loop_setup): Adjust for new
	interface to gfc_trans_allocate_temp_array.
	* trans-expr.c (gfc_interface_sym_mapping, gfc_interface_mapping):
	Moved to trans.h.
	(gfc_init_interface_mapping, gfc_free_interface_mapping)
	(gfc_add_interface_mapping, gfc_finish_interface_mapping)
	(gfc_apply_interface_mapping): Make extern.
	(gfc_conv_function_call): Build an interface mapping for array
	return values too.  Call gfc_set_loop_bounds_from_array_spec.
	Adjust call to gfc_trans_allocate_temp_array so that code is
	added to SE rather than LOOP.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&r1=1.545&r2=1.546
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans.h.diff?cvsroot=gcc&r1=1.33&r2=1.34
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-array.h.diff?cvsroot=gcc&r1=1.13&r2=1.14
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-array.c.diff?cvsroot=gcc&r1=1.58&r2=1.59
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-expr.c.diff?cvsroot=gcc&r1=1.61&r2=1.62
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.6036&r2=1.6037
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/array_alloc_1.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/array_alloc_2.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/array_alloc_3.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


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

[Bug fortran/21104] Segmentation fault on correct code

[rsandifo at gcc dot gnu dot org]

------- Additional Comments From rsandifo at gcc dot gnu dot org  2005-09-09 06:24 -------
Patch applied to mainline.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |4.1.0


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

[Bug fortran/21104] Segmentation fault on correct code

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-09-09 06:34 -------
Subject: Bug 21104

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	rsandifo@gcc.gnu.org	2005-09-09 06:34:08

Modified files:
	gcc/fortran    : ChangeLog Make-lang.in dependency.h 
	                 dependency.c trans.h trans-array.c trans-expr.c 
	gcc/testsuite  : ChangeLog 
Added files:
	gcc/testsuite/gfortran.dg: vector_subscript_1.f90 
	                           vector_subscript_2.f90 

Log message:
	PR fortran/19239
	* Makefile.in (fortran/trans-expr.o): Depend on dependency.h.
	* dependency.h (gfc_ref_needs_temporary_p): Declare.
	* dependency.c (gfc_ref_needs_temporary_p): New function.
	(gfc_check_fncall_dependency): Use it instead of inlined check.
	By so doing, take advantage of the fact that character substrings
	within an array reference also need a temporary.
	* trans.h (GFC_SS_VECTOR): Adjust comment.
	* trans-array.c (gfc_free_ss): Remove GFC_SS_VECTOR case.
	(gfc_set_vector_loop_bounds): New function.
	(gfc_add_loop_ss_code): Call it after evaluating the subscripts of
	a GFC_SS_SECTION.  Deal with the GFC_SS_VECTOR case by evaluating
	the vector expression and caching its descriptor for use within
	the loop.
	(gfc_conv_array_index_ref, gfc_conv_vector_array_index): Delete.
	(gfc_conv_array_index_offset): Handle scalar, vector and range
	dimensions as separate cases of a switch statement.  In the vector
	case, use the loop variable to calculate a vector index and use the
	referenced element as the dimension's index.  Perform bounds checking
	on this final index.
	(gfc_conv_section_upper_bound): Return null for vector indexes.
	(gfc_conv_section_startstride): Give vector indexes a start value
	of 0 and a stride of 1.
	(gfc_conv_ss_startstride): Adjust for new GFC_SS_VECTOR representation.
	(gfc_conv_expr_descriptor): Expand comments.  Generalize the
	handling of the !want_pointer && !direct_byref case.  Use
	gfc_ref_needs_temporary_p to decide whether the variable case
	needs a temporary.
	(gfc_walk_variable_expr): Handle DIMEN_VECTOR by creating a
	GFC_SS_VECTOR index.
	* trans-expr.c: Include dependency.h.
	(gfc_trans_arrayfunc_assign): Fail if the target needs a temporary.
	
	2005-09-09  Richard Sandiford  <richard@codesourcery.com>
	
	PR fortran/21104
	* trans.h (gfc_interface_sym_mapping, gfc_interface_mapping): Moved
	from trans-expr.c.
	(gfc_init_interface_mapping, gfc_free_interface_mapping)
	(gfc_add_interface_mapping, gfc_finish_interface_mapping)
	(gfc_apply_interface_mapping): Declare.
	* trans-array.h (gfc_set_loop_bounds_from_array_spec): Declare.
	(gfc_trans_allocate_temp_array): Add pre and post block arguments.
	* trans-array.c (gfc_set_loop_bounds_from_array_spec): New function.
	(gfc_trans_allocate_array_storage): Replace loop argument with
	separate pre and post blocks.
	(gfc_trans_allocate_temp_array): Add pre and post block arguments.
	Update call to gfc_trans_allocate_array_storage.
	(gfc_trans_array_constructor, gfc_conv_loop_setup): Adjust for new
	interface to gfc_trans_allocate_temp_array.
	* trans-expr.c (gfc_interface_sym_mapping, gfc_interface_mapping):
	Moved to trans.h.
	(gfc_init_interface_mapping, gfc_free_interface_mapping)
	(gfc_add_interface_mapping, gfc_finish_interface_mapping)
	(gfc_apply_interface_mapping): Make extern.
	(gfc_conv_function_call): Build an interface mapping for array
	return values too.  Call gfc_set_loop_bounds_from_array_spec.
	Adjust call to gfc_trans_allocate_temp_array so that code is
	added to SE rather than LOOP.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&r1=1.546&r2=1.547
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/Make-lang.in.diff?cvsroot=gcc&r1=1.20&r2=1.21
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/dependency.h.diff?cvsroot=gcc&r1=1.4&r2=1.5
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/dependency.c.diff?cvsroot=gcc&r1=1.8&r2=1.9
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans.h.diff?cvsroot=gcc&r1=1.34&r2=1.35
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-array.c.diff?cvsroot=gcc&r1=1.59&r2=1.60
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-expr.c.diff?cvsroot=gcc&r1=1.62&r2=1.63
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.6037&r2=1.6038
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/vector_subscript_1.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/vector_subscript_2.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


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