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.
