From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9098 invoked by alias); 13 Jul 2010 22:08:48 -0000 Received: (qmail 9029 invoked by uid 48); 13 Jul 2010 22:08:34 -0000 Date: Tue, 13 Jul 2010 22:08:00 -0000 Message-ID: <20100713220834.9028.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug fortran/44929] [OOP] Parsing error of derived type name starting with 'REAL' 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: 2010-07/txt/msg01444.txt.bz2 ------- Comment #8 from burnus at gcc dot gnu dot org 2010-07-13 22:08 ------- (In reply to comment #6) > (In reply to comment #1) > > Reported by Satish at http://gcc.gnu.org/ml/fortran/2010-07/msg00152.html > > Is the original code invalid? > > C401 (R401) The derived-type-spec shall not specify an abstract > type (4.5.6). > > Satish extends an abstract type. Why shouldn't one extend abstract types? I think abstract types were essentially useless if one could not extend them. type, abstract :: abst end type abst type, extends(abst) :: real_type end type real_type [...] class(abst), pointer :: obj allocate(real_type :: obj) And in the allocate statement, "real_type" is not an abstract type; using "allocate(abst :: ...)" would be invalid. (In reply to comment #5) > > Talking about (c): The following valid program is also rejected: > > allocate( real(8) :: r8) > Hmm. Interesting. > allocate(real(kind=8) :: r8) > works. Hmm, at the moment both works for me ... (In reply to comment #7) > Created an attachment (id=21194) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21194&action=view) [edit] > patch for original problem Moving the derived-type check up is clearly a good idea, though I wonder whether the "::" check should be also moved up or remain at the end: + else if (m == MATCH_ERROR && gfc_match (" :: ") == MATCH_YES) + return MATCH_ERROR; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44929