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