This is from a discussion on the gfortran mailing list.

The code

program memain
implicit none
call fail((1))
contains
subroutine fail(x)
integer :: x
x = x + 1
print *,x
end subroutine fail
end program memain

certainly looks wrong because the dummy argument is associated
with an expression that is not definable.

However, we have failed to find a prohibition in the standard.
The closest we could find was in F2018, "15.5.2.4 Ordinary dummy
variables", which states "If a dummy argument has INTENT (OUT)
or INTENT (INOUT), the actual argument shall be definable."
But this does not apply, because x does not have INTENT.

Where and how is this prohibited? Or, if this is not prohibited,
is this an oversight in the standard?

On Wednesday, July 5, 2023 at 9:04:06 AM UTC-7, Thomas Koenig wrote:

(snip)

> However, we have failed to find a prohibition in the standard.
> The closest we could find was in F2018, "15.5.2.4 Ordinary dummy
> variables", which states "If a dummy argument has INTENT (OUT)
> or INTENT (INOUT), the actual argument shall be definable."
> But this does not apply, because x does not have INTENT.
There is a fourth choice, which is no INTENT.

And, specifically, that is different from INOUT.

> Where and how is this prohibited? Or, if this is not prohibited,
> is this an oversight in the standard?

This has been known since the Fortran 66 days, though I don't know
where to find it in current standards. With INTENT, the compiler
can diagnose it. Without, especially for compiled separately,
they can't, and usually won't.

In some case, you can change the value of the constant.

PL/I removed this, by requiring the compiler to pass a modifiable
copy of the constant. For some reason, Fortran never did that.

On Wednesday, July 5, 2023 at 9:04:06 AM UTC-7, Thomas Koenig wrote:
> This is from a discussion on the gfortran mailing list.
>
> The code
>
> program memain
> implicit none
> call fail((1))
> contains
> subroutine fail(x)
> integer :: x
> x = x + 1
> print *,x
> end subroutine fail
> end program memain
>
> certainly looks wrong because the dummy argument is associated
> with an expression that is not definable.
>
> However, we have failed to find a prohibition in the standard.
> The closest we could find was in F2018, "15.5.2.4 Ordinary dummy
> variables", which states "If a dummy argument has INTENT (OUT)
> or INTENT (INOUT), the actual argument shall be definable."
> But this does not apply, because x does not have INTENT.
>
> Where and how is this prohibited? Or, if this is not prohibited,
> is this an oversight in the standard?

The code does not conform to the Fortran 2018 standard.
The relevant parts of the standard are subclause 8.5.10
paragraph 5, subclause 9.2, and subclause 10.2.1.1.
Subclause 10.2.1.1 does not apply directly, but it links
the other two parts.

Bob Corbett

Le 06/07/2023 à 12:44, Robert Corbett a écrit :
> On Wednesday, July 5, 2023 at 9:04:06 AM UTC-7, Thomas Koenig wrote:
>> This is from a discussion on the gfortran mailing list.
>>
>> The code
>>
>> program memain
>> implicit none
>> call fail((1))
>> contains
>> subroutine fail(x)
>> integer :: x
>> x = x + 1
>> print *,x
>> end subroutine fail
>> end program memain
>>
>> certainly looks wrong because the dummy argument is associated
>> with an expression that is not definable.
>>
>> However, we have failed to find a prohibition in the standard.
>> The closest we could find was in F2018, "15.5.2.4 Ordinary dummy
>> variables", which states "If a dummy argument has INTENT (OUT)
>> or INTENT (INOUT), the actual argument shall be definable."
>> But this does not apply, because x does not have INTENT.
>>
>> Where and how is this prohibited? Or, if this is not prohibited,
>> is this an oversight in the standard?
>
> The code does not conform to the Fortran 2018 standard.
> The relevant parts of the standard are subclause 8.5.10
> paragraph 5, subclause 9.2, and subclause 10.2.1.1.
> Subclause 10.2.1.1 does not apply directly, but it links
> the other two parts.
>

Looks like the 8.5.10 par.5 tells it all:

"If no INTENT attribute is specified for a dummy argument, its use is
subject to the limitations of its effective argument"

On Wednesday, July 5, 2023 at 12:04:06 PM UTC-4, Thomas Koenig wrote:

> ..
> Where and how is this prohibited? Or, if this is not prohibited,
> is this an oversight in the standard?

@Thomas Koenig,

What do you mean by "prohibited"?

There is no numbered constraint in this context that requires a conforming processor to detect and report any diagnostics here, if that is what you mean. The onus lies entirely on the writer of the program to conform.

Robert Corbett <robertpaulcorbett@gmail.com> schrieb:
> On Wednesday, July 5, 2023 at 9:04:06 AM UTC-7, Thomas Koenig wrote:
>> This is from a discussion on the gfortran mailing list.
>>
>> The code
>>
>> program memain
>> implicit none
>> call fail((1))
>> contains
>> subroutine fail(x)
>> integer :: x
>> x = x + 1
>> print *,x
>> end subroutine fail
>> end program memain
>>
>> certainly looks wrong because the dummy argument is associated
>> with an expression that is not definable.
>>
>> However, we have failed to find a prohibition in the standard.
>> The closest we could find was in F2018, "15.5.2.4 Ordinary dummy
>> variables", which states "If a dummy argument has INTENT (OUT)
>> or INTENT (INOUT), the actual argument shall be definable."
>> But this does not apply, because x does not have INTENT.
>>
>> Where and how is this prohibited? Or, if this is not prohibited,
>> is this an oversight in the standard?
>
> The code does not conform to the Fortran 2018 standard.

Which is not surprising, I was just searching for why.

> The relevant parts of the standard are subclause 8.5.10
> paragraph 5,

That is

# If no INTENT attribute is specified for a dummy argument, its use
# is subject to the limitations of its effective argument (15.5.2)

Following that, I do not find the prohibition, because 15.5.2.4 does
not apply (as before). Looking further

>subclause 9.2,

That is the definition of a variable.

> and subclause 10.2.1.1.

The definition of an assignment.

> Subclause 10.2.1.1 does not apply directly, but it links
> the other two parts.

Hm, I'm afraid that I do not yet see the connection between those
parts you quoted. Could you maybe elaborate?

pehache <pehache.7@gmail.com> schrieb:
> Le 06/07/2023 à 12:44, Robert Corbett a écrit :
>> On Wednesday, July 5, 2023 at 9:04:06 AM UTC-7, Thomas Koenig wrote:
>>> This is from a discussion on the gfortran mailing list.
>>>
>>> The code
>>>
>>> program memain
>>> implicit none
>>> call fail((1))
>>> contains
>>> subroutine fail(x)
>>> integer :: x
>>> x = x + 1
>>> print *,x
>>> end subroutine fail
>>> end program memain
>>>
>>> certainly looks wrong because the dummy argument is associated
>>> with an expression that is not definable.
>>>
>>> However, we have failed to find a prohibition in the standard.
>>> The closest we could find was in F2018, "15.5.2.4 Ordinary dummy
>>> variables", which states "If a dummy argument has INTENT (OUT)
>>> or INTENT (INOUT), the actual argument shall be definable."
>>> But this does not apply, because x does not have INTENT.
>>>
>>> Where and how is this prohibited? Or, if this is not prohibited,
>>> is this an oversight in the standard?
>>
>> The code does not conform to the Fortran 2018 standard.
>> The relevant parts of the standard are subclause 8.5.10
>> paragraph 5, subclause 9.2, and subclause 10.2.1.1.
>> Subclause 10.2.1.1 does not apply directly, but it links
>> the other two parts.
>>
>
> Looks like the 8.5.10 par.5 tells it all:
>
> "If no INTENT attribute is specified for a dummy argument, its use is
> subject to the limitations of its effective argument"

That could be it - the interpretation then would be that this is a
limitation, because the dummy argument is, in fact, not a variable
due to being associated with a constant expression?

On Saturday, July 8, 2023 at 4:59:15 AM UTC+12, Thomas Koenig wrote:
> pehache <peha...@gmail.com> schrieb:
> > Le 06/07/2023 à 12:44, Robert Corbett a écrit :
> >> On Wednesday, July 5, 2023 at 9:04:06 AM UTC-7, Thomas Koenig wrote:
> >>> This is from a discussion on the gfortran mailing list.
> >>>
> >>> The code
> >>>
> >>> program memain
> >>> implicit none
> >>> call fail((1))
> >>> contains
> >>> subroutine fail(x)
> >>> integer :: x
> >>> x = x + 1
> >>> print *,x
> >>> end subroutine fail
> >>> end program memain
> >>>
> >>> certainly looks wrong because the dummy argument is associated
> >>> with an expression that is not definable.
> >>>
> >>> However, we have failed to find a prohibition in the standard.
> >>> The closest we could find was in F2018, "15.5.2.4 Ordinary dummy
> >>> variables", which states "If a dummy argument has INTENT (OUT)
> >>> or INTENT (INOUT), the actual argument shall be definable."
> >>> But this does not apply, because x does not have INTENT.
> >>>
> >>> Where and how is this prohibited? Or, if this is not prohibited,
> >>> is this an oversight in the standard?
> >>
> >> The code does not conform to the Fortran 2018 standard.
> >> The relevant parts of the standard are subclause 8.5.10
> >> paragraph 5, subclause 9.2, and subclause 10.2.1.1.
> >> Subclause 10.2.1.1 does not apply directly, but it links
> >> the other two parts.
> >>
> >
> > Looks like the 8.5.10 par.5 tells it all:
> >
> > "If no INTENT attribute is specified for a dummy argument, its use is
> > subject to the limitations of its effective argument"
> That could be it - the interpretation then would be that this is a
> limitation, because the dummy argument is, in fact, not a variable
> due to being associated with a constant expression?
Indeed. And it's one of the many errors that compilers are not obliged to diagnose. In such cases compilers are free to do anything with the program, up to starting WWIII if appropriate hardware is fitted (as they used to say when f77 was the latest version.)

On 7/5/23 6:36 PM, gah4 wrote:
> In some case, you can change the value of the constant.

I've seen cases were the values of literal constants were changed. This
example isn't like that because the actual argument is an expression
(because of the parentheses) rather than a literal constant.

> PL/I removed this, by requiring the compiler to pass a modifiable
> copy of the constant. For some reason, Fortran never did that.

Fortran now has the VALUE attribute for dummy arguments. This does what
you are talking about, it requires the compiler to create a modifiable
copy of its actual argument. The dummy argument can be changed, while
the actual argument is never changed. I think this attribute requires an
explicit interface, since both the caller and the callee need to know
about it.

$.02 -Ron Shepard

On Friday, July 7, 2023 at 10:08:06 PM UTC-7, Ron Shepard wrote:
> On 7/5/23 6:36 PM, gah4 wrote:
> > In some case, you can change the value of the constant.

> I've seen cases were the values of literal constants were changed. This
> example isn't like that because the actual argument is an expression
> (because of the parentheses) rather than a literal constant.

As well as I know it, from when this question was asked years ago,
that doesn't get out of the problem. You are not supposed to modify
expression arguments, and so the compiler can pass the address
(usually) of a constant.

> > PL/I removed this, by requiring the compiler to pass a modifiable
> > copy of the constant. For some reason, Fortran never did that.

And PL/I specifically allows for constant in parentheses as
a modifiable temporary.

> Fortran now has the VALUE attribute for dummy arguments. This does what
> you are talking about, it requires the compiler to create a modifiable
> copy of its actual argument. The dummy argument can be changed, while
> the actual argument is never changed. I think this attribute requires an
> explicit interface, since both the caller and the callee need to know
> about it.
Yes. Well, that is also needed to make C interoperability work, in the
cases where the caller is C. But also, yes, it has to work when both
are Fortran.

But it would be so convenient for users, and not all that hard,
to supply modifiable temporaries for expressions and constants.

Note that in PL/I you can put a variable in parentheses and
get the modifiable temporary. As above, since Fortran doesn't
allow modifying expressions, it doesn't have to supply a
temporary at all, even for a variable.

Ron Shepard <nospam@nowhere.org> schrieb:
> On 7/5/23 6:36 PM, gah4 wrote:
>> In some case, you can change the value of the constant.
>
> I've seen cases were the values of literal constants were changed.

Ah yes, the famous "variation of constants".

This was an artefact of the calling conventions on IBM mainframes.
For

call foo(3.14159265)
print *,3.14159265

they passed a pointer to a constant 42 to foo, and since they didn't
want to waste space, the constant was there only once. And they usually
put the constants on the same pages as the executable code, so this
"worked". I guess it could come handy if the value of pi changed during
execution of the program.

These days, the constant is likely to be in read-only memory, so there
will be an access violation if anybody tries stuff like that.

>This
> example isn't like that because the actual argument is an expression
> (because of the parentheses) rather than a literal constant.

It would still be likely be implemented the same way, but it's been
a few decades since I last had access to VS Fortran :-)

On Sat, 08 Jul 2023 00:08:01 -0500, Ron Shepard wrote:

> On 7/5/23 6:36 PM, gah4 wrote:
>> In some case, you can change the value of the constant.
>
> I've seen cases were the values of literal constants were changed. This
> example isn't like that because the actual argument is an expression
> (because of the parentheses) rather than a literal constant.

The only place the Fortran standard mentions this issue is
in a note, which is non-normative.

F2023 (23-007r1.pdf), p. 114-115, Note 4, last paragraph.
INTENT (INOUT) is not equivalent to omitting the INTENT attribute. The
actual argument corresponding to an INTENT (INOUT) dummy argument is
always required to be definable, while an actual argument corresponding
to a dummy argument without an INTENT attribute need be definable only
if the dummy argument is actually redefined.

You'll find in the discussion of "effective argument" a statement that once
argument association is established, an actual argument can only be referenced
through the effective argument. This would mean that the following is
doubly non-conforming

program foo
call bar((1))
end program foo

subroutine bar(x)
x = 42 + (1)
end

--
steve

On Thursday, 6 July 2023 at 09:36:48 UTC+10, gah4 wrote:
> On Wednesday, July 5, 2023 at 9:04:06 AM UTC-7, Thomas Koenig wrote:
>
> (snip)
> > However, we have failed to find a prohibition in the standard.
> > The closest we could find was in F2018, "15.5.2.4 Ordinary dummy
> > variables", which states "If a dummy argument has INTENT (OUT)
> > or INTENT (INOUT), the actual argument shall be definable."
> > But this does not apply, because x does not have INTENT.
> There is a fourth choice, which is no INTENT.
>
> And, specifically, that is different from INOUT.
> > Where and how is this prohibited? Or, if this is not prohibited,
> > is this an oversight in the standard?
..
> This has been known since the Fortran 66 days,
..
and well before that.
Which is why PL/I did not fall into that trap.
..
> though I don't know
> where to find it in current standards. With INTENT, the compiler
> can diagnose it. Without, especially for compiled separately,
> they can't, and usually won't.
>
> In some case, you can change the value of the constant.
>
> PL/I removed this, by requiring the compiler to pass a modifiable
> copy of the constant. For some reason, Fortran never did that.
..
In the case of a constant, PL/I generates a temporary in which the value is placed,
and passes the address of the temporary.

On Saturday, 8 July 2023 at 17:23:38 UTC+10, gah4 wrote:
> On Friday, July 7, 2023 at 10:08:06 PM UTC-7, Ron Shepard wrote:
> > On 7/5/23 6:36 PM, gah4 wrote:
> > > In some case, you can change the value of the constant.
>
> > I've seen cases were the values of literal constants were changed. This
> > example isn't like that because the actual argument is an expression
> > (because of the parentheses) rather than a literal constant.
> As well as I know it, from when this question was asked years ago,
> that doesn't get out of the problem. You are not supposed to modify
> expression arguments, and so the compiler can pass the address
> (usually) of a constant.
> > > PL/I removed this, by requiring the compiler to pass a modifiable
> > > copy of the constant. For some reason, Fortran never did that.
> And PL/I specifically allows for constant in parentheses as
> a modifiable temporary.
..
I think that you mean a variable in parenthesls.
Constants as arguments always have a temporary generated,
and do not need to be in parentheses.
..
> > Fortran now has the VALUE attribute for dummy arguments. This does what
> > you are talking about, it requires the compiler to create a modifiable
> > copy of its actual argument. The dummy argument can be changed, while
> > the actual argument is never changed. I think this attribute requires an
> > explicit interface, since both the caller and the callee need to know
> > about it.
> Yes. Well, that is also needed to make C interoperability work, in the
> cases where the caller is C. But also, yes, it has to work when both
> are Fortran.
>
> But it would be so convenient for users, and not all that hard,
> to supply modifiable temporaries for expressions and constants.
>
> Note that in PL/I you can put a variable in parentheses and
> get the modifiable temporary. As above, since Fortran doesn't
> allow modifying expressions, it doesn't have to supply a
> temporary at all, even for a variable.