[Bug fortran/57966] New: Using a TBP to specify the shape of a dummy argument

[Bug fortran/57966] New: Using a TBP to specify the shape of a dummy argument

[stefan.mauerberger at gmail dot com]

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

            Bug ID: 57966
           Summary: Using a TBP to specify the shape of a dummy argument
           Product: gcc
           Version: 4.8.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: stefan.mauerberger at gmail dot com

Created attachment 30542
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30542&action=edit
minimal example

Hi There!

I am faced with some weired behavior. Because it is a little hard to describe I
am providing an example:

There is a DDT 'config_cls' whose pure TBP 'my_size' does nothing but returning
10 .
> TYPE config_cls
> CONTAINS
>     PROCEDURE, NOPASS :: my_size
> END TYPE

> PURE INTEGER FUNCTION my_size()
>     my_size = 10
> END FUNCTION my_size

In addition there is a subroutine 'my_sub' which expects a dummy argument of
explicit shape 'config%my_size()'. 
> SUBROUTINE my_sub( field )
>     REAL, INTENT(INOUT) :: field( config%my_size() )
>     !REAL, INTENT(INOUT), CONTIGUOUS :: field(:) ! Assumed shape works
>     !REAL, INTENT(INOUT) :: field( my_size() ) ! works, too

> END SUBROUTINE my_sub
As far as I can see this is valid Fortran code. However, gfortran complains
that config%my_size() is not a function. Well, this is wrong (for non dummy
arguments it works perfectly fine)!

Attached, there is a minimal example. Compiling it with gfortran terminates
with:
> test.f90:33.22:
>
>        REAL :: field( config%my_size() )
>                      1
> Error: 'my_size' at (1) should be a FUNCTION

Any ideas? 

Cheers, Stefan 

Actually, ifort 12.1.6, nag 5.3.2 and pgfortran 13.4 are just fine.

[Bug fortran/57966] [OOP] Using a TBP to specify the shape of a dummy argument

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |rejects-valid
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-07-24
                 CC|                            |janus at gcc dot gnu.org
            Summary|Using a TBP to specify the  |[OOP] Using a TBP to
                   |shape of a dummy argument   |specify the shape of a
                   |                            |dummy argument
     Ever confirmed|0                           |1

--- Comment #1 from janus at gcc dot gnu.org ---
(In reply to stefan.mauerberger from comment #0)
> Hi There!

Hi!


> I am faced with some weired behavior. Because it is a little hard to
> describe I am providing an example:

... which is anyway a much better idea than trying to describe it.


> Attached, there is a minimal example. Compiling it with gfortran terminates
> with:
> > test.f90:33.22:
> >
> >        REAL :: field( config%my_size() )
> >                      1
> > Error: 'my_size' at (1) should be a FUNCTION
> 
> Any ideas? 

Seems like you hit a bug. I can reproduce it with 4.7, 4.8 and trunk.

Slightly reduced test case:

MODULE my_mod
  IMPLICIT NONE

  TYPE config_cls
  CONTAINS
    PROCEDURE, NOPASS :: my_size
  END TYPE

  TYPE(config_cls) :: config

CONTAINS

  PURE INTEGER FUNCTION my_size()
    my_size = 10
  END FUNCTION

  SUBROUTINE my_sub( field )
    REAL :: field( config%my_size() )
  END SUBROUTINE

END MODULE


Thanks for reporting ...

Cheers,
Janus

[Bug fortran/57966] [OOP] Using a TBP to specify the shape of a dummy argument

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |janus at gcc dot gnu.org

--- Comment #2 from janus at gcc dot gnu.org ---
Draft patch (not regtested yet):


Index: gcc/fortran/resolve.c
===================================================================
--- gcc/fortran/resolve.c    (revision 201038)
+++ gcc/fortran/resolve.c    (working copy)
@@ -5638,14 +5638,6 @@ resolve_compcall (gfc_expr* e, const char **name)
   gfc_actual_arglist* newactual;
   gfc_symtree* target;

-  /* Check that's really a FUNCTION.  */
-  if (!e->value.compcall.tbp->function)
-    {
-      gfc_error ("'%s' at %L should be a FUNCTION",
-         e->value.compcall.name, &e->where);
-      return false;
-    }
-
   /* These must not be assign-calls!  */
   gcc_assert (!e->value.compcall.assign);

@@ -5661,6 +5653,15 @@ resolve_compcall (gfc_expr* e, const char **name)
     return false;
   gcc_assert (!e->value.compcall.tbp->is_generic);

+  /* Check that it's really a FUNCTION.  */
+  if (!e->value.compcall.tbp->function
+      && !e->value.compcall.tbp->u.specific->n.sym->attr.function)
+    {
+      gfc_error ("'%s' at %L should be a FUNCTION",
+         e->value.compcall.name, &e->where);
+      return false;
+    }
+
   /* Take the rank from the function's symbol.  */
   if (e->value.compcall.tbp->u.specific->n.sym->as)
     e->rank = e->value.compcall.tbp->u.specific->n.sym->as->rank;

[Bug fortran/57966] [OOP] Using a TBP to specify the shape of a dummy argument

[janus at gcc dot gnu.org]

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

--- Comment #3 from janus at gcc dot gnu.org ---
(In reply to janus from comment #2)
> Draft patch (not regtested yet):

Seems to survive the regtest without any failures (except for round_4.f90,
which is unrelated).

[Bug fortran/57966] [OOP] Using a TBP to specify the shape of a dummy argument

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu.org

--- Comment #4 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to janus from comment #3)
> Seems to survive the regtest without any failures (except for round_4.f90,
> which is unrelated).

Regarding: round_4.f90 with GLIBC (e.g. Linux), it is expected to fail with
GLIBC < 2.17 as those ignore the rounding; cf.
http://sourceware.org/bugzilla/show_bug.cgi?id=3479

[Bug fortran/57966] [OOP] Using a TBP to specify the shape of a dummy argument

[janus at gcc dot gnu.org]

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

--- Comment #5 from janus at gcc dot gnu.org ---
(In reply to janus from comment #3)
> (In reply to janus from comment #2)
> > Draft patch (not regtested yet):
> 
> Seems to survive the regtest without any failures

However, it ICEs on the following variant (which involves a GENERIC TBP):


MODULE my_mod
  IMPLICIT NONE

  TYPE config_cls
  CONTAINS
    PROCEDURE, NOPASS :: my_size
    GENERIC :: sz => my_size
  END TYPE

  TYPE(config_cls) :: config

CONTAINS

  PURE INTEGER FUNCTION my_size()
    my_size = 10
  END FUNCTION

  SUBROUTINE my_sub( field )
    REAL :: field( config%sz() )
  END SUBROUTINE

END MODULE


With an unpatched gfortran, this yields the same (bogus) error as comment 0.
Unfortunately ifort 12.1.2 ICEs on this variant (and I don't have access to a
newer version), but after all I assume it is valid.

[Bug fortran/57966] [OOP] Using a TBP to specify the shape of a dummy argument

[burnus at gcc dot gnu.org]

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

--- Comment #6 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to janus from comment #5)
> However, it ICEs on the following variant (which involves a GENERIC TBP):

That test case compile with NAG f95 v5.1 (of 2007!) and with a pretty new Cray
ftn (version 8.1.8). It also looks valid to me.


> Unfortunately ifort 12.1.2 ICEs on this variant (and I don't have access to
> a newer version), but after all I assume it is valid.

It also ICEs with ifort 13.1.3. PGI has a similar bogus error as gfortran:
"Could not resolve generic type bound procedure sz".

[Bug fortran/57966] [OOP] Using a TBP to specify the shape of a dummy argument

[janus at gcc dot gnu.org]

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

--- Comment #7 from janus at gcc dot gnu.org ---
The following patch fixes both variants (comment 1 and comment 5):


Index: gcc/fortran/resolve.c
===================================================================
--- gcc/fortran/resolve.c    (revision 201238)
+++ gcc/fortran/resolve.c    (working copy)
@@ -5686,7 +5686,9 @@ resolve_compcall (gfc_expr* e, const char **name)
 }


+static bool resolve_fl_derived (gfc_symbol *sym);

+
 /* Resolve a typebound function, or 'method'. First separate all
    the non-CLASS references by calling resolve_compcall directly.  */

@@ -5772,6 +5774,9 @@ resolve_typebound_function (gfc_expr* e)

   /* Get the CLASS declared type.  */
   declared = get_declared_from_expr (&class_ref, &new_ref, e, true);
+  
+  if (!resolve_fl_derived (declared))
+    return false;

   /* Weed out cases of the ultimate component being a derived type.  */
   if ((class_ref && class_ref->u.c.component->ts.type == BT_DERIVED)



The problem was actually that the TBP was not properly resolved (or more
precisely: that the resolution came too late), so that the FUNCTION attribute
was not yet set. Regtesting now ...

[Bug fortran/57966] [OOP] Using a TBP to specify the shape of a dummy argument

[janus at gcc dot gnu.org]

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

--- Comment #8 from janus at gcc dot gnu.org ---
(In reply to janus from comment #7)
> Regtesting now ...

Completed successfully!