On Sat, Mar 30, 2013 at 9:50 PM, Tobias Burnus <bur...@net-b.de> wrote:
> Janne Blomqvist wrote:
>> +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.
Hmm, if it's a long laundry list of special cases (ugh.. :( ), then
maybe it's not worth doing..?
>> +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++).
Ah, well, I at least didn't understand that implication, so it might
be useful to clarify it by explicitly mentioning _Complex.
Thanks,
--
Janne Blomqvist
