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

[Tobias Burnus <burnus at net-b dot de>]

Janne Blomqvist wrote:
> On Fri, Mar 29, 2013 at 7:22 PM, Tobias Burnus <burnus@net-b.de> wrote:
> 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..

I tried to find it in their manual - but I couldn't.

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

I am a bit unsure. The advantage of doing it in the callee is surely 
that the callee-code knows that it owns the code and only has a single 
place for the code generation.

However, for arrays, it is often required to do some copy in already: To 
make the argument contiguous (explicit-size, (not applicable here: 
assumed-size,) contiguous attribute) - or, with the current array 
descriptor, for array CLASS to TYPE as gfortran only has element strides.

Thus, I fear that one might end up doing two copy-in: Once to create the 
actual argument in the caller and once in the callee.

BTW: Due to the copy-in, one can make use of the contiguity of the 
argument as one knows that the copied-in variable is contiguous. And in 
the callee, one can regard it (fn spec) as intent(in).

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

That was done in Rev. 197252.

I have updated the wiki's changelog; I will later create a patch to 
transfer all those changes to gcc-4.8/changes.html.

Thanks to you and Thomas for the OK - and thanks for the comments.

* * *

Regarding the ABI issues: I think VALUE+OPTIONAL is very rarely used. It 
is only valid since Fortran 2003 possible. The filled PR also only came 
up (by Toon) while looking at the standard and is not from a real-world 
code. Thus, this ABI breakage shouldn't matter.

Regarding the new array descriptor: The fortran-dev branch contains a 
nearly complete transition from (lbound, ubound, stride) to 
(lower_bound, extend, stride_multiplier); if I recall correctly, only a 
handful (<10) test-suite failures remained. I do not recall whether due 
to some issue where the stride is required but only the SM is available 
or some non-debugged other issue.

a) First step is to update the branch to the trunk.
b) Second step is the work on the remaining failures.
c) Is to add "elem_length" - without, the stride is not available in the 
array descriptor
[(b) might come after (c) depending on the issues.]
d) Third step is to get rid of the "offset" field - that will require a 
lot of work in the FE!
e) Afterwards, rank and type have to be split.
f) the fine tuning starts: e.g. which information should be in the 
descriptor - we have to think of things like the _vptr*
g) Optimizations for the new format, fine tuning, cleanup, bug fixing
h) Complete the TS29113 support
i) Doing all the other ABI breaking stuff we want to have

I think that's possible for 4.9 and would be nice, but especially (d) 
will be a lot of work!

Tobias

(* I am in favour of getting rid of the extra container around BT_CLASS, 
having them in the type makes life easier.)