This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: [Fortran-Experiments]: patch
hi Tobias,
* * *
Request for comments:
As a mere user of Fortran 2003 code (such as F03GL), I'm overwhelmed by
"[variable] may not be C interoperable" warnings. Compiling F03GL:
| $ gfortran -c -fno-range-check OpenGL_glut.f90 2>&1 |wc -l
| 65
However, as programmer of Fortran 2003 code, I really like these warnings.
Of cause, in both cases I usually run "gfortran" without further options.
Nonetheless, I'm thinking of only showing these warnings with -std=f2003
or -pedantic or -Wall, but not by default. Comments, suggestions?
i've been considering this too and have added a function
(gfc_check_any_c_kind) that basically will ignore the warning if it finds
any C kind that interops. this new function could be used to issue an
ERROR if no C kind is found to interop, and a warning if the user wishes
pedantic or something along those lines. i personally think the warnings
are useful in cases were a single fortran type/kind can interop with
multiple C types but having the warnings on by default is probably too
much.
* * *
With F03GL I actually found two errors in the current Bind(C)
implementation:
The following code is valid, but gfortran prints
"CHARACTER argument 'empty_string' to 'c_loc' must have a length of 1".
The string length is not specified and thus one. (Note: Character arrays
are allowed, independent of their size/dimension [they need to have a
target attribute, though]; for pointers: only pointers to scalars are
allowed - or one chooses one element of a pointer array (-> pointer
target, no longer a pointer).)
-----------------
module x
use iso_c_binding
contains
SUBROUTINE glutInit_f03()
TYPE(C_PTR), DIMENSION(1), TARGET :: argv=C_NULL_PTR
CHARACTER(C_CHAR), DIMENSION(1), TARGET :: empty_string=C_NULL_CHAR
argv(1)=C_LOC(empty_string)
END SUBROUTINE
end module x
this has been fixed. the issue was that i simply had not finished
implementing the scalar expression check that looks into the size of an
array if given the whole array. in my copy, this is happily accepted. i
have made a new test case out of this code.
Gfortran produces an internal compiler error for the following code. The
reason is (I think) the bind-label checking:
-----------------
subroutine display() bind(c)
implicit none
end
program main
implicit none
interface
subroutine display() bind(c)
end subroutine display
end interface
end
-----------------
this was a simple fix in the binding label checking. this is now happily
accepted with no ICE. thanks for the bug reports.
Not related to F03GL: The error checking of the "func" argument yields a
bogus error message:
"Variable 'glutcreatemenu' at (1) may not be a C interoperable kind but
it is bind(c)"
The correct error would use "Variable 'func'...". Therefore, it seems as
if the error message is printed twice for 'glutcreatemenu' and missing
for 'func' at:
-----------------
! Warning printed twice:
! Variable 'glutcreatemenu' at (1) may not be a C interoperable kind but it is bind(c)
MODULE OpenGL_glut
IMPLICIT NONE
INTERFACE
FUNCTION glutCreateMenu(func) BIND(C,NAME="glutCreateMenu")
use iso_c_binding
INTEGER :: glutCreateMenu ! <<<< two warnings
INTERFACE
SUBROUTINE func()! <<<<<< no warning
END SUBROUTINE func
END INTERFACE
END FUNCTION glutCreateMenu
END INTERFACE
END MODULE OpenGL_glut
-----------------
i'll look into why it's being duplicated and why the warning for func is
not printed. should be a simple fix.
Other missing parts encountered when trying the Bind C examples:
- c_f_procpointer is missing for CP2K; one needs to implement procedural
pointers first (no PR)
- F03 interface to pthreads: Fails due to a bug in IMPORT, PR30922
- F03GL has to be modified slightly as the storage equivalence of
character arrays and character strings is not properly honoured in
gfortran, PR 30940.
Question to Chris:
In http://gcc.gnu.org/ml/fortran/2007-02/msg00558.html you wrote:
"on my list of things to do yet for iso_c_binding, i have:
"1) add versions of c_f_pointer for complex type/kind combos"
Is this finished or what remains to do there?
i haven't started. i should probably get my patch for c_ptr/c_funptr
committed before this work so whoever implements these can follow what's
currently done in iso_c_*.
thanks for the feedback.
Chris