[Bug fortran/36058] New: Not allowing pointers to derived types in COMMON

[Bug fortran/36058] New: Not allowing pointers to derived types in COMMON

[w6ws at earthlink dot net]

Gfortran is not allowing pointers to certain derived types to reside in COMMON.
 While there are constraints for derived type objects themselves (ref section
5.5.2 of F2003), there do not appear to be constraints on pointers to them.  So
it seems that gfortran is not considering 'pointeredness' when applying the
constraint checks in 5.5.2.

$ cat commonptr.f90
subroutine commonptr ()
  implicit none

  type wws_t
    integer :: x = 1, y = 2, z = 3
  end type

  type (wws_t), pointer :: my_wwsptr
  common /block/ my_wwsptr

  allocate (my_wwsptr)
  my_wwsptr = wws_t (3, 4, 5)

end subroutine
$
$ gfortran --version
GNU Fortran (GCC) 4.3.0 20071222 (experimental) [trunk revision 127783]
Copyright (C) 2007 Free Software Foundation, Inc.

GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING

$ gfortran -c commonptr.f90
commonptr.f90:8.36:

  type (wws_t), pointer :: my_wwsptr
                                   1
Error: Derived type variable 'my_wwsptr' in COMMON at (1) has neither the
SEQUENCE nor the BIND(C) attribute
commonptr.f90:8.36:

  type (wws_t), pointer :: my_wwsptr
                                   1
Error: Derived type variable 'my_wwsptr' in COMMON at (1) may not have default
initializer
$


-- 
           Summary: Not allowing pointers to derived types in COMMON
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: w6ws at earthlink dot net


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

[Bug fortran/36058] Not allowing pointers to derived types in COMMON

[burnus at gcc dot gnu dot org]

------- Comment #1 from burnus at gcc dot gnu dot org  2008-04-27 08:01 -------
gfortran's rejection is in line with g95, NAG f95, ifort, openf95, sunf95 and
ifort.

I think gfortran is right and the sequence (or bind(C)) attribute is needed.

The reason is the same as for the following program:

  type my_t
    integer :: x, y, z
  end type my_t
  type(my_t) :: tt
  call foo(tt)
contains
subroutine foo(t)
  type foo_t
    integer :: x, y, z
  end type foo_t
  type(foo_t) :: t
end subroutine
end

foo_t and my_t are different, incompatible types without SEQUENCE. From that
point of view, it makes sense to reject your example.

Additionally, I think the following also applies to pointers. ("my_wwsptr" is
of a derived type [albeit with pointer attribute].)

"C589 (R558) If a common-block-object is of a derived type, it shall be a
sequence type (4.5.1) or a type with the BIND attribute and it shall have no
default initialization."

 * * *

If one now adds "SEQUENCE", gfortran rejects it as there is a default
initialization; in principle this it can be allowed as the default
initialization does not happen for pointers to derived types (only for its
targets). However, I believe that C589 also applies in this case.

The such modified program is rejected by NAG f95, sunf95, openf95, g95 and
gfortran, but ifort accepts the program.

 * * *

In conclustion, I think both error messages of gfortran are correct.


-- 


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

[Bug fortran/36058] Not allowing pointers to derived types in COMMON

[w6ws at earthlink dot net]

------- Comment #2 from w6ws at earthlink dot net  2008-04-27 13:24 -------
Subject: Re:  Not allowing pointers to derived types in
 COMMON

burnus at gcc dot gnu dot org wrote:
> ------- Comment #1 from burnus at gcc dot gnu dot org  2008-04-27 08:01 -------
> gfortran's rejection is in line with g95, NAG f95, ifort, openf95, sunf95 and
> ifort.

On the other side are PGI and Salford/Silverfrost - who allow the pointer
to reside in the COMMON block.

> Additionally, I think the following also applies to pointers. ("my_wwsptr" is
> of a derived type [albeit with pointer attribute].)
> 
> "C589 (R558) If a common-block-object is of a derived type, it shall be a
> sequence type (4.5.1) or a type with the BIND attribute and it shall have no
> default initialization."

I am only concerned with the POINTER case.  I am not placing a
derived type object in the COMMON block.  I am only storing a
pointer to it.

W.


-- 


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

[Bug fortran/36058] Not allowing pointers to derived types in COMMON

[burnus at gcc dot gnu dot org]

------- Comment #3 from burnus at gcc dot gnu dot org  2008-04-27 15:30 -------
See also:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/773de8d5b57f8e20

(In reply to comment #2)
> I am only concerned with the POINTER case.  I am not placing a
> derived type object in the COMMON block.  I am only storing a
> pointer to it.

But still you want (at least potentially) to access the pointer target at
different scopes. And then the type declaration needs to be the same (storage
wise), which is only guaranteed for SEQUENCE.

Additionally and more formally, the storage unit for a pointer is different if
the type is different (16.4.3.1 Storage sequence, item (8)) and without
SEQUENCE they describe different types [see 4.5.1.3 Determination of derived
types].

Thus I maintain that this is invalid. I'm however less sure about using a
derived type with default initializer and a pointer in a common.

Let's see what will be the reply in comp.lang.fortran.


-- 


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

[Bug fortran/36058] Not allowing pointers to derived types in COMMON

[burnus at gcc dot gnu dot org]

------- Comment #4 from burnus at gcc dot gnu dot org  2008-04-29 05:21 -------
Close as INVALID.

Richard Maine wrote in c.l.f (see link above):
------------------------------
> > Contrary to you, my reading is that this applies also to a pointer to
> > a derived type.
>
> I can read it either way,

I don't really see how. I strongly agree with Tobias here. I think you
are confusing an important aspect of Fortran pointers with C ones. In
Fortran, pointer is an attribute. It does *NOT* make a separate type. If
the common-block-object has (derived) type x, then adding the pointer
attribute doesn't change the type. It is still of the same type and thus
the above restriction still applies.

If you try to read such words any other way, I think you'll find that
large parts of the standard fall apart - at least if one tries to apply
the same reading throughout the standard.
------------------------------


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


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