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

Tobias Burnus burnus@net-b.de
Sat Mar 30 19:51:00 GMT 2013


Janne Blomqvist wrote:
> 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.

I will try to improve this.

> +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?

I was thinking of not mentioning the handling of special things like 
ENTRY, alt-returns, compiler-generated virtual tables etc. However, if 
you think that it fits into this chapter, I can add it.

Regarding the _F prefix: Yes, the patch for GFC_PREFIX (_F. or _F$ or 
_F_) went in, but it is (currently) only used to mangle the 
hidden-length variable for the length of deferred-length characters. 
Actually, we should document that one as well.

> +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.

That was what I tried to imply by the platform ABI: The Fortran complex 
is handled like Ada's Complex and C's _Complex, which (at least on 
Alpha) is different to the struct version. However, if it helps, I can 
mention C (and/or Ada and/or Java and/or C++).

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

I never now how to write that value. Fortran has null(), C and C++ 
define NULL, C++11 has nullptr, ObjC has nil, ASCII has NUL. And 
internally, the value (void*) 0 is used, i.e. zero.

Tobias



More information about the Gcc-patches mailing list