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

["sgk at troutmask dot apl.washington.edu" <gcc-bugzilla@gcc.gnu.org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46152

--- Comment #16 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 2010-10-29 21:51:20 UTC ---
On Fri, Oct 29, 2010 at 02:51:33PM +0000, janus at gcc dot gnu.org wrote:
> > 
> >   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,i
> saying that there is an error in the type spec?!?

The code in gfc_match_allocate() checks for '::' only if
match_type_spec() return MATCH_YES.  On MATCH_NO or MATCH_ERROR,
then gfc_match_allocate() assumes the first argument is an
allocatable pointer or variable.

> 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.

It looks like the locus pointer '1' is not handled correctly.
I've updated my patch to point at 'tx'

laptop:kargl[206] gfc4x -o z df.f90
df.f90:2.9:

allocate(tx :: x(5))
         1
Error: Allocate-object at (1) is not a nonprocedure pointer or an allocatable
variable

At this point, gfortran has never looked beyond 'tx', so 
it does not know the '::' is the next token.  

> > 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.
> 

I'll look at the patch again.  I think a less invasive
patch would be to replace gfc_match_symbol() in
match_derived_type_spec() with

  char name[GFC_MAX_SYMBOL_LEN + 1];

  if (gfc_match ("%n", name) != MATCH_YES)
    {
       gfc_current_locus = old_locus;
       return MATCH_NO;
    }

  gfc_find_symbol (name, NULL, 1, &derived);

Here, derived will be either NULL or point at a symbol
in the current name space, including parent name spaces.

The issue that really concerns me is that gfc_match_type_is()
and gfc_match_class_is() both call match_derived_type_spec()
directly.  I do not know the details of your OO work, and
simply don't want to break it.