This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: [Fortran-Experiments]: patch
On Mon, 26 Feb 2007, Tobias Burnus wrote:
Hello Chris, hi all,
Christopher D. Rickett wrote:
i've attached another patch for the fortran-experiments branch. it
contains quite a bit of whitespace fixes and new test cases. it also has
improved error messages for a few things and new error checking on binding
labels. it also fixes some minor bugs, such as c_size_t and the required
parens for subroutines marked with bind(c). bootstrapped and regtested on
x86 with no new failures.
I applied it, build it (but did not bootstrap), tested it a bit, skimmed
the patch itself and regtested it on x86-64/openSUSE 10.2 with no
failures (but the old c_int_fast*_t in c_kind_params.f90).
Thanks for all those fixes. Steve, is this patch ok for the
fortran-experiments branch? If yes, I'd like to check it in.
Tobias
PS: Just to keep track myself:
- nested interfaces do not work yet,
http://gcc.gnu.org/ml/fortran/2007-02/msg00535.html
did you apply your proposed patch for bind(c) dummy procedures? if so, my
next patch (which i'm holding on to until the one from Saturday gets
committed) should finish fixing these.
- gfortran rejects bind(c,name=""),
http://gcc.gnu.org/ml/fortran/2007-02/msg00505.html (b)
should work with the patch i'm waiting to submit. now i simply let
gfortran mangle the symbol as normal if the binding label was "". we
could further improve this by adding some sort of character that is
invalid for C names just to ensure the C programmer can't call it by it's
mangled name either. i also issue a warning for private symbols that have
been given a binding label (this was proposed in one of Tobias' emails and
seemed like a good idea).
- gfortran allows functions to return an array,
http://gcc.gnu.org/ml/fortran/2007-02/msg00505.html (c)
this is fixed in the patch i'm holding. i also added a check to ensure
character strings aren't returned, since i hadn't checked for that either.
apologies for the obvious oversites.
- Same error is printed twice,
http://gcc.gnu.org/ml/fortran/2007-02/msg00496.html
this should be also be fixed in the patch i'm holding. the problem was
that i had not moved all of the error checking for BIND(C) to the resolve
stage. i was still verifying the derived types after matching them.
however, i now do it during resolution only.
- bind_c symbol collision:
----------- 1.f90--------
module x
use iso_c_binding
implicit none
integer(c_int), bind(c,name="c_one") :: one
end module x
---------------------------
----------- 2.f90--------
module y
use iso_c_binding
implicit none
integer(c_int), bind(c,name="c_one") :: one
end module y
program main
use x
use y
end program main
---------------------------
Does compile with gfortran, but NAG f95 outputs:
Error: 2.f90: Duplicate binding label 'c_one' for variable ONE of
module Y and variable ONE of module X
On the other hand, neither g95, sunf95 nor ifort 10 give a compile-time
error/warning.
hmm, i thought that this should have been fixed with my last patch.
either way, my current local gfortran reports the following:
tobias4.f03:10.44:
integer(c_int), bind(c,name="c_one") :: one
1
tobias4.f03:4.44:
integer(c_int), bind(c,name="c_one") :: one
2
Error: Binding label 'c_one' at (1) collides with global entity 'c_one' at
(2)
tobias4.f03:15.6:
use y
1
Fatal Error: Can't open module file 'y.mod' for reading at (1): No such
file or directory
is that acceptable? in your copy Tobias, do you have a function called
gfc_verify_binding_labels? if you do, then i'm not sure why the above
code isn't getting reported as an error.
again, i'll submit my next patch once the one from Feb. 24 has been
committed to make things easier.
Chris