This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
[patch, fortran] Fix PR 60355, missing error for BIND(C) outside module scope
- From: Thomas Koenig <tkoenig at netcologne dot de>
- To: "fortran at gcc dot gnu dot org" <fortran at gcc dot gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 2 Aug 2017 15:19:33 +0200
- Subject: [patch, fortran] Fix PR 60355, missing error for BIND(C) outside module scope
- Authentication-results: sourceware.org; auth=none
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