[PATCH, RFC] Fortran: do not copy back for parameter actual arguments [PR81978]

[Harald Anlauf]

Hi Paul,

Am 20.01.25 um 11:29 schrieb Paul Richard Thomas:
> Hi Harald,
>
> How did we miss that one for so long? This is certainly OK for mainline
> and, I would suggest, 14-branch.

alright, will do that.

> Thanks for the patch.

Thanks for the review!

Harald

> Paul
>
>
> On Sun, 19 Jan 2025 at 20:42, Harald Anlauf <anlauf@gmx.de> wrote:
>
>> Dear all,
>>
>> this patch addresses a long-standing difference between gfortran and
>> other brands: when an array actual argument was passed to a procedure,
>> and the dummy argument had no intent specified, we would often create
>> packing and unpacking code.  Only the case of the dummy argument
>> having intent(in) did avoid the unpacking.
>>
>> This resulted in the user experience that passing an array having the
>> PARAMETER attribute, i.e. a named constant that gcc could place in
>> read-only memory, was generating a segfault at runtime even if the
>> dummy argument was not modified in the invoked procedure.  It therefore
>> was often not possible passing such an argument to a procedure without
>> explicitly requiring a temporary that might not be needed. (*)
>>
>> Other brands tested do not crash:
>>
>> (1) Intel, Nvidia, AMD flang, g95 seem to not put PARAMETER into read-only
>>       memory.  One can write code by lying to the compiler and modify the
>>       array values.
>>
>> (2) NAG appears to prevent modification of variables with the PARAMETER
>>       attribute.  Code that lies to the compiler seems to have no effect,
>>       but that compiler has a checking option that detects an illegal
>>       assignment in the called procedure.
>>
>> The proposal is to simply not generate the unpacking / copying-back code
>> if the actual argument has the PARAMETER attribute.  Non-conforming code
>> should rather be either detected at compile-time (which we do to a
>> reasonable extent), or we might add (in the future) new checking code
>> that detects modification of the dummy similar to case (2) above.
>> (We do something like this e.g. for do-loop indices passed as actual
>> arguments).
>>
>> How do you think of this approach?
>>
>> BTW: attached patch regtests fine on x86_64-pc-linux-gnu.  ON for mainline?
>>
>> Thanks,
>> Harald
>>
>> (*) There is a missed-optimization in that we do not simply create
>> suitable array descriptors when passing to assumed-shape dummies,
>> which may avoid the packing.
>>
>>
>