This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[patch, fortran] Fix PR 60355, missing error for BIND(C) outside module scope


Hello world,

the attached patch is a bit smaller than it looks, because most of
it is due to reformatting a large comment.  It is rather simple -
checking for an incorrectly placed BIND(C) variable was sometimes not
done because the test was mixed in with other tests where implicitly
typed variables were excluded.

Regression-tested. OK for trunk?

Regards

	Thomas

2017-08-02  Thomas Koenig  <tkoenig@gcc.gnu.org>

        PR fortran/60355
        * resolve.c (resolve_symbol): Adjust (and reformat)
        comment.  Perform check if a BIND(C) is declared
        at module level regardless of whether it is typed
        implicitly or not.

2017-08-02  Thomas Koenig  <tkoenig@gcc.gnu.org>

        PR fortran/60355
        * gfortran.dg (bind_c_usage_30): New test.
Index: resolve.c
===================================================================
--- resolve.c	(Revision 250720)
+++ resolve.c	(Arbeitskopie)
@@ -14397,17 +14397,18 @@ resolve_symbol (gfc_symbol *sym)
 	}
     }
 
-  /* If the symbol is marked as bind(c), verify it's type and kind.  Do not
-     do this for something that was implicitly typed because that is handled
-     in gfc_set_default_type.  Handle dummy arguments and procedure
-     definitions separately.  Also, anything that is use associated is not
-     handled here but instead is handled in the module it is declared in.
-     Finally, derived type definitions are allowed to be BIND(C) since that
-     only implies that they're interoperable, and they are checked fully for
-     interoperability when a variable is declared of that type.  */
-  if (sym->attr.is_bind_c && sym->attr.implicit_type == 0 &&
-      sym->attr.use_assoc == 0 && sym->attr.dummy == 0 &&
-      sym->attr.flavor != FL_PROCEDURE && sym->attr.flavor != FL_DERIVED)
+  /* If the symbol is marked as bind(c), that it is declared at module level
+     scope and verify its type and kind.  Do not do the latter for symbols
+     that are implicitly typed because that is handled in
+     gfc_set_default_type.  Handle dummy arguments and procedure definitions
+     separately.  Also, anything that is use associated is not handled here
+     but instead is handled in the module it is declared in.  Finally, derived
+     type definitions are allowed to be BIND(C) since that only implies that
+     they're interoperable, and they are checked fully for interoperability
+     when a variable is declared of that type.  */
+  if (sym->attr.is_bind_c && sym->attr.use_assoc == 0
+      && sym->attr.dummy == 0 && sym->attr.flavor != FL_PROCEDURE
+      && sym->attr.flavor != FL_DERIVED)
     {
       bool t = true;
 
@@ -14421,11 +14422,11 @@ resolve_symbol (gfc_symbol *sym)
 		     "module level scope", sym->name, &(sym->declared_at));
 	  t = false;
 	}
-      else if (sym->common_head != NULL)
+      else if (sym->common_head != NULL && sym->attr.implicit_type == 0)
         {
           t = verify_com_block_vars_c_interop (sym->common_head);
         }
-      else
+      else if (sym->attr.implicit_type == 0)
 	{
 	  /* If type() declaration, we need to verify that the components
 	     of the given type are all C interoperable, etc.  */
! { dg-do compile }
! PR 60355 - there was no error message for implicitly typed variables
! Test case contributed by Vladimir Fuka
program main
  bind(c) test_BIND ! { dg-error "cannot be BIND" }
END

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]