*ping* [Patch, Fortran] PR35203 - Fix VALUE + OPTIONAL handling for pass-by-value arguments

[Janne Blomqvist]

On Fri, Mar 29, 2013 at 7:22 PM, Tobias Burnus <burnus@net-b.de> wrote:
> Walter,
>
>
> W Spector wrote:
>>
>> I am wondering if your implementation is compatible with what IBM did in
>> their compiler:
>>
>> http://publib.boulder.ibm.com/infocenter/comphelp/v8v101/index.jsp?topic=%2Fcom.ibm.xlf101a.doc%2Fxlfopg%2Finterlang-passdata.htm
>>
>> In it, the order of arguments passed is:
>>   * All addresses or values (or both) of actual arguments
>>   * "Present" indicators for optional VALUE arguments
>>   * Length arguments for strings
>> Note that they set each "Present" indicator to zero if the argument is not
>> present, and 1 if the argument is present.
>
>
> The current implementation is slightly different: present and string-lengths
> are in one group, ordered by their appearance. While IBM puts them into
> different groups and puts first all optionals and then all string lengths.
>
> It probably makes sense to change this to match IBM's implementation.

IBM's is more compact if one has multiple such arguments due to
alignment, so yes, I agree it makes sense to use that.

BTW, any idea what ifort does? XL Fortran, and the hardware it runs
on, is quite esoteric for many users..

> Note that in gfortran, optional+value only applies to scalar real, complex,
> integer and logical - all others are passed by reference with copy in.
> (Well, that's at least the plan; currently, optional+value fails for
> characters and it is not implemented for nonscalars, derived types or
> polymorphic types.)

I wonder, would it make sense to do the copy in the callee rather than
in all the call sites as part of the call? Should be less code bloat,
and might allow skipping the copying if one can prove that the
argument is read-only?

As for the patch itself, Ok with the IBM style grouping. Please also
put a note in the 4.9 changes.html that the ABI for procedures with
OPTIONAL, VALUE has changed.


-- 
Janne Blomqvist