From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10636 invoked by alias); 27 Apr 2008 08:01:46 -0000 Received: (qmail 10480 invoked by uid 48); 27 Apr 2008 08:01:03 -0000 Date: Sun, 27 Apr 2008 08:01:00 -0000 Message-ID: <20080427080103.10479.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug fortran/36058] Not allowing pointers to derived types in COMMON In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "burnus at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2008-04/txt/msg01907.txt.bz2 ------- 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