[Bug fortran/41627] New: mixing common and modules elicits seg fault

[Bug fortran/41627] New: mixing common and modules elicits seg fault

[dh458 at oakapple dot net]

Using a (patched) 4.4.1 gofortran on linux/x86, try to compile the attached
tcommon.f90

I get

gfortran /tmp/tcommon.f90
/tmp/tcommon.f90: In function 'tf_ad_splitting_driver_plane':
/tmp/tcommon.f90:109: internal compiler error: Segmentation fault

This was incidentally uncovered while trying to work around bug 40737.
Mixing common and modules is not good practice, but it shouldn't core dump.


-- 
           Summary: mixing common and modules elicits seg fault
           Product: gcc
           Version: 4.4.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: dh458 at oakapple dot net


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

[Bug fortran/41627] mixing common and modules elicits seg fault

[dh458 at oakapple dot net]

------- Comment #1 from dh458 at oakapple dot net  2009-10-07 22:54 -------
Created an attachment (id=18747)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18747&action=view)
example file tor segmentation violation with gfortran 4.4.1


-- 


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

[Bug fortran/41627] mixing common and modules elicits seg fault

[kargl at gcc dot gnu dot org]

------- Comment #2 from kargl at gcc dot gnu dot org  2009-10-07 23:21 -------
Here's a reduced testcase.

module testmod
   type variables_maille
      real, dimension(5) :: cell_var
   end type variables_maille
   type(variables_maille), pointer, dimension(:,:,:) :: hydro_vars
   common /arrays/ ro
   real, pointer, dimension(:) :: ro
end module testmod

subroutine tf_ad_splitting_driver_plane
   use testmod
   implicit none
   ro => hydro_vars(1:1,1,1)%cell_var(1)
end subroutine tf_ad_splitting_driver_plane


-- 

kargl at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
      Known to fail|                            |4.4.1 4.4.2 4.5.0
   Last reconfirmed|0000-00-00 00:00:00         |2009-10-07 23:21:34
               date|                            |


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

[Bug fortran/41627] mixing common and modules elicits seg fault

[dominiq at lps dot ens dot fr]

------- Comment #3 from dominiq at lps dot ens dot fr  2009-10-07 23:57 -------
Confirmed for gfortran 4.3.4, 4.4.1, and trunk. The code compiles with gfortran
4.2.4, thus this is a regression. Reduced test:

module testmod

integer, parameter :: r8  = selected_real_kind(12)

   type VARIABLES_MAILLE
      real(r8), dimension(5) :: cell_var
   end type VARIABLES_MAILLE

   type (VARIABLES_MAILLE), pointer, dimension(:) :: Hydro_vars

   real(r8), pointer, dimension(:) :: Ro

   common/arrays/Ro

end module testmod

subroutine TF_AD_SPLITTING_DRIVER_PLANE

use testmod
implicit none

    Ro => Hydro_vars(1:2)%cell_var(1)

end subroutine TF_AD_SPLITTING_DRIVER_PLANE
end

Note that if I comment the line "   common/arrays/Ro" I get the following link
error:

Undefined symbols:
  "_span.0", referenced from:
      _span.0$non_lazy_ptr in ccut3FpU.o
ld: symbol(s) not found
collect2: ld returned 1 exit status


-- 


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

[Bug fortran/41627] mixing common and modules elicits seg fault

[dh458 at oakapple dot net]

------- Comment #4 from dh458 at oakapple dot net  2009-10-08 00:19 -------
Subject: Re:  mixing common and modules elicits seg fault

> 
Note that if I comment the line "   common/arrays/Ro" I get the following link
error:

Undefined symbols:
  "_span.0", referenced from:
      _span.0$non_lazy_ptr in ccut3FpU.o


That's another bug 

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

with a patch in the comments.


-- 


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

[Bug fortran/41627] mixing common and modules elicits seg fault

[burnus at gcc dot gnu dot org]

------- Comment #5 from burnus at gcc dot gnu dot org  2009-10-08 07:47 -------
Backtrace (of comment 3) using an older GCC 4.5 (20090526):
#0  0x0000000000549453 in gfc_trans_pointer_assignment (expr1=0x12d8ea0,
expr2=0x12d3b80)
    at /home/tob/projects/gcc-trunk-checkout/gcc/fortran/trans-expr.c:4117
#1  0x000000000052b2f8 in gfc_trans_code (code=0x12d3c50) at
/home/tob/projects/gcc-trunk-checkout/gcc/fortran/trans.c:1072
#2  0x0000000000543b45 in gfc_generate_function_code (ns=0x12d00b0) at
/home/tob/projects/gcc-trunk-checkout/gcc/fortran/trans-decl.c:4153


-- 


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

[Bug fortran/41627] mixing common and modules elicits seg fault

[dominiq at lps dot ens dot fr]

------- Comment #6 from dominiq at lps dot ens dot fr  2009-10-08 08:43 -------
The use of common in the context of this PR badly hurts my understanding of
commons: storage arrays computed at compile time. The standard says (f2008):

5.7.2 COMMON statement

5.7.2.1 General

1 The COMMON statement specifies blocks of physical storage, called common
  blocks, that can be accessed by any of the scoping units in a program.
  Thus, the COMMON statement provides a global data facility based on
  storage association (16.5.3).

2 A common block that does not have a name is called blank common.

  R568 common-stmt is COMMON
      [ / [ common-block-name ] / ] common-block-object-list
      [ [ , ] / [ common-block-name ] /
      common-block-object-list ] ...

R569 common-block-object is variable-name [ ( array-spec ) ]
or proc-pointer-name

C595 (R569) An array-spec in a common-block-object shall be an
explicit-shape-spec-list.

C596 (R569) Only one appearance of a given variable-name or
proc-pointer-name is permitted in all common-block-object-lists within a
scoping unit.

C597 (R569) A common-block-object shall not be a dummy argument, a result
variable, an allocatable variable, a derived-type object with an ultimate
component that is allocatable, an automatic object, a variable with the
BIND attribute, an unlimited polymorphic pointer, or a coarray.

C598 (R569) If a common-block-object is of a derived type, the type shall
have the BIND attribute or the SEQUENCE attribute and it shall have no
default initialization.

C599 (R569) A variable-name or proc-pointer-name shall not be a name made
accessible by use association.

5.3.8.2 Explicit-shape array

R516 explicit-shape-spec is [ lower-bound : ] upper-bound
R517 lower-bound is specification-expr
R518 upper-bound is specification-expr

C531 (R516) An explicit-shape-spec whose bounds are not constant
expressions shall appear only in a subprogram, derived type definition,
or interface body.

1 An explicit-shape array is an array whose shape is explicitly declared by
  an explicit-shape-spec-list.  The rank is equal to the number of
  explicit-shape-specs.

2 An explicit-shape array that is a named local variable of a subprogram or
  BLOCK construct may have bounds that are not constant expressions.  The
  bounds, and hence shape, are determined at entry to a procedure de ned by
  the subprogram, or on execution of the BLOCK statement, by evaluating the
  bounds' expressions.  The bounds of such an array are una ected by the
  rede nition or unde nition of any variable during execution of the
  procedure or BLOCK construct.

3 The values of each lower-bound and upper-bound determine the bounds of
  the array along a particular dimension and hence the extent of the array
  in that dimension.  If lower-bound appears it speci es the lower bound;
  otherwise the lower bound is 1.  The value of a lower bound or an upper
  bound may be positive, negative, or zero.  The subscript range of the
  array in that dimension is the set of integer values between and
  including the lower and upper bounds, provided the upper bound is not
  less than the lower bound.  If the upper bound is less than the lower
  bound, the range is empty, the extent in that dimension is zero, and the
  array is of zero size.

1 1.3.10
automatic data object
automatic object

nondummy data object with a type parameter or array bound that depends on
the value of a speci cation-expr that is not an constant expression

I cannot see how 

real, pointer, dimension(:) :: ro

can defines an explicit-shape array or a non-automatic object. So is the use of
common in this PR valid or not?

Note that if C595 or C597 applies, the burden is probably on the compiler.


-- 


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

[Bug fortran/41627] mixing common and modules elicits seg fault

[dh458 at oakapple dot net]

------- Comment #7 from dh458 at oakapple dot net  2009-10-08 13:23 -------
Subject: Re:  mixing common and modules elicits seg fault

> The use of common in the context of this PR badly hurts my understanding of
commons: storage arrays computed at compile time.

For better or worse, the Sun Studio 12 Update 1 compiler compiles the
reduced test case without comment and executes it without complaint.

Whether this particular code would ever actually be good for anything is
another matter.     While hacking blindly I got gfortran to core dump on it.


-- 


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

[Bug fortran/41627] mixing common and modules elicits ICE

[dfranke at gcc dot gnu dot org]

------- Comment #8 from dfranke at gcc dot gnu dot org  2010-05-07 23:32 -------
This PR lacks the ICE-on-{valid,invalid}-code keyword.
It's too late for me now to attempt to judge which needs to be added.


-- 

dfranke at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dfranke at gcc dot gnu dot
                   |                            |org
      Known to fail|4.4.1 4.4.2 4.5.0           |4.4.1 4.4.2 4.5.0 4.6.0
            Summary|mixing common and modules   |mixing common and modules
                   |elicits seg fault           |elicits ICE


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

[Bug fortran/41627] mixing common and modules elicits ICE

[anlauf at gmx dot de]

------- Comment #9 from anlauf at gmx dot de  2010-05-08 07:44 -------
(In reply to comment #8)
> This PR lacks the ICE-on-{valid,invalid}-code keyword.
> It's too late for me now to attempt to judge which needs to be added.

The test case from comment #3 is accepted by ifort 11.1 and by
nagf95 5.1.


-- 


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

[Bug fortran/41627] mixing common and modules elicits ICE

[fxcoudert at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41627

Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |fxcoudert at gcc dot gnu.org
         Resolution|---                         |DUPLICATE
      Known to fail|                            |

--- Comment #10 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
I get, again, the same backtrace on this one as I do for PR34640, so I'm
closing it as duplicate.

*** This bug has been marked as a duplicate of bug 34640 ***