On 1/29/23 10:50 PM, gah4 wrote:
> On Sunday, January 29, 2023 at 2:39:16 PM UTC-8, Thomas Koenig wrote:
>
>
> (snip)
>
>> int a;
>> foo (&a);
>> printf ("%d\n",a);
>> a = 42;
>> bar ();
>> printf ("%d\n",a);
>
>> The compiler (and the reader) cannot assume that bar does not
>> change the value of a, because foo might have stashed it away in
>> static storage somewhere. Yes, this is a nuisance.
>
> But Fortran has COMMON, and now module variables, which can
> change at surprising times. Maybe not as surprising as for C.
> Even so, the compiler has to assume that any COMMON variable,
> and many module variables, can change.

If the above C code were rewritten in the straightforward way in
fortran, then the fortran bar() function cannot modify a. That is
because the local variable a is not a target, and it cannot be aliased
to any other subroutine argument or to anything in a module or in a
common block and then modified. Even if the function foo() were to use a
local pointer to a, it is not allowed for foo() to modify the value
through that pointer, because the actual argument is not a target (or
pointer). That is, foo() can access the value through its local pointer,
but it cannot modify that value. If bar() has access to that same
pointer, then the restrictions apply also to what a programmer is
allowed to do within bar().

Of course, a programmer can violate that constraint with trickery,
particularly when foo() and bar() are not written in fortran, but that
nonconforming code would be an error on the programmer's part, not a
feature of the fortran language as it is with C.

[...]
> Dynamic allocation, and especially the complications of assumed shape,
> do have overhead. In the olden days (through Fortran 77) static allocation
> allows low overhead access to arrays.

Now that the recursive attribute is the default, almost all local
entities must be dynamically allocated (i.e. stack or heap) when a
subprogram is entered. However, if all local variables are saved (which
means no automatic arrays are present), then it is pretty much back to
the same situation as pre-f90 code, where everything could be compiled
to static addresses. Presumably that would put the call overhead back to
similar pre-f90 levels. As you point out, there are also efficiency
downsides to that approach, e.g. the overall memory footprint is larger,
which can affect cache reuse and memory locality.

As for assumed shape arguments, the upside is that they no longer need
to be contiguous as they did for pre-f90 arrays, so that feature can
eliminate temporary copies from being required, either explicitly by the
programmer or implicitly by the compiler. Of course, there are
situations where a contiguous copy is more efficient to use, so
sometimes this new functionality is more efficient and sometimes less.
When a noncontiguous actual argument is associated with a dummy argument
that must be contiguous (e.g. explicit shape, assumed size, and so on),
then the compiler must make that copy implicitly during the call,
whether or not it is the most efficient choice.

$.02 -Ron Shepard