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

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

[burnus at gcc dot gnu.org]

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

           Summary: ALLOCATE with type-spec fails for intrinsic types
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Keywords: rejects-valid
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: burnus@gcc.gnu.org
                CC: kargl@gcc.gnu.org


Compiling the following program:

implicit none  ! << crucial
integer, allocatable :: a
allocate (integer :: a)
end

Fails with:

allocate (integer :: a)
                 1
Error: Symbol 'integer' at (1) has no IMPLICIT type

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

[dominiq at lps dot ens.fr]

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

--- Comment #1 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2010-10-23 19:04:41 UTC ---
The error I get with trunk is:

Error: 'integer' at (1) is not an accessible derived type

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

[burnus at gcc dot gnu.org]

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

--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-10-23 19:10:18 UTC ---
(In reply to comment #1)
> The error I get with trunk is:
> Error: 'integer' at (1) is not an accessible derived type

OK - the difference is a side effect of a local patch. Try:

  allocate (integer(4) :: a)

to get the same error message as I did.

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

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #3 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 2010-10-23 19:25:19 UTC ---
On Sat, Oct 23, 2010 at 06:50:21PM +0000, burnus at gcc dot gnu.org wrote:
> 
> Compiling the following program:
> 
> implicit none  ! << crucial
> integer, allocatable :: a

It even more crucial that 'a' is a scalar.

> allocate (integer :: a)
> end
> 

  implicit none
  integer, allocatable :: a
  integer, allocatable :: b(:)
  integer, pointer :: ap
  integer, pointer :: bp(:)
  allocate (integer :: a)
  allocate (integer :: b(1))
  allocate (integer :: ap)
  allocate (integer :: bp(1))
  end

laptop:kargl[206] gfc4x -o z a.f90
a.f90:4.17:

allocate (integer :: a)
                 1
Error: Symbol 'integer' at (1) has no IMPLICIT type

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

[burnus at gcc dot gnu.org]

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

--- Comment #4 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-10-23 19:50:52 UTC ---
(In reply to comment #3)
> > implicit none  ! << crucial
> > integer, allocatable :: a
> 
> It even more crucial that 'a' is a scalar.

Note really, if I comment-out the "allocate(integer :: a)" line I get:

  allocate (integer :: b(1))
                   1
Error: 'integer' at (1) is not an accessible derived type

(Respectively "Symbol 'integer' at (1) has no IMPLICIT type" with a patch based
on http://gcc.gnu.org/ml/fortran/2010-08/msg00181.html applied.)

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

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #5 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 2010-10-23 20:18:40 UTC ---
On Sat, Oct 23, 2010 at 07:50:55PM +0000, burnus at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46152
> 
> --- Comment #4 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-10-23 19:50:52 UTC ---
> (In reply to comment #3)
> > > implicit none  ! << crucial
> > > integer, allocatable :: a
> > 
> > It even more crucial that 'a' is a scalar.
> 
> Note really, if I comment-out the "allocate(integer :: a)" line I get:
> 
>   allocate (integer :: b(1))
>                    1
> Error: 'integer' at (1) is not an accessible derived type
> 

Oh! I've fixed that once.  This is due to janus' changes in
match_type_spec to allow derived types in the type-spec.
If you change match_type_spec to have


#if 0
  m = match_derived_type_spec (ts);
  if (m == MATCH_YES)
    {
      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)
    {
      gfc_error ("Derived type '%s' at %L may not be ABSTRACT",
             ts->u.derived->name, &old_locus);
      return MATCH_ERROR;
    }
      return MATCH_YES;
    }
#endif

the longer example code  I posted will compile.

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

[janus at gcc dot gnu.org]

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

--- Comment #6 from janus at gcc dot gnu.org 2010-10-23 21:36:43 UTC ---
This may possibly be a regression of r162724, which was the fix for PR44929.
Note that

allocate (integer :: a)

is really only useful once we have unlimited polymorphism (but even without
that it still is a valid statement and should work of course).

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

[burnus at gcc dot gnu.org]

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

--- Comment #7 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-10-24 07:01:14 UTC ---
(In reply to comment #6)
> Note that
> allocate (integer :: a)
> is really only useful once we have unlimited polymorphism

Well, it was motivated by:

  character(len=:), allocatable :: str
  allocate (character(len=77) :: str)

which is useful even without unlimited polymorphism.

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

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #8 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 2010-10-25 00:25:04 UTC ---
On Sat, Oct 23, 2010 at 07:04:51PM +0000, dominiq at lps dot ens.fr wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46152
> 
> --- Comment #1 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2010-10-23 19:04:41 UTC ---
> The error I get with trunk is:
> 
> Error: 'integer' at (1) is not an accessible derived type
> 

The attached patch fixes this problem.

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

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #9 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 2010-10-25 00:33:49 UTC ---
On Sat, Oct 23, 2010 at 06:50:21PM +0000, burnus at gcc dot gnu.org wrote:
> 
> Compiling the following program:
> 
> implicit none  ! << crucial
> integer, allocatable :: a
> allocate (integer :: a)
> end
> 
> Fails with:
> 
> allocate (integer :: a)
>                  1
> Error: Symbol 'integer' at (1) has no IMPLICIT type
> 

I believe that this is due to gfc_match_symbol() in
match_derived_type_spec().  If I understand gfc_match_symbol()
correctly, then 'integer' is added to the symbol table
of the current namespace.  When match_derived_type_spec()
returns either MATCH_NO or MATCH_ERROR, it does not clean
up the namespace.

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

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #10 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 2010-10-25 00:47:49 UTC ---
Investigating a little more.  I could not understand
why this issue was not caught earlier.  Afterall, I
use 'implicit none' in all the code I write, and I 
wrote a testcase for a type-spec in ALLOACATE.  Looking
in testsuite/ChangeLog I find, 

2010-07-19  Steven G. Kargl  <kargl@gcc.gnu.org>

        PR fortran/44929
        * gfortran.dg/allocate_with_typespec.f90: New test.
        * gfortran.dg/allocate_derived_1.f90: Update error message.

but there is no allocate_with_typespec.f90!  It appears
that I fat-fingered/forgot/screwed-up a commit.

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

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #11 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 2010-10-25 04:33:38 UTC ---
On Mon, Oct 25, 2010 at 12:48:10AM +0000, sgk at troutmask dot
apl.washington.edu wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46152
> 
> --- Comment #10 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 2010-10-25 00:47:49 UTC ---
> Investigating a little more.  I could not understand
> why this issue was not caught earlier.  Afterall, I
> use 'implicit none' in all the code I write, and I 
> wrote a testcase for a type-spec in ALLOACATE.  Looking
> in testsuite/ChangeLog I find, 
> 

The attached patch fixes the problem.

2010-10-24  Steven G. Kargl  <kargl@gcc.gnu.org>

    PR fortran/46152
    * testsuite/gfortran.dg/allocate_derived_1.f90: Update test.

    * fortran/match.c (match_derived_type_spec): Use gfc_find_symbol()
    instead of gfc_match_symbol().
    (match_type_spec): Simplify the matching of a derived type.  Move
    the matching of character length and kind to remove a jump.

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

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #12 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 2010-10-26 04:21:41 UTC ---
On Mon, Oct 25, 2010 at 12:34:10AM +0000, sgk at troutmask dot
apl.washington.edu wrote:
> > Compiling the following program:
> > 
> > implicit none  ! << crucial
> > integer, allocatable :: a
> > allocate (integer :: a)
> > end
> > 
> > Fails with:
> > 
> > allocate (integer :: a)
> >                  1
> > Error: Symbol 'integer' at (1) has no IMPLICIT type
> > 
> 
> I believe that this is due to gfc_match_symbol() in
> match_derived_type_spec().  If I understand gfc_match_symbol()
> correctly, then 'integer' is added to the symbol table
> of the current namespace.  When match_derived_type_spec()
> returns either MATCH_NO or MATCH_ERROR, it does not clean
> up the namespace.

New patch attached.  This passed regression testing.
Janus, you may want to glance over the patch.

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

[burnus at gcc dot gnu.org]

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

--- Comment #13 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-10-26 19:43:43 UTC ---
(In reply to comment #12)
> New patch attached.  This passed regression testing.

The patch is OK from my side.

I assume there is still an error printed but error but the extra error causes
that succeeding checks fail thus you removed the following line:

- allocate(tx :: x(5))  ! { dg-error "is not an accessible derived type" }

Otherwise, "is not an accessible derived type" is a nicer error message then
"error in CLASS IS specification at" but I assume one cannot have everything -
and the latter is also sufficiently clear.

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

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #14 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 2010-10-26 21:01:57 UTC ---
On Tue, Oct 26, 2010 at 07:43:49PM +0000, burnus at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46152
> 
> --- Comment #13 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-10-26 19:43:43 UTC ---
> (In reply to comment #12)
> > New patch attached.  This passed regression testing.
> 
> The patch is OK from my side.
> 
> I assume there is still an error printed but error but the extra error causes
> that succeeding checks fail thus you removed the following line:
> 
> - allocate(tx :: x(5))  ! { dg-error "is not an accessible derived type" }
> 
> Otherwise, "is not an accessible derived type" is a nicer error message then
> "error in CLASS IS specification at" but I assume one cannot have everything -
> and the latter is also sufficiently clear.
> 

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.

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

OTOH, I don't use the OO features of Fortran and I certainly will
defer to Janus if he needs this error message for something other
than allocate().  What clearly needs to go is the gfc_match_symbol()
in match_derived_type_spec().

I'll ping Janus for comment before proceeding.

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

[janus at gcc dot 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.

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

[sgk at troutmask dot apl.washington.edu]

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.

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

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

--- Comment #17 from kargl at gcc dot gnu.org 2010-10-31 03:34:35 UTC ---
New patch that I plan to commit within 24 hours.

http://gcc.gnu.org/ml/fortran/2010-10/msg00285.html

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

[kargl at gcc dot gnu.org]

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

--- Comment #18 from kargl at gcc dot gnu.org 2010-11-01 19:30:01 UTC ---
Author: kargl
Date: Mon Nov  1 19:29:57 2010
New Revision: 166140

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166140
Log:
2010-10-30  Steven G. Kargl  <kargl@gcc.gnu.org>

    PR fortran/46152
    * gfortran.dg/select_type_11.f03: Update dg-error phrase.
    * gfortran.dg/allocate_with_typespec_4.f90: New test.
    * gfortran.dg/allocate_with_typespec_1.f90: New test.
    * gfortran.dg/allocate_with_typespec_2.f: New test.
    * gfortran.dg/allocate_with_typespec_3.f90: New test.
    * gfortran.dg/allocate_derived_1.f90: Delete an obselescent test.
    * gfortran.dg/select_type_1.f03: Update dg-error phrase.

2010-10-30  Steven G. Kargl  <kargl@gcc.gnu.org>

    PR fortran/46152
    * fortran/match.c (match_derived_type_spec): Reoplace gfc_match_symbol
    with a gfc_find_symbol to prevent namespace pollution.  Remove dead
    code.
    (match_type_spec): Remove parsing of '::'.  Collapse character
    kind checking to one location.
    (gfc_match_allocate): Use correct locus in error message.

Added:
    trunk/gcc/testsuite/gfortran.dg/allocate_with_typespec_1.f90
    trunk/gcc/testsuite/gfortran.dg/allocate_with_typespec_2.f
    trunk/gcc/testsuite/gfortran.dg/allocate_with_typespec_3.f90
    trunk/gcc/testsuite/gfortran.dg/allocate_with_typespec_4.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/match.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gfortran.dg/allocate_derived_1.f90
    trunk/gcc/testsuite/gfortran.dg/select_type_1.f03
    trunk/gcc/testsuite/gfortran.dg/select_type_11.f03

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

[kargl at gcc dot gnu.org]

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

--- Comment #19 from kargl at gcc dot gnu.org 2010-11-02 22:02:42 UTC ---
Author: kargl
Date: Tue Nov  2 22:02:37 2010
New Revision: 166217

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166217
Log:
2010-10-30  Steven G. Kargl  <kargl@gcc.gnu.org>

    PR fortran/46152
    * gfortran.dg/select_type_11.f03: Update dg-error phrase.
    * gfortran.dg/allocate_with_typespec_4.f90: New test.
    * gfortran.dg/allocate_with_typespec_1.f90: New test.
    * gfortran.dg/allocate_with_typespec_2.f: New test.
    * gfortran.dg/allocate_with_typespec_3.f90: New test.
    * gfortran.dg/allocate_derived_1.f90: Delete an obselescent test.
    * gfortran.dg/select_type_1.f03: Update dg-error phrase.

2010-10-30  Steven G. Kargl  <kargl@gcc.gnu.org>

    PR fortran/46152
    * fortran/match.c (match_derived_type_spec): Reoplace gfc_match_symbol
    with a gfc_find_symbol to prevent namespace pollution.  Remove dead
    code.
    (match_type_spec): Remove parsing of '::'.  Collapse character
    kind checking to one location.
    (gfc_match_allocate): Use correct locus in error message.

Added:
   
branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/allocate_with_typespec_1.f90
   
branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/allocate_with_typespec_2.f
   
branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/allocate_with_typespec_3.f90
   
branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/allocate_with_typespec_4.f90
Modified:
    branches/gcc-4_5-branch/gcc/fortran/ChangeLog
    branches/gcc-4_5-branch/gcc/fortran/match.c
    branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
    branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/allocate_derived_1.f90
    branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/select_type_1.f03
    branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/select_type_11.f03

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

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |4.5.3

--- Comment #20 from kargl at gcc dot gnu.org 2010-11-02 22:04:18 UTC ---
Fixed on 4.5 and trunk.  Closing.