diff mbox

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

Message ID 05713b4b-3f6e-7000-395a-a964520c7204@netcologne.de
State New
Headers show

Commit Message

Thomas Koenig Aug. 2, 2017, 1:19 p.m. UTC
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.

Comments

Thomas Koenig Aug. 9, 2017, 7:44 p.m. UTC | #1
Am 02.08.2017 um 15:19 schrieb Thomas Koenig:
> 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?

Ping.

Patch at:

https://gcc.gnu.org/ml/fortran/2017-08/msg00010.html

Regards

	Thomas
Paul Richard Thomas Aug. 10, 2017, 9:37 a.m. UTC | #2
Hi Thomas,

It looks fine to me. OK for trunk.

Thanks

Paul

PS What about PR34640 ?????


On 9 August 2017 at 20:44, Thomas Koenig <tkoenig@netcologne.de> wrote:
> Am 02.08.2017 um 15:19 schrieb Thomas Koenig:
>>
>> 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?
>
>
> Ping.
>
> Patch at:
>
> https://gcc.gnu.org/ml/fortran/2017-08/msg00010.html
>
> Regards
>
>         Thomas
Thomas Koenig Aug. 11, 2017, 5:49 p.m. UTC | #3
Hi Paul,

> It looks fine to me. OK for trunk.
> 

Thanks, committed.

> Paul
> 
> PS What about PR34640 ?????

Your patch is OK if you bump the library version.

Regards

	Thomas
diff mbox

Patch

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