This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]