From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15923 invoked by alias); 13 Jul 2010 17:48:33 -0000 Received: (qmail 15692 invoked by uid 48); 13 Jul 2010 17:48:18 -0000 Date: Tue, 13 Jul 2010 17:48:00 -0000 Message-ID: <20100713174818.15691.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/msg01430.txt.bz2 ------- Comment #3 from burnus at gcc dot gnu dot org 2010-07-13 17:48 ------- (In reply to comment #2) > a) TYPE(REAL) / TYPE(REAL_TYPE) is allowed, one probably can borrow the code > from there. Thinking of it again, the simplest seems to be to copy from decl.c's gfc_match_decl_type_spec everything after "matched_type = (m == MATCH_YES);" to "if (matched_type)" into a separate function -- and call it then from both the reminder of gfc_match_decl_type_spec and from match.c's match_type_spec. I think fixing match_type_spec is difficult as also "real(8)" needs to be handled - or later also "real_type(kind=8,n=8,m=7)" (i.e. derived type parameters) - thus one should combine the logic at one place. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44929