[Fortran-Experiments]: patch for error checking on binding labels and derived types, etc.
Christopher D. Rickett
crickett@lanl.gov
Tue Feb 27 00:40:00 GMT 2007
hi all,
the attached patch includes:
- better error checking on binding label collisions.
- better error reporting for BIND(C) derived types to try and prevent
duplicate messages.
- warnings for BIND(C) private variables that have a binding label.
- allowing NAME=""
- preventing BIND(C) functions from returning arrays or character
strings.
- new and updated test cases.
bootstrapped and regtested on x86 with no new failures.
ChangeLog entry:
2007-02-26 Christopher D. Rickett <crickett@lanl.gov>
* gcc/testsuite/gfortran.dg/binding_label_tests_10_main.f03: New
test case to make sure the compiler catches binding label
collisions across separate files when they're use associated into
one namespace.
* gcc/testsuite/gfortran.dg/bind_c_usage_7.f03: New test case to
make sure gfortran reports an error for BIND(C) procedures that
try to return an array or character string.
* gcc/testsuite/gfortran.dg/binding_label_tests_11_main.f03: Same
type of test case as binding_label_tests_10, but for contained
procedures.
* gcc/testsuite/gfortran.dg/interop_params.f03: The warning for
my_type is now an error (missing BIND(C) in derived type
definition).
* gcc/testsuite/gfortran.dg/binding_label_tests_10.f03: New test
case that goes with binding_labels_10_main.f03.
* gcc/testsuite/gfortran.dg/binding_label_tests_11.f03: New test
case that goes with binding_labels_11_main.f03.
* gcc/testsuite/gfortran.dg/binding_label_tests_2.f03: Updated
test case to remove the error for a NAME="" specifier.
* gcc/testsuite/gfortran.dg/binding_label_tests.f03: Updated test
case to include a NAME="" specifier, since this is valid.
* gcc/testsuite/gfortran.dg/bind_c_dts_3.f03: Updated my_c_type_1
to an error from a warning.
* gcc/testsuite/gfortran.dg/bind_c_dts_4.f03: Test case to make
sure the warnings for derived types are only printed once.
* gcc/testsuite/gfortran.dg/binding_label_tests_9.f03: New test
case that ensures gfortran reports a warning if a private variable
that is BIND(C) is given a binding label.
* gcc/fortran/decl.c: Updated verify_c_interop_param to include
procedures. Report an error for BIND(C) derived types that are
found conclusively to not be C interoperable (warnings still allow
derived types to be C interoperable). Added checks to
verify_bind_c_sym to make sure functions do not return arrays or
strings and if the BIND(C) symbol is PRIVATE, a warning is
reported if a binding label was given. Updated gfc_match_bind_c
to allow for NAME="".
* gcc/fortran/gfortran.h: Added mod_name field to gfc_gsymbol to
allow gfc_verify_binding_labels to correctly catch binding label
collisions that are in separate modules in separate files if
something uses both modules.
* gcc/fortran/resolve.c: Updated verify_bind_c_sym in
resolve_contained_functions to be called for both functions and
subroutines. Added resolve_bind_c_derived_types so the components
of derived types can be tested once, rather than for each time it
is encountered in a variable declaration. Updated
gfc_verify_binding_labels to ensure binding labels do not collide
even if they're in separate modules (in separate files) and then
used together in one namespace. Set the module name for the
gfc_gsymbol for the BIND(C) symbol to enable this checking.
Changed the way BIND(C) derived types are verified during
resolution to not call verify_bind_c_derived_type unless the user
needs it to be BIND(C) (C interoperable) but did not mark it as
such.
* gcc/fortran/trans-decl.c: Added check to
gfc_sym_mangled_identifier to see if a binding label was provided
for a BIND(C) symbol.
* gcc/fortran/parse.c: Removed call to verify_bind_c_derived_type
that was in parse_derived. This is now done during resolution in
resolve_bind_c_derived_types.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: svn_diff_ws.txt.gz
Type: application/octet-stream
Size: 5084 bytes
Desc:
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20070227/29e7ee20/attachment.obj>
More information about the Fortran
mailing list