[Bug fortran/36058] Not allowing pointers to derived types in COMMON
--- 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
--- 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
--- 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
--- 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
