[Bug fortran/44929] New: [OOP] Intrinsic type

[Bug fortran/44929] New: [OOP] Intrinsic type

[bdsatish at gmail dot com]

-- 
           Summary: [OOP] Intrinsic type
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: bdsatish at gmail dot com


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

[Bug fortran/44929] [OOP] Parsing error of derived type name starting with 'REAL'

[bdsatish at gmail dot com]

------- Comment #1 from bdsatish at gmail dot com  2010-07-13 17:30 -------
Reported by Satish at http://gcc.gnu.org/ml/fortran/2010-07/msg00152.html

Simplified testcase by Janus Weil:

type :: real_type
end type
class(real_type), allocatable :: obj
allocate(real_type :: obj)
end

This is a simple parsing bug, triggered by the fact that
type name starts with "real", which is being confused with the
intrinsic type REAL. 


-- 

bdsatish at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bdsatish at gmail dot com,
                   |                            |janus at gcc dot gnu dot org
            Summary|[OOP] Intrinsic type        |[OOP] Parsing error of
                   |                            |derived type name starting
                   |                            |with 'REAL'


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

[Bug fortran/44929] [OOP] Parsing error of derived type name starting with 'REAL'

[burnus at gcc dot gnu dot org]

------- Comment #2 from burnus at gcc dot gnu dot org  2010-07-13 17:42 -------
Reminder:

a) TYPE(REAL) / TYPE(REAL_TYPE) is allowed, one probably can borrow the code
from there.

b) In fixed format, spaces do not count anything, thus,
   ALL O CATE( REAL  _ TYPE :: t)
   ALL O CATE( R E A L :: r)
are both perfectly valid.

c) Type parameters are also perfectly valid
   ALLOCATE( REAL(8) :: r)

I think the :: is required, thus, knowing that there is a colon, one can simply
gobble everything until the ::.


Talking about (c): The following valid program is also rejected:

real(8),allocatable :: r8
allocate( real(8) :: r8)
end


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |rejects-valid


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

[Bug fortran/44929] [OOP] Parsing error of derived type name starting with 'REAL'

[burnus at gcc dot gnu dot org]

------- Comment #3 from burnus at gcc dot gnu dot org  2010-07-13 17:48 -------
(In reply to comment #2)
> a) TYPE(REAL) / TYPE(REAL_TYPE) is allowed, one probably can borrow the code
> from there.

Thinking of it again, the simplest seems to be to copy from decl.c's
gfc_match_decl_type_spec everything after "matched_type = (m == MATCH_YES);" to
"if (matched_type)" into a separate function -- and call it then from both the
reminder of gfc_match_decl_type_spec and from match.c's match_type_spec.

I think fixing match_type_spec is difficult as also "real(8)" needs to be
handled - or later also  "real_type(kind=8,n=8,m=7)"  (i.e. derived type
parameters) - thus one should combine the logic at one place.


-- 


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

[Bug fortran/44929] [OOP] Parsing error of derived type name starting with 'REAL'

[jvdelisle at gcc dot gnu dot org]

------- Comment #4 from jvdelisle at gcc dot gnu dot org  2010-07-13 20:06 -------
The solution here should take into account all possible "key words"
combinations as well.  integer, complex, character, etc.  Matching "REAL"
should give match no accept for the few cases that are acceptable "REAL " and
REAL(" for example.


-- 


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

[Bug fortran/44929] [OOP] Parsing error of derived type name starting with 'REAL'

[kargl at gcc dot gnu dot org]

------- Comment #5 from kargl at gcc dot gnu dot org  2010-07-13 20:35 -------

> Talking about (c): The following valid program is also rejected:
> 
> real(8),allocatable :: r8
> allocate( real(8) :: r8)
> end

Hmm.  Interesting.

real(8),allocatable :: r8
allocate(real(kind=8) :: r8)
end

works.


-- 


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

[Bug fortran/44929] [OOP] Parsing error of derived type name starting with 'REAL'

[kargl at gcc dot gnu dot org]

------- Comment #6 from kargl at gcc dot gnu dot org  2010-07-13 20:41 -------
(In reply to comment #1)
> Reported by Satish at http://gcc.gnu.org/ml/fortran/2010-07/msg00152.html

Is the original code invalid?

A type is specified in several contexts by a type specifier.
R401  type-spec       is intrinsic-type-spec
                      or derived-type-spec
C401  (R401) The derived-type-spec shall not specify an abstract
             type (4.5.6).

Satish extends an abstract type.


-- 


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

[Bug fortran/44929] [OOP] Parsing error of derived type name starting with 'REAL'

[kargl at gcc dot gnu dot org]

------- Comment #7 from kargl at gcc dot gnu dot org  2010-07-13 21:01 -------
Created an attachment (id=21194)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21194&action=view)
patch for original problem

Patch the fixed Satish's original problem.  It simply checks
for a derived type prior to an intrinsic type in the allocate
statement.


-- 


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

[Bug fortran/44929] [OOP] Parsing error of derived type name starting with 'REAL'

[burnus at gcc dot gnu dot org]

------- Comment #8 from burnus at gcc dot gnu dot org  2010-07-13 22:08 -------
(In reply to comment #6)
> (In reply to comment #1)
> > Reported by Satish at http://gcc.gnu.org/ml/fortran/2010-07/msg00152.html
> 
> Is the original code invalid?
>
> C401  (R401) The derived-type-spec shall not specify an abstract
>              type (4.5.6).
> 
> Satish extends an abstract type.

Why shouldn't one extend abstract types? I think abstract types were
essentially useless if one could not extend them.

    type, abstract :: abst
    end type abst
    type, extends(abst) :: real_type
    end type real_type
[...]
        class(abst), pointer :: obj
        allocate(real_type :: obj)

And in the allocate statement, "real_type" is not an abstract type; using
"allocate(abst :: ...)" would be invalid.

(In reply to comment #5)
> > Talking about (c): The following valid program is also rejected:
> >   allocate( real(8) :: r8)
> Hmm.  Interesting.
>   allocate(real(kind=8) :: r8)
> works.

Hmm, at the moment both works for me ...


(In reply to comment #7)
> Created an attachment (id=21194)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21194&action=view) [edit]
> patch for original problem

Moving the derived-type check up is clearly a good idea, though I wonder
whether the "::" check should be also moved up or remain at the end:

+  else if (m == MATCH_ERROR && gfc_match (" :: ") == MATCH_YES)
+    return MATCH_ERROR;


-- 


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

[Bug fortran/44929] [OOP] Parsing error of derived type name starting with 'REAL'

[kargl at gcc dot gnu dot org]

------- Comment #9 from kargl at gcc dot gnu dot org  2010-07-13 22:20 -------
I'm working on a patch, so I might as well take 
ownership of the PR.


-- 

kargl at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |kargl at gcc dot gnu dot org
                   |dot org                     |
             Status|UNCONFIRMED                 |ASSIGNED
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2010-07-13 22:20:03
               date|                            |


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

[Bug fortran/44929] [OOP] Parsing error of derived type name starting with 'REAL'

[kargl at gcc dot gnu dot org]

------- Comment #10 from kargl at gcc dot gnu dot org  2010-07-20 04:01 -------
Subject: Bug 44929

Author: kargl
Date: Tue Jul 20 04:01:32 2010
New Revision: 162325

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162325
Log:
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.

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

        PR fortran/44929
        * fortran/match.c (match_type_spec): Check for derived type before
        intrinsic types.

Added:
    trunk/gcc/testsuite/gfortran.dg/allocate_with_typespec.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/match.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gfortran.dg/allocate_derived_1.f90


-- 


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

[Bug fortran/44929] [OOP] Parsing error of derived type name starting with 'REAL'

[kargl at gcc dot gnu dot org]

------- Comment #11 from kargl at gcc dot gnu dot org  2010-07-20 05:39 -------
Subject: Bug 44929

Author: kargl
Date: Tue Jul 20 05:38:49 2010
New Revision: 162326

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162326
Log:
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.

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

        PR fortran/44929
        * fortran/match.c (match_type_spec): Check for derived type before
        intrinsic types.

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


-- 


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

[Bug fortran/44929] [OOP] Parsing error of derived type name starting with 'REAL'

[kargl at gcc dot gnu dot org]

------- Comment #12 from kargl at gcc dot gnu dot org  2010-07-20 05:40 -------
Fixed on 4,5 and trunk.


-- 

kargl at gcc dot gnu dot org changed:

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


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

[Bug fortran/44929] [OOP] Parsing error of derived type name starting with 'REAL'

[kargl at gcc dot gnu dot org]

------- Comment #13 from kargl at gcc dot gnu dot org  2010-07-21 22:34 -------
Subject: Bug 44929

Author: kargl
Date: Wed Jul 21 22:34:07 2010
New Revision: 162386

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

    PR fortran/44929
    * Revert my commit r162325 for this PR.

Removed:
    trunk/gcc/testsuite/gfortran.dg/allocate_with_typespec.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/match.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gfortran.dg/allocate_derived_1.f90


-- 


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

[Bug fortran/44929] [OOP] Parsing error of derived type name starting with 'REAL'

[kargl at gcc dot gnu dot org]

------- Comment #14 from kargl at gcc dot gnu dot org  2010-07-21 22:47 -------
Subject: Bug 44929

Author: kargl
Date: Wed Jul 21 22:47:36 2010
New Revision: 162389

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

        PR fortran/44929
        * Revert my commit r162326 for this PR.

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


-- 


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

[Bug fortran/44929] [OOP] Parsing error of derived type name starting with 'REAL'

[kargl at gcc dot gnu dot org]

------- Comment #15 from kargl at gcc dot gnu dot org  2010-07-21 22:49 -------
Re-opening the bug.  My previous patch has been reverted due
to the problems outlined in PR fortran/45005.


-- 

kargl at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |


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

[Bug fortran/44929] [OOP] Parsing error of derived type name starting with 'REAL'

[kargl at gcc dot gnu dot org]

------- Comment #16 from kargl at gcc dot gnu dot org  2010-07-22 20:02 -------
Created an attachment (id=21289)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21289&action=view)
Updated diff that handles intrinsics type

The attached patch handles intrinsic types in match_type_spec better.
It does not fix the issues found in the massive valgrind log.  The
handling of derive types is too opaque for me.


-- 


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

[Bug fortran/44929] [OOP] Parsing error of derived type name starting with 'REAL'

[kargl at gcc dot gnu dot org]

------- Comment #17 from kargl at gcc dot gnu dot org  2010-07-22 20:03 -------
Unassign myself.  I don't have the smarts to trace through 
the derive type handling.


-- 

kargl at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|kargl at gcc dot gnu dot org|unassigned at gcc dot gnu
                   |                            |dot org
             Status|REOPENED                    |NEW


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

[Bug fortran/44929] [OOP] Parsing error of derived type name starting with 'REAL'

[janus at gcc dot gnu dot org]

-- 

janus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |janus at gcc dot gnu dot org
                   |dot org                     |
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2010-07-13 22:20:03         |2010-07-30 16:25:18
               date|                            |


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

[Bug fortran/44929] [OOP] Parsing error of derived type name starting with 'REAL'

[janus at gcc dot gnu dot org]

------- Comment #18 from janus at gcc dot gnu dot org  2010-07-30 17:50 -------
Subject: Bug 44929

Author: janus
Date: Fri Jul 30 17:50:28 2010
New Revision: 162724

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162724
Log:
2010-07-30  Janus Weil  <janus@gcc.gnu.org>
            Steven G. Kargl  <kargl@gcc.gnu.org>

        PR fortran/44929
        * match.c (match_type_spec): Try to parse derived types before
        intrinsic types.


2010-07-30  Janus Weil  <janus@gcc.gnu.org>

        PR fortran/44929
        * gfortran.dg/allocate_derived_3.f90: New.

Added:
    trunk/gcc/testsuite/gfortran.dg/allocate_derived_3.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/match.c
    trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/44929] [OOP] Parsing error of derived type name starting with 'REAL'

[janus at gcc dot gnu dot org]

------- Comment #19 from janus at gcc dot gnu dot org  2010-07-30 17:55 -------
Fixed with r162724. I am planning to backport this to 4.5 in about a week,
provided it does not introduce any more regressions.


-- 


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

[Bug fortran/44929] [OOP] Parsing error of derived type name starting with 'REAL'

[rguenth at gcc dot gnu dot org]

------- Comment #20 from rguenth at gcc dot gnu dot org  2010-07-31 09:29 -------
GCC 4.5.1 is being released, adjusting target milestone.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.5.1                       |4.5.2


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

[Bug fortran/44929] [OOP] Parsing error of derived type name starting with 'REAL'

[janus at gcc dot gnu dot org]

------- Comment #21 from janus at gcc dot gnu dot org  2010-08-05 13:56 -------
Subject: Bug 44929

Author: janus
Date: Thu Aug  5 13:56:00 2010
New Revision: 162914

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162914
Log:
2010-08-05  Janus Weil  <janus@gcc.gnu.org>
            Steven G. Kargl  <kargl@gcc.gnu.org>

        PR fortran/44929
        * match.c (match_type_spec): Try to parse derived types before
        intrinsic types.


2010-08-05  Janus Weil  <janus@gcc.gnu.org>

        PR fortran/44929
        * gfortran.dg/allocate_derived_3.f90: New.

Added:
    branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/allocate_derived_3.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


-- 


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

[Bug fortran/44929] [OOP] Parsing error of derived type name starting with 'REAL'

[janus at gcc dot gnu dot org]

------- Comment #22 from janus at gcc dot gnu dot org  2010-08-05 13:57 -------
Fixed on trunk an 4.5. Closing.


-- 

janus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


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