[Bug fortran/46152] [F03] ALLOCATE with type-spec fails for intrinsic types

["janus at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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.