[Bug fortran/22571] Reject derived types for dummy arguments declared in the subroutine unless they are SEQUENCE

[Bug fortran/22571] Reject derived types for dummy arguments declared in the subroutine unless they are SEQUENCE

[pinskia at gcc dot gnu dot org]

------- Comment #3 from pinskia at gcc dot gnu dot org  2006-01-07 05:47 -------
*** Bug 25686 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pinskia at gcc dot gnu dot
                   |                            |org


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

[Bug fortran/22571] Reject derived types for dummy arguments declared in the subroutine unless they are SEQUENCE

[pinskia at gcc dot gnu dot org]

------- Comment #4 from pinskia at gcc dot gnu dot org  2006-02-11 21:20 -------
*** Bug 25685 has been marked as a duplicate of this bug. ***


-- 


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

[Bug fortran/22571] Reject derived types for dummy arguments declared in the subroutine unless they are SEQUENCE

[paul dot richard dot thomas at cea dot fr]

------- Comment #5 from paul dot richard dot thomas at cea dot fr  2006-06-23 07:04 -------
It should be noted that encasing the two subroutines in a module produces the
correct error

 In file pr22571.f90:15

    call a(q)
          1
Error: Type/rank mismatch in argument 'p' at (1)

The problem lies in the absence of global actual/formal argument checking;
where there is an explicit interface, all works correctly.

Paul


-- 


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

[Bug fortran/22571] Reject derived types for dummy arguments declared in the subroutine unless they are SEQUENCE

[pault at gcc dot gnu dot org]

------- Comment #6 from pault at gcc dot gnu dot org  2006-10-03 15:06 -------
(In reply to comment #5)

> The problem lies in the absence of global actual/formal argument checking;
> where there is an explicit interface, all works correctly.

Actually, it is not as bad as I thought:
(i)'p' being a non-sequence type dummy in a non-contained procedure should
generate an error because there is no way in which type association can occur
between the caller and 'a'.
(ii) The same is true of the actual argument in the call to 'a' from 'b'; since
'a' is external, a sequence type is required.

Paul 


-- 


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

[Bug fortran/22571] Reject derived types for dummy arguments declared in the subroutine unless they are SEQUENCE

[fxcoudert at gcc dot gnu dot org]

-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |fxcoudert at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2005-12-31 20:16:00         |2007-08-14 14:10:56
               date|                            |


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

[Bug fortran/22571] Reject derived types for dummy arguments declared in the subroutine unless they are SEQUENCE

[burnus at gcc dot gnu dot org]

------- Comment #7 from burnus at gcc dot gnu dot org  2007-08-14 15:48 -------
Note: Instead of having the SEQUENCE property, the BIND(C) attribute ("type,
bind(c) :: t") suffices as well.

"Two data entities have the same type if they are declared with reference to
the same derived-type definition. The definition may be accessed from a module
or from a host scoping unit. Data entities indifferent scoping units also have
the same type if they are declared with reference to different derived-type
definitions that specify the same type name, all have the SEQUENCE property or
all have the BIND attribute, have no components with PRIVATE accessibility, and
have type parameters and components that agree in order, name, and attributes.
Otherwise, they are of different derived types. A data entity declared using a
type with the SEQUENCE property or with the BIND attribute is not of the same
type as an entity of a type declared to be PRIVATE or that has any components
that are PRIVATE."


-- 


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

[Bug fortran/22571] Reject derived types for dummy arguments declared in the subroutine unless they are SEQUENCE

[fxcoudert at gcc dot gnu dot org]

-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|fxcoudert at gcc dot gnu dot|unassigned at gcc dot gnu
                   |org                         |dot org
             Status|ASSIGNED                    |NEW


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

[Bug fortran/22571] Reject derived types for dummy arguments declared in the subroutine unless they are SEQUENCE

[tobi at gcc dot gnu dot org]

------- Comment #8 from tobi at gcc dot gnu dot org  2007-10-07 17:16 -------
Something like the patch below fails unfortunately -- when resolving arglists
we still don't know enough about the callee (viz the checks of ptype, that are
already a hack on top of my original patch attempt) to determine what is legal.
 It's probably possible to add another scan over the argument list once the
procedure call has been resolved, but I haven't yet looked into this.  Also, it
doesn't really feel proper.

diff -r 8c9190af9173 gcc/fortran/resolve.c
--- a/gcc/fortran/resolve.c     Sun Oct 07 11:45:15 2007 +0000
+++ b/gcc/fortran/resolve.c     Sun Oct 07 19:11:46 2007 +0200
@@ -940,6 +940,31 @@ resolve_assumed_size_actual (gfc_expr *e
 }


+/* Given a derived type, returns true if the type is use-associated or
+   has the SEQUENCE or BIND(C) attributes and has no PRIVATE
+   componentes.  In these cases it may be used as dummy arguments in
+   calls without explicit interface.  */
+
+static bool
+interchangeable_type (gfc_typespec *ts)
+{
+  gfc_symbol *sym = ts->derived;
+
+  gcc_assert (ts->type == BT_DERIVED);
+
+  /* We don't have to recurse through potential derived type members,
+     because the type having either of use_assoc, is_bin_c or sequence
+     set requires this for the subtypes.  This requirement is checked
+     elsewhere.  Likewise, if the private_comp attribute is set in a
+     component, it is inherited by the type.  */
+  if (sym->ns != gfc_current_ns || sym->attr.use_assoc)
+    return true;
+
+  return ((sym->attr.is_bind_c || sym->attr.sequence)
+         && !sym->attr.private_comp);
+}
+
+
 /* Resolve an actual argument list.  Most of the time, this is just
    resolving the expressions in the list.
    The exception is that we sometimes have to decide whether arguments
@@ -975,6 +1000,7 @@ resolve_actual_arglist (gfc_actual_argli
        {
          if (gfc_resolve_expr (e) != SUCCESS)
            return FAILURE;
+
          goto argument_list;
        }

@@ -1114,6 +1140,15 @@ resolve_actual_arglist (gfc_actual_argli
        return FAILURE;

     argument_list:
+      if ((ptype == PROC_EXTERNAL || ptype == PROC_UNKNOWN)
+         && e->ts.type == BT_DERIVED
+         && !interchangeable_type (&e->ts))
+       {
+         gfc_error ("Derived type '%s' cannot appear in argument list "
+                    "at %L", e->ts.derived->name, &e->where);
+         return FAILURE;
+       }
+             
       /* Check argument list functions %VAL, %LOC and %REF.  There is
         nothing to do for %REF.  */
       if (arg->name && arg->name[0] == '%')


-- 

tobi at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tobi at gcc dot gnu dot org


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

[Bug fortran/22571] Reject derived types for dummy arguments declared in the subroutine unless they are SEQUENCE

[jv244 at cam dot ac dot uk]

------- Comment #9 from jv244 at cam dot ac dot uk  2008-12-05 16:28 -------
updated testcase still fails:

subroutine a(p)
  type t
    integer :: t1
  end type
  type(t) :: p
  p%t1 = 42
end subroutine
subroutine b
  type u
    integer :: u1
  end type
  type (u) :: q
  call a(q)
  write(6,*) q%u1
end subroutine


-- 


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

[Bug fortran/22571] Reject derived types for dummy arguments declared in the subroutine unless they are SEQUENCE

[pault at gcc dot gnu dot org]

------- Comment #10 from pault at gcc dot gnu dot org  2009-03-30 19:35 -------
Subject: Bug 22571

Author: pault
Date: Mon Mar 30 19:35:14 2009
New Revision: 145314

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145314
Log:
2009-03-30  Paul Thomas  <pault@gcc.gnu.org>

        PR fortran/22571
        PR fortran/26227
        PR fortran/24886
        * symbol.c : Add gfc_global_ns_list.
        * decl.c (add_global_entry): Set the namespace ('ns') field.
        * gfortran.h : Add the resolved field to gfc_namespace. Add the
        namespace ('ns') field to gfc_gsymbol.  Add flag_whole_file to
        gfc_option_t.  Add the prototype for gfc_free_dt_list.
        * lang.opt : Add the whole-file option.
        * invoke.texi : Document the whole-file option.
        * resolve.c (resolve_global_procedure): If the fwhole-file
        option is set, reorder gsymbols to ensure that translation is
        in the right order.  Resolve the gsymbol's namespace if that
        has not occurred and then check interfaces.
        (resolve_function): Move call to resolve_global_procedure.
        (resolve_call): The same.
        (resolve_codes): Store the current labels_obstack.
        (gfc_resolve) : Return if the namespace is already resolved.
        trans-decl.c (gfc_get_extern_function_decl): If the whole_file
        option is selected, use the backend_decl of a gsymbol, if it is
        available.
        parse.c (add_global_procedure, add_global_program): If the flag
        whole-file is set, add the namespace to the gsymbol.
        (gfc_parse_file): On -fwhole-file, put procedure namespaces on
        the global namespace list.  Rearrange to do resolution of all
        the procedures in a file, followed by their translation.
        * options.c (gfc_init_options): Add -fwhole-file.
        (gfc_handle_option): The same.

2009-03-30  Paul Thomas  <pault@gcc.gnu.org>

        PR fortran/22571
        * gfortran.dg/whole_file_1.f90: New test.
        PR fortran/26227
        * gfortran.dg/whole_file_2.f90: New test.
        * gfortran.dg/whole_file_3.f90: New test.
        PR fortran/24886
        * gfortran.dg/whole_file_4.f90: New test.


Added:
    trunk/gcc/testsuite/gfortran.dg/whole_file_1.f90
    trunk/gcc/testsuite/gfortran.dg/whole_file_2.f90
    trunk/gcc/testsuite/gfortran.dg/whole_file_3.f90
    trunk/gcc/testsuite/gfortran.dg/whole_file_4.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/decl.c
    trunk/gcc/fortran/gfortran.h
    trunk/gcc/fortran/invoke.texi
    trunk/gcc/fortran/lang.opt
    trunk/gcc/fortran/options.c
    trunk/gcc/fortran/parse.c
    trunk/gcc/fortran/resolve.c
    trunk/gcc/fortran/symbol.c
    trunk/gcc/fortran/trans-array.c
    trunk/gcc/fortran/trans-decl.c
    trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/22571] Reject derived types for dummy arguments declared in the subroutine unless they are SEQUENCE

[dfranke at gcc dot gnu dot org]

------- Comment #11 from dfranke at gcc dot gnu dot org  2009-04-10 22:12 -------
Testcase of comment #9 now gives:
$ gfortran-svn -fwhole-file -g -Wall -c pr22571.f90
pr22571.f90:13.9:

  call a(q)
         1
Error: Type mismatch in argument 'p' at (1); passed TYPE(u) to TYPE(t)

Paul, can we close this one?


-- 

dfranke at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dfranke at gcc dot gnu dot
                   |                            |org, pault at gcc dot gnu
                   |                            |dot org


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

[Bug fortran/22571] Reject derived types for dummy arguments declared in the subroutine unless they are SEQUENCE

[dfranke at gcc dot gnu dot org]

-- 

dfranke at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING


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

[Bug fortran/22571] Reject derived types for dummy arguments declared in the subroutine unless they are SEQUENCE

[dfranke at gcc dot gnu dot org]

------- Comment #12 from dfranke at gcc dot gnu dot org  2010-05-08 20:07 -------
In reply to comment #11)
> Paul, can we close this one?

This PR sat here WAITING for a few months.
Everything seems to be done, thus closing now.


-- 

dfranke at gcc dot gnu dot org changed:

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


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

[Bug fortran/22571] New: error needed

[jv244 at cam dot ac dot uk]

related to inlining of fortran functions :

http://gcc.gnu.org/ml/gcc/2005-07/msg00860.html

the following code is non-standard (but gfortran 'fails' to generate an error):

subroutine a(p)
  type t
    integer :: t1
  end type
  type(t) :: p
  p%t1 = 42
end subroutine
subroutine b
  type u
    integer :: u1
  end type
  type (u) :: q
  call a(q)
  print * q%u1
end subroutine

NAG:
Error: mytest.f90: Argument P (no. 1) in reference to A from B has the wrong
data type

LAHEY:line 14: Argument number '1' type of procedure 'a' shall be the same
between definition and reference.

Only the following is accepted by both compilers (and is standard conforming):

subroutine a(p)
  type t
    sequence
    integer :: t1
  end type
  type(t) :: p
  p%t1 = 42
end subroutine
subroutine b
  type t
    sequence
    integer :: t1
  end type
  type (t) :: q
  call a(q)
end subroutine

in particular same name of the types, sequence type, and same name of the
components, see 4.4.2 for a precise definition about when two derived types are
the same.

Joost

-- 
           Summary: error needed
           Product: gcc
           Version: 4.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: jv244 at cam dot ac dot uk
                CC: gcc-bugs at gcc dot gnu dot org


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

[Bug fortran/22571] Reject derived types for dummy arguments declared in the subroutine unless they are SEQUENCE

[tkoenig at gcc dot gnu dot org]

------- Additional Comments From tkoenig at gcc dot gnu dot org  2005-07-22 11:30 -------
Confirmed.

We need to reject dummy arguments if

- they are of a derived type
- the derived type is declared in that subroutine
- they aren't sequence types.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2005-07-22 11:30:58
               date|                            |
            Summary|error needed                |Reject derived types for
                   |                            |dummy arguments declared in
                   |                            |the subroutine unless they
                   |                            |are SEQUENCE


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