On Fri, Mar 29, 2013 at 8:42 PM, Tobias Burnus <bur...@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
http://gcc.gnu.org/onlinedocs/gfortran/Internal-representation-of-LOGICAL-variables.html
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
s/NUL/NULL/
--
Janne Blomqvist
