On Saturday, May 21, 2022 at 11:26:43 AM UTC-4, Dan Nagle wrote:

> ..
> The relevance is that, once the function statement gives the name foo the
> function characteristic,
> the declaration of the local result variable cannot change it. The
> declaration can set other
> attributes, but cannot change whether a name refers to an entity that is a
> function or a subroutine.
> That is determined by whether the name appears in a function statement
> or a subroutine statement.

@Dan Nagle,

Re: your comment "The relevance is that, once the function statement gives the name foo the function characteristic, the declaration of the local result variable cannot change it,"

* are you saying a function statement `foo` prevents the name `foo` from it from being treated as a function result variable that is a procedure pointer to a subroutine whereas it can have other characteristics?

The following is a conforming program per my read of the Fortran 90 standard, chances are rather high every Fortran 90 and later compiler you can try will process the program ok:

print *, foo(1)
contains
function foo(a)
integer, intent(in) :: a
integer :: foo(2)
foo(1) = a
foo(2) = foo(1) + 1
end function
end

Do you think in this case once the function statement gives the name foo the function characteristic, the declaration of the local result variable cannot change it to an array of rank-1?

Hi,

You can't change a characteristic with a type statement. Full stop.
You can create a characteristic with a type statement, but you cannot
change an existing characteristic.

On May 21, 2022, Ron Shepard wrote
(in article <_n9iK.4090$Dr6.3622@fx06.iad>):

> On 5/21/22 10:26 AM, Dan Nagle wrote:
> [...]
> > > Thus "CALL foo" does not involved a reference to the function-name per the
> > > standard, instead it is a reference to a procedure pointer associated with
> > > `bar`. One can see it as though the "offending" line were `CALL bar` and
> > > there is nothing non-conformant when viewed as such.
> >
> > Not so. C1525 disagrees. The name appearing in a call statement must
> > designate
> > a subroutine.
>
> In that call statement, foo is a procedure pointer to a subroutine, so
> does that not qualify as designating a subroutine?

No. The name foo appears in a function statement,
which makes it a function.

The value of foo is a pointer to subroutine.
But foo is a function.

>
>
> > foo is the name of a function (whose value is a pointer to
> > subroutine).
>
> Without the result() clause, foo is the value of the function within the
> function body, which is a pointer to a procedure. A procedure pointer
> can point to either subroutines or functions, without restriction. There
> are not separate pointers for functions and for subroutines, they all
> share the same type declaration.

The use must be consistent with the declarations of pointer and target.
For example, the use must be consistent with the interface.

>
>
> Furthermore, after the pointer assignment, it would be illegal to
> reference foo as a function within the body of the function. It is
> REQUIRED to reference it only as a subroutine and with the interface
> that is consistent with that of the target subroutine.

The function result variable inherits all the characteristics
of the function name.

The statement declaring foo to be a pointer to subroutine
is invalid because it attempts to change the characteristics of foo.

The function statement declares two characteristics of foo:
1. foo is a function, and
2. foo has no arguments.

Neither can be contradicted and be standard-conforming.

(aside- this is real nitpicking)

In the above paragraph, shouldn't the prohibition on foo-as-function
start with the declaration of foo-as-pointer-to-subroutine?
So how do you assign a value at all?
What is the function result variable of a subroutine?

(end aside)

>
>
> >
> > Again, this can be cured by using a local variable to hold the value
> > returned from the function foo, the which can then be called.
>
> The result() clause was added to the language in order to allow direct
> recursion to the function from within the body of the function. Of
> course, the recursive attribute is required, either explicitly (f90) or
> implicitly (f2003), in this case. After result(r) is added, then any
> references to foo are to the function, while references to r are to the
> value. It is even allowed to do indirect recursion without the result()
> clause, it is only direct recursion from foo to itself that requires the
> result() clause. However, in this example, there is no recursion
> involved anywhere, direct nor indirect. If recursion is not involved
> then it seems like result() should not be necessary.

result was also added to allow the function value to be an array.
(This is one reason why result variables inherit all characteristics
of the function name- you want the array to have the correct shape.)

>
>
> Without result(), there is no ambiguity that within the body of the
> function that references to foo are references to the value.
>
> >
> > The theme is that one must distinguish the function-ness of foo
> > from the subroutine-ness of foo's result value. An extra variable does the
> > trick.
>
> Those two "-ness" are already distinguished. Without the result(), all
> references to foo within the body are to its value. With the result()
> clause, all references to foo are recursive references to the function
> itself. It follows that since no recursive references to foo are
> invoked, then result() is unnecessary. It is like declaring a variable
> and then not referencing it. Of course, in this case, that might not be
> a bad idea for human readers of the code, but it seems unnecessary for
> the compiler which knows all of this because there is no ambiguity in
> the language in this respect.

The ambiguity is that you want some references to foo to be a function,
and some references to foo to be a subroutine.

Whether foo is a function or a subroutine is a characteristic
that cannot change.

foo is a function because it is the name in a function statement.
The type of foo is irrelevant.

foo is not a subroutine because its name does not appear in a subroutine
statement.
Attempting to do so by setting the type of the result is not conforming.

<snip>

>
> $.02 -Ron Shepard

--
Cheers!

Dan Nagle

On 5/22/22 10:22 AM, Dan Nagle wrote:
[...]
> The function result variable inherits all the characteristics
> of the function name.

Your claim would seem to apply to both cases, with and without the
result() clause. Yet you have already stated that it doesn't, that it
only applies to the case without the result() clause.

Or are you claiming that with result(r), the entity r is not the result
variable? Or that the entity r does not inherit all the characteristics
of foo, the function name.

Either way, it seems like a contradiction to the above statement?

>
> The statement declaring foo to be a pointer to subroutine
> is invalid because it attempts to change the characteristics of foo.

Yet, with the result() clause you claim that the same thing is allowed.
Isn't this inconsistent with your above argument?

>
> The function statement declares two characteristics of foo:
> 1. foo is a function, and
> 2. foo has no arguments.

Within the body of the function, and without the result() clause,
references to foo are to the result value, not recursive references to
the function. This is the same as if it were say, an integer function.
References within the body would be to the integer value, not recursive
references to the function with no arguments. Here is another example of
this, which I think is conforming:

program func
write(*,*) foo(3)
contains
function foo(n)
integer :: foo(2) ! return an integer array.
integer, intent(in) :: n
foo(1) = -n
foo(2) = n
return
end function foo
end program func

Note that there is no result() clause. The result of the function is an
integer array, so result() is not necessary simply to declare an array
valued function. Also, within the function body, the references to
foo(1) and foo(2) are to the elements of the integer array, they are not
recursive references to the function with its single integer argument.

Is this small program conforming?

[...]
> result was also added to allow the function value to be an array.

The example above shows that result() is not required for this purpose.

> (This is one reason why result variables inherit all characteristics
> of the function name- you want the array to have the correct shape.)

See the above example which contradicts this statement.

>> Without result(), there is no ambiguity that within the body of the
>> function that references to foo are references to the value.

This is demonstrated with the above example. There is no result()
clause, and there is no ambiguity, even though foo(1) looks the same
with either interpretation.

>>> The theme is that one must distinguish the function-ness of foo
>>> from the subroutine-ness of foo's result value. An extra variable does the
>>> trick.
>>
>> Those two "-ness" are already distinguished.

This is demonstrated with the above code for the case of an integer
array. The language already distinguishes between foo(1) as a recursive
function reference and foo(1) as an array reference. The same occurs for
other types, including I believe procedure pointers.

> The ambiguity is that you want some references to foo to be a function,
> and some references to foo to be a subroutine.

There is no ambiguity. Without the result() clause, all references to
foo within the function body are to its value as an integer array in the
above example, and to a procedure pointer in the example being discussed.

>
> Whether foo is a function or a subroutine is a characteristic
> that cannot change.

foo is a function, and its value is a procedure pointer.

> foo is a function because it is the name in a function statement.
> The type of foo is irrelevant.

This statement is not consistent with the above example. There foo is a
function, and the type of its value is an integer array. References such
as foo(1) within the body of the function are to the integer array, not
recursive references to the function.

> foo is not a subroutine because its name does not appear in a subroutine
> statement.
> Attempting to do so by setting the type of the result is not conforming.

Are you claiming that the value of foo cannot be a procedure pointer
that is assigned to a subroutine either with or without the result() clause?

I remember Richard Maine saying that one should never write a function
that returns a pointer value. I'm not sure this is what he had in mind,
but perhaps this discussion reflects the wisdom of his warning.

However, having said that, if I were to write a function that returns a
procedure pointer, I would always use the result() clause to make it
easier for a human to understand, although I think the language is
unambiguous in either the result() or the no result() case.

$.02 -Ron Shepard

"Ron Shepard" wrote in message news:CYuiK.16679$wIO9.3518@fx12.iad...

> Within the body of the function, and without the result() clause,
> references to foo are to the result value, not recursive references to
> the function. This is the same as if it were say, an integer function.
> References within the body would be to the integer value, not recursive
> references to the function with no arguments. Here is another example of
> this, which I think is conforming:

> program func
> write(*,*) foo(3)
> contains
> function foo(n)
> integer :: foo(2) ! return an integer array.
> integer, intent(in) :: n
> foo(1) = -n
> foo(2) = n
> return
> end function foo
> end program func

> Note that there is no result() clause. The result of the function is an
> integer array, so result() is not necessary simply to declare an array
> valued function. Also, within the function body, the references to
> foo(1) and foo(2) are to the elements of the integer array, they are not
> recursive references to the function with its single integer argument.

This was an issue that Steve Lionel was certainly familiar with because
the Digital compiler had an extension that allowed for recursive
functions. When the standard itself expanded to allow recursive
procedures one could create standard-conforming programs where
the Digital extension led to a result inconsistent with what the
standard dictates, and the above example might be one such.

Of course, Digital had to follow the standard but yet not require
its user base to throw out all of their code at the same time. It's
kind of mind-bending to think about the function foo and the
result variable foo as different things with the same name in
the seminal example of this thread, but different things can indeed
have the same name. If you google my name the first thing it comes
up with is some pervert from the West Coast. Another thing about
names with which we are all familiar:
https://en.wikipedia.org/wiki/Haddocks%27_Eyes

I note that the title of this thread is intentionally provocative. If
it were something like "CALL the target of FOO when FOO is a
result variable that is a pointer to a subroutine" the thread would
not have been nearly as entertaining.

On 5/22/2022 1:44 PM, James Van Buskirk wrote:
<--SNIP-->

> It's kind of mind-bending to think about the function foo and the
> result variable foo as different things with the same name in
> the seminal example of this thread, but different things can indeed
> have the same name. If you google my name the first thing it comes
> up with is some pervert from the West Coast. Another thing about
> names with which we are all familiar:
> https://en.wikipedia.org/wiki/Haddocks%27_Eyes
>
Not only the same name, as James writes, but sometimes we use the same
notation but with different meanings.

Indeed, having multiple purposes/meanings of parentheses -- to hold a
sequence of subprogram arguments, and also to hold subscripts -- is the
cause of so many complicated and confusing rules. Had we used the
notation of other programming languages, "foo(n)" would be a function
invocation and "foo[n]" would be the n-th or (n+1)th element of array
"foo". As things stand in Fortran, we are burdened with mind-bending
stuff such as the following in F2008:

"If RESULT appears, the name of the result variable of the function is
result-name and all occurrences of the function name in execution-part
statements in its scope refer to the function itself. If RESULT does not
appear, the name of the result variable is function-name and all
occurrences of the function name in execution-part statements in its
scope are references to the result variable."

One could comically restate this quotation as "If RESULT appears, the
result is RESULT and the function is FUNCTION. If RESULT does not
appear, result is FUNCTION and function is RESULT".

-- CyrMag

On Monday, May 23, 2022 at 2:17:01 PM UTC+12, CyrMag wrote:
> On 5/22/2022 1:44 PM, James Van Buskirk wrote:
> <--SNIP-->
> > It's kind of mind-bending to think about the function foo and the
> > result variable foo as different things with the same name in
> > the seminal example of this thread, but different things can indeed
> > have the same name. If you google my name the first thing it comes
> > up with is some pervert from the West Coast. Another thing about
> > names with which we are all familiar:
> > https://en.wikipedia.org/wiki/Haddocks%27_Eyes
>
> Not only the same name, as James writes, but sometimes we use the same
> notation but with different meanings.
>
> Indeed, having multiple purposes/meanings of parentheses -- to hold a
> sequence of subprogram arguments, and also to hold subscripts -- is the
> cause of so many complicated and confusing rules. Had we used the
> notation of other programming languages, "foo(n)" would be a function
> invocation and "foo[n]" would be the n-th or (n+1)th element of array
> "foo".
> <-SNIP->

That would give [ ] multiple meanings. If you think parentheses have too many meanings in Fortran, what about the asterisk? It had 20 the last time I looked, and many of them are not obsolescent.

Hi,

On May 22, 2022, Ron Shepard wrote
(in article <CYuiK.16679$wIO9.3518@fx12.iad>):

> On 5/22/22 10:22 AM, Dan Nagle wrote:
> [...]
> > The function result variable inherits all the characteristics
> > of the function name.
>
> Your claim would seem to apply to both cases, with and without the
> result() clause. Yet you have already stated that it doesn't, that it
> only applies to the case without the result() clause.

Because that is the same name in the result variable and the function.
I have posted that I believe the code is valid, provided a differently-named
result variable is used.

I claim (again) that declarations may not contradict each other.

>
>
> Or are you claiming that with result(r), the entity r is not the result
> variable? Or that the entity r does not inherit all the characteristics
> of foo, the function name.
>
> Either way, it seems like a contradiction to the above statement?
>
> >
> > The statement declaring foo to be a pointer to subroutine
> > is invalid because it attempts to change the characteristics of foo.
>
> Yet, with the result() clause you claim that the same thing is allowed.
> Isn't this inconsistent with your above argument?

No, because with a result clause, the same name in the same scope
is not being given contradictory characteristics.

<snip>

> Here is another example of
> this, which I think is conforming:
>
> program func
> write(*,*) foo(3)
> contains
> function foo(n)
> integer :: foo(2) ! return an integer array.
> integer, intent(in) :: n
> foo(1) = -n
> foo(2) = n
> return
> end function foo
> end program func
>
> Note that there is no result() clause. The result of the function is an
> integer array, so result() is not necessary simply to declare an array
> valued function. Also, within the function body, the references to
> foo(1) and foo(2) are to the elements of the integer array, they are not
> recursive references to the function with its single integer argument.
>
> Is this small program conforming?

Where does a declaration contradict another declaration?

>
>
> [...]
> > result was also added to allow the function value to be an array.
>
> The example above shows that result() is not required for this purpose.
>
> > (This is one reason why result variables inherit all characteristics
> > of the function name- you want the array to have the correct shape.)
>
> See the above example which contradicts this statement.

Again, where are the contradictory declarations?

<snip>

>
> There is no ambiguity. Without the result() clause, all references to
> foo within the function body are to its value as an integer array in the
> above example, and to a procedure pointer in the example being discussed.

But your example declaration (integer function) the later declaration
does not contradict the earlier one.

Look, the statement "function foo" declares foo to be a function.
Declaring foo's return value to be a pointer-to-subroutine contradicts that,
if you try to use the same name. Declaring foo to return an integer array
does not contradict foo being a function.

>
>
> >
> > Whether foo is a function or a subroutine is a characteristic
> > that cannot change.
>
> foo is a function, and its value is a procedure pointer.

Correct. Which is why, in the same scope, they both cannot
be declared using the same name.

>
>
> > foo is a function because it is the name in a function statement.
> > The type of foo is irrelevant.
>
> This statement is not consistent with the above example. There foo is a
> function, and the type of its value is an integer array. References such
> as foo(1) within the body of the function are to the integer array, not
> recursive references to the function.

Note that "subsequent declaration" and "contradictory declaration" are
different cases.

Please.

Comment

A code is not standard-conforming unless the standard says what it means.

Fortran allows declarations of one name in one scope to be spread across
several statements. But the incremental declarations must all be consistent.

Recall that the OP asked why so many compilers "crash hard with internal
errors".
My answer is that many compilers have not seen a lot of code with procedure
pointers,
and they do not yet catch all the errors they might (and possibly will
someday).

--
Cheers!

Dan Nagle

On 5/18/2022 11:39 AM, pmk wrote:
> Only one Fortran compiler can cope with this usage -- most crash hard with internal errors -- but I contend that it's conforming usage.
>
> module m
> contains
> function foo()
> procedure(bar), pointer :: foo
> foo => bar
> call foo ! <-- CALL of a function
> end function
> subroutine bar
> print *, 'in bar'
> end subroutine
> end module
>
> program demo
> use m
> procedure(bar), pointer :: p
> p => foo()
> call p
> end
>

I respectfully disagree with Dan Nagle here.

Referencing Fortran 2018, 15.6.2.2 (Function subprogram), paragraph 3, says:

"The type and type parameters (if any) of the result of the function
defined by a function subprogram may be specified by a type
specification in the FUNCTION statement or by the name of the function
result appearing in a type declaration statement in the specification
part of the function subprogram. They shall not be specified both ways.
If they are not specified either way, they are determined by the
implicit typing rules in effect within the function subprogram. If the
function result is an array, allocatable, or a pointer, this shall be
specified by specifications of the name of the function result within
the function body. The specifications of the function result attributes,
the specification of dummy argument attributes, and the information in
the procedure heading collectively define the characteristics of the
function (15.3.1)"

P4 then says, in part, "If RESULT does not appear, the name of the
function result is function-name and all occurrences of the function
name in execution-part statements in its scope are references to the
function result."

NOTE 1 then says, "The function result is similar to any other entity
(variable or procedure pointer) local to a function subprogram. Its
existence begins when execution of the function is initiated and ends
when execution of the
function is terminated."

Within the function, FOO is not a function, it is a local variable that
is the function result. Its characteristics are those declared in the
specification section as a procedure pointer with interface (BAR), which
happens to be a subroutine. This is fine, and there is no conflict or
duplicate declaration.

If we were to accept Dan's position that the FUNCTION statement causes
the function result to be a function, a function such as:

function BAZ ()
REAL :: BAZ
BAZ = 3.0
end function BAZ

would be invalid, since you can't assign 3.0 to a function.

This case is confusing, I'll admit. I note that NAG Fortran 7.1 rejects
it, complaining of a recursive reference to FOO. I'm going to run this
by the committee and see what they think. (I'll also report the ICE to
Intel, though not before I get an answer as to what it is supposed to do.)

--
Steve Lionel
ISO/IEC JTC1/SC22/WG5 (Fortran) Convenor
Retired Intel Fortran developer/support
Email: firstname at firstnamelastname dot com
Twitter: @DoctorFortran
LinkedIn: https://www.linkedin.com/in/stevelionel
Blog: https://stevelionel.com/drfortran
WG5: https://wg5-fortran.org

On Monday, May 23, 2022 at 4:29:31 PM UTC-7, Steve Lionel wrote:

(snip)

> This case is confusing, I'll admit. I note that NAG Fortran 7.1 rejects
> it, complaining of a recursive reference to FOO. I'm going to run this
> by the committee and see what they think. (I'll also report the ICE to
> Intel, though not before I get an answer as to what it is supposed to do.)

Much of this can be confusing to humans, if not the compiler.

Since you can't call integers, or add functions, we know the difference
between an integer variable and procedure pointer.

I know it slightly better in C, and maybe it is a little less confusing.

In C you can declare a function:

double fun();

or a function pointer:

double (*fp)();

Also, in C () is the function call operator, similar to the way [] is the
array reference operator. (It isn't quite as easy in Fortran.)

You can assign to a function pointer:

fp=sqrt; // no () operator

and call a function using a dereferenced function pointer:

x=(*fp)(2.0);

However, it seems that C lets you get away with calling a function
pointer instead of a function:

x=fp(2.0);
even though maybe it shouldn't.

But now, consider a function that returns a function pointer.

Here is one place where the difference between C and Fortran appears.
In C, you can reference an array element of an array (actually
a pointer) returned by a function:

double *af();
x = af()[0];

while Fortran requires assigning the function value to an array.

But now, consider a function returning a function pointer,
a function pointer to such function, and reference using it.
and then a call to the function from the returned pointer.

Declare function pointer to function returning a function pointer:
double (*(*fpp)())();

Declare function returning a function pointer:
double (*ffp())();

ffp=fpp; // point to the function

Call the function, and then the returned function:

printf("%f\n", (*fpp())(3.14));

or call it this way:

printf("%f\n", (fpp())(3.14));

I don't know how to write or call functions returning function pointers,
or pointers to them in Fortran. Here is the whole C program:

#include <stdio.h>
#include <math.h>
int main() {
double (*fp)();
double (*(*fpp)())();
double (*ffp())();
fp=sqrt;
printf("%f\n", (*fp)(2.0));
printf("%f\n", fp(2.0));
fpp = ffp;
printf("%f\n", (*fpp())(3.14));
printf("%f\n", (fpp())(3.14));
}

double (*ffp())() {
return cos;
}

On Monday, May 23, 2022 at 7:29:31 PM UTC-4, Steve Lionel wrote:

> ..
> This case is confusing, I'll admit. I note that NAG Fortran 7.1 rejects
> it, complaining of a recursive reference to FOO. I'm going to run this
> by the committee and see what they think.

Given OP's first line, "Only one Fortran compiler can cope with this usage," I had been wondering whether NAG Fortran was the one that managed to "cope with this usage". Your note that "NAG Fortran 7.1 rejects it, complaining of a recursive reference to FOO" is interesting. The note by @Juergen Reuter upthread, ".. if the function is defined as recursive. Then gfortran and Nagfor can compile, Nagfor even the original code with the -f2018 flag (using the Fortran 2018 standard where every function is recursive)" had indicated the same.

Given the situation, your plan that "I'm going to run this by the committee and see what they think" is perfect. Thank you, it will be very helpful to learn of the committee feedback.

On 5/23/2022 7:29 PM, Steve Lionel wrote:
> This case is confusing, I'll admit. I note that NAG Fortran 7.1 rejects
> it, complaining of a recursive reference to FOO. I'm going to run this
> by the committee and see what they think. (I'll also report the ICE to
> Intel, though not before I get an answer as to what it is supposed to do.)

Malcolm Cohen (NAG Fortran, standard editor) said, "There is no doubt
that within FOO, FOO is the eponymous result name, not the name of the
subprogram. This is similar to functions returning arrays – within an
array function F with no RESULT clause, F(I,J) is an array element of
the result, not a recursive self-reference."

--
Steve Lionel
ISO/IEC JTC1/SC22/WG5 (Fortran) Convenor
Retired Intel Fortran developer/support
Email: firstname at firstnamelastname dot com
Twitter: @DoctorFortran
LinkedIn: https://www.linkedin.com/in/stevelionel
Blog: https://stevelionel.com/drfortran
WG5: https://wg5-fortran.org

On Tuesday, May 24, 2022 at 8:17:49 AM UTC-5, Steve Lionel wrote:
> On 5/23/2022 7:29 PM, Steve Lionel wrote:
> > This case is confusing, I'll admit. I note that NAG Fortran 7.1 rejects
> > it, complaining of a recursive reference to FOO. I'm going to run this
> > by the committee and see what they think. (I'll also report the ICE to
> > Intel, though not before I get an answer as to what it is supposed to do.)
> Malcolm Cohen (NAG Fortran, standard editor) said, "There is no doubt
> that within FOO, FOO is the eponymous result name, not the name of the
> subprogram. This is similar to functions returning arrays – within an
> array function F with no RESULT clause, F(I,J) is an array element of
> the result, not a recursive self-reference."
> --
> Steve Lionel

In that case, the comment by PMK in the code fragment in the leading post:

call foo ! <-- CALL of a function

is incorrect, and perhaps misleading. On this line, "foo" is not the function FOO, but a pointer that is associated with a subroutine, and it is that subroutine that is being called through the pointer, and there is no the function itself being (recursively or otherwise) "called", as the comment suggests.

Do you agree, Steve L.?

-- Cyrmag

On Tuesday, May 24, 2022 at 9:17:49 AM UTC-4, Steve Lionel wrote:
> ..
> Malcolm Cohen (NAG Fortran, standard editor) said, "There is no doubt
> that within FOO, FOO is the eponymous result name, not the name of the
> subprogram. This is similar to functions returning arrays – within an
> array function F with no RESULT clause, F(I,J) is an array element of
> the result, not a recursive self-reference." ..

Thank you for the follow-up, that is very useful to know. I wonder whether NAG Fortran team will open up a support incident on this.

On Monday, May 23, 2022 at 4:29:31 PM UTC-7, Steve Lionel wrote:

(snip)

> If we were to accept Dan's position that the FUNCTION statement causes
> the function result to be a function, a function such as:
> function BAZ ()
> REAL :: BAZ
> BAZ = 3.0
> end function BAZ
> would be invalid, since you can't assign 3.0 to a function.
It seems to me that isn't quite right. Variables can have different
attributes, depending on where they are used.

My first thought is that I should be able to use an array as a DO
variable, since I can assign one in an assignment statement.

integer i(10)
do i=1,10
print *,i
enddo

I expect this not to work, even though there is nothing wrong
with assigning to i.

But yes, in an assignment statement BAZ is an integer variable,
and not a function, so the assignment works.

On 5/24/2022 9:26 PM, FortranFan wrote:
> Thank you for the follow-up, that is very useful to know. I wonder whether NAG Fortran team will open up a support incident on this.

Yes, Malcolm filed one. I have also reported the ICE to Intel.

--
Steve Lionel
ISO/IEC JTC1/SC22/WG5 (Fortran) Convenor
Retired Intel Fortran developer/support
Email: firstname at firstnamelastname dot com
Twitter: @DoctorFortran
LinkedIn: https://www.linkedin.com/in/stevelionel
Blog: https://stevelionel.com/drfortran
WG5: https://wg5-fortran.org

On 5/24/2022 7:39 PM, CyrMag wrote:
> In that case, the comment by PMK in the code fragment in the leading post:
>
> call foo ! <-- CALL of a function
>
> is incorrect, and perhaps misleading.

Yes.

--
Steve Lionel
ISO/IEC JTC1/SC22/WG5 (Fortran) Convenor
Retired Intel Fortran developer/support
Email: firstname at firstnamelastname dot com
Twitter: @DoctorFortran
LinkedIn: https://www.linkedin.com/in/stevelionel
Blog: https://stevelionel.com/drfortran
WG5: https://wg5-fortran.org