[Fortran, RFC patch] Document naming and argument passing convention

Janne Blomqvist blomqvist.janne@gmail.com
Sat Mar 30 19:15:00 GMT 2013

On Fri, Mar 29, 2013 at 8:42 PM, Tobias Burnus <burnus@net-b.de> wrote:
> Ups - I attached the wrong patch (same file name, wrong directory).
> Hopefully, this one is the correct one.
> Tobias
> Am 29.03.2013 19:40, schrieb Tobias Burnus:
>> Dear all,
>> the attached patch attempts to document gfortran's naming and argument
>> passing convention when Bind(C) is not used.
>> While Bind(C) is the recommended way for interoperation with other Fortran
>> compilers and other languages, there are situations where this is not
>> possible; for instance, legacy code. Or in case of the MPI standard, the MPI
>> implementation might need this information and MPI performance tool
>> developers (PMPI) have to know how the different Fortran compilers pass the
>> arguments.
>> The attached patch does not (yet) state how array descriptors are handled
>> internally. (I was thinking of deferring this until the new array descriptor
>> becomes available.) I also believe there are other omissions as well and the
>> wording could be improved. Suggestions are welcome.
>> The patch was motivated by Walter's comment** to my VALUE+OPTIONAL patch.*
>> It takes his comments into account and, that part, only reflects gfortran's
>> implementation after the VALUE+OPTIONAL patch has been committed with his
>> suggested change.
>> What do you think?
>> Tobias
>> * http://gcc.gnu.org/ml/fortran/2013-03/msg00102.html
>> ** http://gcc.gnu.org/ml/fortran/2013-03/msg00173.html

Thanks for the patch! Comments below:

+For logical types, please note that the Fortran standard only guarantees
+interoperability between C99's @code{_Bool} and Fortran's @code{C_Bool}-kind
+logicals and C99 defines that @code{true} has the value 1 and @code{false}
+the value 0.  In GCC, Boolean variables (Fortran @code{logicals} with and
+without C binding [and for all @code{kind} values], C99's @code{_Bool},
+C++'s @code{bool}, Ada's @code{Boolean}, etc.) all expect that only the
+value 0 and 1 are used; using other values might lead to wrong results.
+Therefore, using @code{logical(kind=c_int)} to interoperate with C99's
+@code{int} is discouraged and should be replaced either by
+@code{integer(kind=c_int)} on the Fortran side (which can then be
+converted to @code{logical}) -- or to use @code{_Bool} and
+@code{logical(kind=c_bool)}. Note that some other (Fortran) compilers
+use a different value for @code{.true.} (e.g. @math{-1}), even with C binding.

This seems to partly repeat what is already said at


IMHO we shouldn't repeat stuff like that; that part might be better
suited as part of the mixed-language programming chapter, if you think
so, please delete the above existing chapter. Or just replace the text
with a short reference to the (updated?) description in the other
chapter, or something like that.

+For procedures and variables declared in the specification space of a
+module, the name is formed by @code{__}, followed by the lower-cased
+module name, @code{_MOD_}, and the lower-cased Fortran name.  Note that
+no underscore is appended.

Would it be worth shortly mentioning the various compiler-generated
symbols (e.g. vtables)? BTW, did the patch that changes all those to
use the "_F" prefix go in, or are we still doing something else?

+Arguments are passed according to the platform ABI. In particular,
+complex arguments may not be compatible to a struct with two real
+components for the real and imaginary part; and complex values are
+returned as result and not by reference.

Here it might be worth mentioning that Fortran complex arguments are
ABI-wise handled like C99 _Complex types.

+For @code{OPTIONAL} dummy arguments, an absent argument is denoted
+by a NUL pointer, except for scalar dummy arguments of type


Janne Blomqvist

More information about the Gcc-patches mailing list