From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4671 invoked by alias); 29 Oct 2010 14:51:45 -0000 Received: (qmail 4663 invoked by uid 22791); 29 Oct 2010 14:51:44 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,MISSING_MID X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 29 Oct 2010 14:51:39 +0000 From: "janus at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/46152] [F03] ALLOCATE with type-spec fails for intrinsic types X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Keywords: rejects-valid X-Bugzilla-Severity: normal X-Bugzilla-Who: janus at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Status Last reconfirmed Summary Ever Confirmed In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Fri, 29 Oct 2010 14:51:00 -0000 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-10/txt/msg02498.txt.bz2 Message-ID: <20101029145100.cTMBrg7nTrBEbRD085DU68Hr63QBmBdWlvLFXkgYyrc@z> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46152 janus at gcc dot gnu.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Last reconfirmed| |2010.10.29 14:51:24 Summary|ALLOCATE with type-spec |[F03] ALLOCATE with |fails for intrinsic types |type-spec fails for | |intrinsic types Ever Confirmed|0 |1 --- Comment #15 from janus at gcc dot gnu.org 2010-10-29 14:51:24 UTC --- (In reply to comment #14) > The error message "is not an accessible derived type" make no > sense to me. In the testcase, the statement 'allocate(tx :: x(5))' > appears and there is no other appearance of 'tx'. There is > no reason (imho) to assume that 'tx' was a derived type over > some simple typographically error (ie., a syntax error). In the > following fixed-form program, > > program hmm > doubleprecision, allocatable :: x > allocate(doubleprecicion :: x) > end program hmm > > saying 'doubleprecicion' is inaccessible derived type seems odd. > > match_type_spec() now simply looks at 'tx' and asks if is a > derived type. If yes, match_type_spec() returns MATCH_YES. If no, > then 'tx' is compared against the intrinsic types. 'tx' clearly > is not an intrinsic to match_type_spec() returns MATCH_NO. Agreed so far. So maybe one should add another error message there, saying that there is an error in the type spec?!? Currently the line you commented out in allocate_derived_1 gives: allocate_derived_1.f90:35.13: allocate(tx :: x(5)) ! { dg-error "is not an accessible derived type" } 1 Fehler: Allocate-object at (1) is not a nonprocedure pointer or an allocatable variable I think this error message is much more misleading than the previous one. > Also note, the name of the function is match_type_spec(), > I've removed these chunks of code > > - old_locus = gfc_current_locus; > - if (gfc_match (" :: ") != MATCH_YES) > - return MATCH_ERROR; > - gfc_current_locus = old_locus; > /* Enfore F03:C401. */ > if (ts->u.derived->attr.abstract) > { > @@ -2771,8 +2776,6 @@ match_type_spec (gfc_typespec *ts) > } > return MATCH_YES; > } > - else if (m == MATCH_ERROR && gfc_match (" :: ") == MATCH_YES) > - return MATCH_ERROR; > > that look for '::'. The double-colon is not part of > a type-spec. Maybe the check for '::' should be left in there. In case a double colon is being found and the preceding string can not be identified as a type spec, one should throw an extra error (see above). > Now, match_type_spec() can never return a MATCH_ERROR > condition, which may mean the "is not an accessible derived type" > message may never triggered. Yes, I think it may be dead code. Not sure. Will check.