Is INTENT (IN) ever used to control code generation?

[john.c...@simconglobal.com]

We find large numbers of INTENT (IN) violations in some of the codes we analyse. They occur when an argument is declared INTENT (IN) and is passed down into another routine which changes it. It appears that the construct is un-maintainable in large codes with many authors.

The INTENT declarations are checked locally by all the compilers we have tested. The construct is useful in that it prevents some errors, and documents the beliefs of the author of the code. The concern is that the Fortran standard suggests that INTENT specifications may be used to guide code generation. It might be considered useful, particularly in multiprocessor systems, if INTENT(IN) arguments didn't need to be exported, or INTENT(OUT) arguments didn't need to be imported. The difficulty in maintaining the construct indicates that this would be a serious trap.

We experimentally removed all of the non-mandatory INTENT declarations from some large codes, and tested for changes in behaviour. So far, we have found none.

Does anyone know of any compilers which use INTENT declarations to guide code generation?

In the interests of code maintenance, would it be appropriate if the Fortran standard were changed to discourage the use of INTENT to guide code generation?

Best wishes,

John

[Gordon Sande]

Is the situation any different than calling with a literal (or
expression) which
is not supposed to be changed by a routine which is in turn called?

I seem to recall that this was a problem that could be diagnosed by the PFORT
Verifier. PFORT was for Fortran 66. I think that the SoftTools project had an
equivalent code for Fortran 77.

[Beliavsky]

On Friday, January 30, 2015 at 1:33:51 PM UTC-5, john.c...@simconglobal.com wrote:
> We find large numbers of INTENT (IN) violations in some of the codes we analyse. They occur when an argument is declared INTENT (IN) and is passed down into another routine which changes it. It appears that the construct is un-maintainable in large codes with many authors.
>

Maybe compilers should have an option to warn when an INTENT(IN) argument is passed as an argument to a procedure where it is not also declared INTENT(IN). Since new Fortran code will still call pre-Fortran-90 code that does not have INTENT declarations, it should not be expected that large codes will compile without warnings about INTENT.

[Paul van Delst]

Hello,

On 01/30/15 13:33, john.c...@simconglobal.com wrote:
> We find large numbers of INTENT (IN) violations in some of the codes
> we analyse. They occur when an argument is declared INTENT (IN) and
> is passed down into another routine which changes it. It appears
> that the construct is un-maintainable in large codes with many
> authors.

This is going to sound high-horse-y (and I don't mean it to be) but it
sounds like there is an issue with developer communication. Or
insufficient documentation of the internal APIs. Or both?

The first question that popped into my head was how come people writing
code down in the guts of the application aren't aware of the actual
argument INTENT of the callees (for those that are not local vars in the
callee)? Or vice versa for those folks writing the callers?

Also, shouldn't these sorts of things (mismatch of dummy and actual
argument INTENT) be caught during the code review stage? One of the
first things on a review checklist I would think.

cheers,

paulv

p.s. Full disclosure: I'm anal about argument INTENT. My requirement for
code delivered to me is that ALL dummies must have an INTENT specified.

[Beliavsky]

For the code

! module foo
! implicit none
! contains
function twice(x) result(x2)
real, intent(in) :: x
real :: x2
call double(x)
x2 = x
end function twice

subroutine double(x)
real, intent(in out) :: x
x = 2*x
end subroutine double
! end module foo

gfortran says

call double(x)
1
Warning: Dummy argument 'x' with INTENT(IN) in variable definition context (actual argument to INTENT = OUT/INOUT) at (1)

and g95 is silent. When the comment lines in the code are made "live" so that the procedures are in a module, gfortran and g95 both give compilation errors. It appears that another advantage of putting procedures in modules is to check INTENT.

[William Clodius]

First it is common to confuse INTENT(IN) with call by value input. If
the programmers wants a variable to be copied into the routine and
change the values of the entity associated witth that initial value
without those changes propagating up the call chain then in F2003 &
F2008 they can use the VALUE attribute. That is one of the easier
aspects of the compiler to implement so I expect it is almost
universally available. If not then in their code if A is the argument
with the appropriate value they must explicitly copy the value into
another enetity local to the procedure and perform all operations on
that entity. Note that call by value input can be expensive for simple
codes operating on large structures, e.g. arrays.

Second, if the writer of the top level code whose arguments are
INTENT(IN) understands the meaning of INTENT(IN) then he is almost
certainly assuming the value is not changing within the scope of the
code, and that assumption may introduce problems if the low level code
does not obey those assumptions. In any library if the library's code
does not obey the assumed API then the library has the strong potential
for bugs. Fortran's INTENT is a way of making the compiler aware of the
API and enforcing it. For this to work the programmers need to
consistently use INTENT.

INTENT is primarilly about self documenting code and not about
optimization. If the users are consistent in using INTENT, the compiler
can notice inconsistencies that can help you fix the code. In some cases
the compiler will assume that this documentation is correct (even if the
users haven't been consistent in using INTENT so the declarations can
not be fully checked for consistency) and use this assumption for
optimization, but optimization is not the primary intent of INTENT.

Your concerns appear to be caused by your programmers not following good
coding practices. They should first determine in detail what the code is
intended to do before writing the code. They should then write the
comments and the procedure interfaces befor writing the body of the
codes, Compiling the subprogram stubs would then identify any API
problems before large bodies of code gets commited to your version
control system. If necessary they should then negotiate changes in the
API with the writers of the top level code.

It is difficult for most people, myself included, to maintain this level
of discipline, but as a manager it is your job to let them know that
this is expected and how INTENT can help with this expectation.

[FortranFan]

On Friday, January 30, 2015 at 1:33:51 PM UTC-5, john.c...@simconglobal.com wrote:

> We find large numbers of INTENT (IN) violations in some of the codes we analyse. They occur when an argument is declared INTENT (IN) and is passed down into another routine which changes it. It appears that the construct is un-maintainable in large codes with many authors.
>

Are the codes not in Fortran MODULEs? With the use of modules, we have no such problem.

> The INTENT declarations are checked locally by all the compilers we have tested. The construct is useful in that it prevents some errors, and documents the beliefs of the author of the code. The concern is that the Fortran standard suggests that INTENT specifications may be used to guide code generation. It might be considered useful, particularly in multiprocessor systems, if INTENT(IN) arguments didn't need to be exported, or INTENT(OUT) arguments didn't need to be imported. The difficulty in maintaining the construct indicates that this would be a serious trap.
>
> We experimentally removed all of the non-mandatory INTENT declarations from some large codes, and tested for changes in behaviour. So far, we have found none.

Removing the INTENT attribute for dummy arguments doesn't seem to be the right way to go. It'll be good if you can first illustrate how modules (or other forms of interface checking) are being used, the different compilers and their checks that have been used to evaluate the code, the comprehensiveness of the unit tests, etc.

>
> ..

> In the interests of code maintenance, would it be appropriate if the Fortran standard were changed to discourage the use of INTENT to guide code generation?
>

NO! The use of INTENT is a matter of "religion" for us and we don't want any changes in the standard that might dilute the effectiveness of INTENT attribute in any way.

[Ian Harvey]

No. If compiler writers find opportunities to make optimizations based
on the stated intent of an actual argument then it should be permitted
to do so.

As others have suggested, compiler warnings in the face of general calls
to procedures with implicit interfaces (when the compiler doesn't know
the intent) or intent(in) actual arguments being associated with dummy
arguments in procedures with explicit interfaces but with the relevant
dummy arguments intent not specified would be far more useful.

Explicit interfaces and intent specifications are important for the
maintainability of large code bases. With those two features in play,
the opportunity for inadvertent INTENT(IN) violations is vastly reduced
(I think you are still exposed to pointer aliasing tricks). Fix the
cause, not the symptom.

[Gordon Sande]

The other way to get Fortran 90 level checking is to make all the
external routines
into contained routines. There are a couple gotchas but it does find a
lot of problems.

The recipe is to make up a new main program

program new_main
implicit none
call old_main
contains
. . . many include statements . . .
end program

with the previous main program turned into a subroutine called old_main
and with suitable upgrades to the end statements. You need to take out
all the external statments for the now contained routines. All this fails
if one is passing routines. If you do not have the source then this has no
hope.

Most of the changes can be automated so one wonders what would happen if the OP
were to try using this trick to get the benefit of F90 level checking.

[Paul van Delst]

Umm...I just want to go on record (as one of the "us" and "we" in the
above sentence) that my previously stated anality about the use of
INTENT does not extend to the level of religiosity.

Chill Dude-ingly Yours,

paulv

--
"I think you need to be more ... flexible" ~~ ElastiGirl

[Thomas Koenig]

Ian Harvey <ian_h...@bigpond.com> schrieb:

> If compiler writers find opportunities to make optimizations based
> on the stated intent of an actual argument then it should be permitted
> to do so.

And we do.

A recent case in gfortran concerned something like (simplified)

subroutine foo(a,n)
real :: a(n,n)
integer, intent(in) :: n

If n is intent(in), then it can be assumed that

a(1:n,1:n)

refers to the whole array. Otherwise, much more elaborate analysis
would be required to catch sick code like

subroutine foo(a,n)
real :: a(n,n)
integer :: n

n = n - 1

... and then do something with a(1:n,1:n).

[FortranFan]

Sorry, "us" and "we" refers to a private enterprise (that shall be unnamed) in manufacturing industry where significant code base in Fortran is used to develop and utilize various simulation and optimization tools. By "religiously" I mean one of the coding practice requirements for new procedures is to include INTENT attributes for dummy arguments and that code that doesn't make use of INTENT usually doesn't pass review and won't get absorbed into production.

[Gordon Sande]

Have I misunderstood a subtle point? I had been under the impression that
the value of n that was true at the subroutine entry was the one and only
value that mattered. Back in the bad old days compilers would use that
value to plug the code with all sorts of addressing constants so that
the later change to n did not matter.

[robin....@gmail.com]

Are you using explicit interfaces?

[Richard Maine]

The entry value of n is all that matters for the declaration, true. But
a reference in the executable code to a(1:n,1:n) would use the current
value of n at the time of execution of the reference. Thus, as Thomas
mentions, a(1:n,1:n) isn't necessarily all of the array even if the
array is dimensioned a(n,n), because the value of n used for the
declaration and for the reference isn't the same.

--
Richard Maine
email: last name at domain . net
domain: summer-triangle

[Gordon Sande]

Thank you. So a(;,:) would be the whole declared array but a(1:n,1:n)
would be the new submatrix only. Not a great coding style but possible.

[robin....@gmail.com]

On Saturday, January 31, 2015 at 12:00:06 PM UTC+11, Gordon Sande wrote:
> On 2015-01-31 00:23:31 +0000, Richard Maine said:
>

You mean a(:,:)

But it might be better to use just "a"

[robin....@gmail.com]

On Saturday, January 31, 2015 at 8:49:25 AM UTC+11, Thomas Koenig wrote:
> Ian Harvey <i.no...@bigpond.com> schrieb:

>
> > If compiler writers find opportunities to make optimizations based
> > on the stated intent of an actual argument then it should be permitted
> > to do so.
>
> And we do.
>
> A recent case in gfortran concerned something like (simplified)
>
> subroutine foo(a,n)
> real :: a(n,n)
> integer, intent(in) :: n

Old habits die hard.
It isn't necessary to pass "n".
subroutine foo (a)
is sufficient.

The bound can be picked up via HBOUND.

[FortranFan]

On Saturday, January 31, 2015 at 3:21:43 AM UTC-5, robin wrote:

> >
> > subroutine foo(a,n)
> > real :: a(n,n)
> > integer, intent(in) :: n
>
> Old habits die hard.
> It isn't necessary to pass "n".
> subroutine foo (a)
> is sufficient.
>
> The bound can be picked up via HBOUND.

UBOUND, not HBOUND.

[dpb]

On 01/31/2015 2:21 AM, robin....@gmail.com wrote:
> On Saturday, January 31, 2015 at 8:49:25 AM UTC+11, Thomas Koenig wrote:
>> Ian Harvey<i.no...@bigpond.com> schrieb:
>>
>>> If compiler writers find opportunities to make optimizations based
>>> on the stated intent of an actual argument then it should be permitted
>>> to do so.
>>
>> And we do.
>>
>> A recent case in gfortran concerned something like (simplified)
>>
>> subroutine foo(a,n)
>> real :: a(n,n)
>> integer, intent(in) :: n
>
> Old habits die hard.

...

More importantly existing code _never_ dies...

--

[robin....@gmail.com]

Hmm...at the time I was typing that I was thinking of UBOUND.
Finger got in the way.

[robin....@gmail.com]

On Sunday, February 1, 2015 at 1:14:13 AM UTC+11, dpb wrote:

Funny you should mention that. Just two weeks ago,
I downloaded some code that has been written in F90.
Unfortunately, it wouldn't compile.
There were hundreds of (kind = 8) phrases,
and, of course, x.yd0 everywhere.

After a lot of effort, I changed the declarations
to a portable form of kind, and made corresponding changes
to float constants.

If I ever need to change kinds, only one line needs to be changed ...

[Gordon Sande]

A good programmers editor would allow you to do those two types of changes
with TWO global pattern match edits. It can be a bit of a pain to figure out
the joys of setting up the pattern matches but very well worth the time.
There will probably still be a few named intrinsics and other details left over
that then need a bit more fussing.

If the original was not as clean as implied the global pattern searchs will
find the potential trouble spots more quickly than just reading the code.

Learning how to use the full capabilites of a good editor with regular
expression
capabilities takes a bit of patience but pays of many time over.

[glen herrmannsfeldt]

robin....@gmail.com wrote:
> On Saturday, January 31, 2015 at 8:49:25 AM UTC+11, Thomas Koenig wrote:

(snip)

>> A recent case in gfortran concerned something like (simplified)
>>
>> subroutine foo(a,n)
>> real :: a(n,n)
>> integer, intent(in) :: n

> Old habits die hard.
> It isn't necessary to pass "n".
> subroutine foo (a)
> is sufficient.

> The bound can be picked up via HBOUND.

For assumed size or explicit size arrays, you need to pass n.
Also, if not using the whole array, you need to pass both the
allocated size and the size actually being used.

Depending on how it is called, you may or may not be able to convert
easily to assumed shape.

-- glen

[robin....@gmail.com]

On Sunday, February 1, 2015 at 4:48:52 AM UTC+11, glen herrmannsfeldt wrote:

> r.no...@gmail.com wrote:
> > On Saturday, January 31, 2015 at 8:49:25 AM UTC+11, Thomas Koenig wrote:
>
> (snip)
> >> A recent case in gfortran concerned something like (simplified)
> >>
> >> subroutine foo(a,n)
> >> real :: a(n,n)
> >> integer, intent(in) :: n
>
> > Old habits die hard.
> > It isn't necessary to pass "n".
> > subroutine foo (a)
> > is sufficient.
>

> > The bound can be picked up via UBOUND.

>
> For assumed size or explicit size arrays, you need to pass n.

That was in the old days (pre F90).

> Also, if not using the whole array, you need to pass both the
> allocated size and the size actually being used.

That rarely happens then using dynamic arrays.
Dynamic arrays came with F90.
That's a quarter of a century ago.

> Depending on how it is called, you may or may not be able to convert
> easily to assumed shape.

Use an explicit interface and you don't have to worry about that.

[robin....@gmail.com]

On Sunday, February 1, 2015 at 2:44:49 AM UTC+11, Gordon Sande wrote:

You think that I didn't use one?

> with TWO global pattern match edits. It can be a bit of a pain to figure out
> the joys of setting up the pattern matches but very well worth the time.
> There will probably still be a few named intrinsics and other details left over
> that then need a bit more fussing.
>
> If the original was not as clean as implied the global pattern searchs will
> find the potential trouble spots more quickly than just reading the code.

All of the changes were done with an editor, searching.
But still each one needs to be visually inspected,
just to make sure that some meaning is not lost.
Making such changes in a large program need to be done carefully;
trying to find the one change that affected the results
can be difficult in a large program.

[john.c...@simconglobal.com]

Good try, but gfortran picks up the error only when the subroutine and the caller are in the same file. Please try the following:

! file: t_intent_in.f90
PROGRAM t_intent_in
INTEGER :: i
i = 1
WRITE(*,'("Before, i:",I2)')i
CALL s1_intent_in(i)
WRITE(*,'("After, i:",I2)')i
END PROGRAM t_intent_in

SUBROUTINE s1_intent_in(ia)
INTEGER,INTENT(IN) :: ia
CALL s2_intent_in(ia)
RETURN
END SUBROUTINE s1_intent_in
! End file t_intent_in.f90

! File s2_intent_in.f90
SUBROUTINE s2_intent_in(ia)
INTEGER :: ia
ia = 2
END SUBROUTINE s2_intent_in
! End file s2_intent_in.f90


#!/bin/csh -f
# File build_intent_in.csh
gfortran -c -g t_intent_in.f90
gfortran -c -g s2_intent_in.f90
gfortran -o t_intent_in.exe t_intent_in.o s2_intent_in.o
gfortran --version
# End file build_intent_in.csh


This, on my system, gives:

john@Kudu:/media/truecrypt1/fpt/fpttest$ ./build_t_intent_in.csh
GNU Fortran (Ubuntu 4.8.2-19ubuntu1) 4.8.2
Copyright (C) 2013 Free Software Foundation, Inc.

GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING

john@Kudu:/media/truecrypt1/fpt/fpttest$ ./t_intent_in.exe
Before, i: 1
After, i: 2
john@Kudu:/media/truecrypt1/fpt/fpttest$


gfortran fails to detect the violation. With large programs, the caller and called routines will often be compiled separately.

However, this has little to do with the original post: Do compilers use INTENT to control code generation?

Best wishes,

John

[john.c...@simconglobal.com]

>
> Does anyone know of any compilers which use INTENT declarations to guide code generation?
>

> In the interests of code maintenance, would it be appropriate if the Fortran standard were changed to discourage the use of INTENT to guide code generation?
>
> Best wishes,
>
> John

Thanks to those who have pointed out the the world's best climatologists and aerospace engineers are not the best Fortran programmers. We know. That is the point. The INTENT construct is a trap. If it is only a documentation trap, and compilers can evolve to improve checking, it obviously valuable. If it leads to bad code generation it is dangerous. I trust that those of you who write perfect code will destroy it when you retire in case it falls into the hands of less competent maintainers? So may I return to the original questions:

Does anyone know of any compilers which use INTENT declarations to guide code generation?

In the interests of code maintenance, would it be appropriate if the Fortran standard were changed to discourage the use of INTENT to guide code generation?

Best wishes,

John

[Clive Page]

On 01/02/2015 09:50, john.c...@simconglobal.com wrote:
> Thanks to those who have pointed out the the world's best climatologists and aerospace engineers are not the best Fortran programmers. We know. That is the point. The INTENT construct is a trap.

I disagree. I use INTENT(IN) for any subprogram argument that should
not be altered within the subprogram, and if I mistakenly write code
that tries to alter the value then I know that the compiler will tell me
of my mistake. It may be that there are some subtle cases where the
compiler cannot diagnose my mistake, but I know that it works in all the
obvious cases. I think that is a useful feature.


--
Clive Page

[Nick Maclaren]

In article <45665aab-3525-4263...@googlegroups.com>,

<john.c...@simconglobal.com> wrote:
>
>Thanks to those who have pointed out the the world's best climatologists an
>d aerospace engineers are not the best Fortran programmers. We know. That
> is the point. The INTENT construct is a trap. If it is only a documentat
>ion trap, and compilers can evolve to improve checking, it obviously valuab
>le. If it leads to bad code generation it is dangerous. I trust that thos
>e of you who write perfect code will destroy it when you retire in case it
>falls into the hands of less competent maintainers? So may I return to the
> original questions:

This is total nonsense. It is NOT a trap, and is perhaps the most
useful debugging facility in the standard.

Any competently organised project takes at least SOME steps to
enforce its coding standards - as is well-known in all contexts,
laws and rules that are never enforced cease to be useful. In
this one, it is trivial to write a simple Python (or Perl, if
you must) tool to check for missing INTENT and either diagnose
it or add INTENT(INOUT) and let the compiler diagnose it.

>Does anyone know of any compilers which use INTENT declarations to guide co
>de generation?

No, but all will, under some circumstances. The first one I
thought of is:

Passing an assumed-shape array or array section to an
explicit-size or assumed-size argument, where it needs to
it but MUST NOT copy back.

>In the interests of code maintenance, would it be appropriate if the Fortra
>n standard were changed to discourage the use of INTENT to guide code gener
>ation?

No.


Regards,
Nick Maclaren.

[Nick Maclaren]

In article <mal35b$mpr$1...@needham.csi.cam.ac.uk>,

Correction. I miscounted the negatives. Yes, it would be most
inappropriate.


Regards,
Nick Maclaren.

[robin....@gmail.com]

On Sunday, February 1, 2015 at 8:28:52 PM UTC+11, john.c...@simconglobal.com wrote:
> Good try, but gfortran picks up the error only when the subroutine and the caller are in the same file. Please try the following:

You are not using an explicit interface.
I enquired whether you were using one some 10 postings ago.
Why have you not tried that?

You could try the following (in which I have added ONE statement and
repositioned another one) :-

> ! file: t_intent_in.f90
> PROGRAM t_intent_in
> INTEGER :: i
> i = 1
> WRITE(*,'("Before, i:",I2)')i
> CALL s1_intent_in(i)
> WRITE(*,'("After, i:",I2)')i

CONTAINS

> SUBROUTINE s1_intent_in(ia)
> INTEGER,INTENT(IN) :: ia
> CALL s2_intent_in(ia)
> RETURN
> END SUBROUTINE s1_intent_in
> ! End file t_intent_in.f90
>
> ! File s2_intent_in.f90
> SUBROUTINE s2_intent_in(ia)
> INTEGER :: ia
> ia = 2
> END SUBROUTINE s2_intent_in

END PROGRAM t_intent_in

[Ron Shepard]

On 2/1/15 6:40 AM, robin....@gmail.com wrote:
> You could try the following (in which I have added ONE statement and
> repositioned another one) :-

To the OP, if you want to have the subroutines in a separate file, then
you can also move them into a module and get the same effect. This
allows separate compilation of the calling program and the module, while
still getting the benefits at compile time of the argument matching.

This is really an issue of explicit interfaces, of which INTENT is just
one aspect. It also includes type-kind-rank checks, and it allows
keyword arguments, all of which are really nice for the programmer.
Explicit interfaces are beneficial for both code development and code
maintenance. Gfortran, as an *extension*, gives you some of those
benefits when everything is in one file, but if you just use the
explicit interface features of the language, then you can get that and
more from any current fortran compiler.

There are several standard ways to get the benefits of explicit
interfaces. You can make the subroutines CONTAINED, as Robin did, that
is one way. You can place them into a module, and that is another way,
and one that has several advantages other than just the separate
compilation. And another way is to write interface blocks. This is, in
many ways, the least attractive approach, but it does have the advantage
that it may be used with existing external subprograms, including those
for which you do not have control of the source.

But, this also needs to be said. All of this compile time checking of
arguments definitely makes things better, but in the end, if you try
hard enough, you can still write illegal code and shoot yourself in the
foot. In your case, you are trying to declare INTENT(IN) arguments that
apparently become modified at some level in the code. The answer to this
problem is to stop doing that.

$.02 -Ron Shepard

[William Clodius]

We are saying that your complaint involves a red herring. Your reported
problem

> We find large numbers of INTENT (IN) violations in some of the codes we
> analyse. They occur when an argument is declared INTENT (IN) and is
> passed down into another routine which changes it. It appears that the
> construct is un-maintainable in large codes with many authors.

involves people using lower level libraries, and misinterpretting what
those libraries do. Any odd behavior involving effects of optimization
from INTENT involves the triggering of errors that were already latent
in the code that could be triggered again by any code modification. What
you need are people that read the documentation for the lower level code
and raise any issue with that documentation, documentation for the lower
level code that is complete and consistent with what that code does, and
code that does what its supposed to do.

Writing the low level code in Fortran 90+ and placing it in modules so
that the interfaces are explicit, would go a long way towards making
that code self documenting on the particular issues you are having. In
general it is easier to exploit F90+ by starting at the lowest levels
and working your way up. This detects problems incrementally. Your
programmers seem to either be doing this top down, or relying on
non-Fortran libraries.

[Fred Williamson]

On 2015-02-01, William Clodius <wclo...@earthlink.net> wrote:
><john.c...@simconglobal.com> wrote:
>
>> >
>> > Does anyone know of any compilers which use INTENT declarations to guide
>> > code generation?

Yes. Ada compilers have used that since the '95 language revision, possibly
earlier and it is enforced. I was so happy to see it mentioned that it was
in the Fortran (2008?) standard but reading this thread it looks like it's
not supposed to be implemented in the same way. What a shame...

>> Thanks to those who have pointed out the the world's best climatologists
>> and aerospace engineers are not the best Fortran programmers. We know.

Did you ever say a mouthfull there! The idea behind this kind of stuff is to
protect people from other people and occasionally from themselves. Personally
I am all in favor of that when done in an intelligent manner. The larger the
project the more you need clear interfaces.

Bottom line is there should be no side effects to subroutines or functions
(I think that is called PURE in new Fortran) and to make that happen all the
arguments should have documented modes like in, out, inout. Unfortunately
that is not 100% because like they say, when in doubt, inout. And that
subverts the usefulness greatly. But as you or somebody else said here the
point is not being unable to figure out a way to shoot yourself in the foot
but in using what features you have in the language and implementation to be
able to avoid doing that without trying too hard.

Fred

[Nick Maclaren]

In article <mam3mv$g12$1...@speranza.aioe.org>,

Fred Williamson <fred.wi...@nomail.org> wrote:
>><john.c...@simconglobal.com> wrote:
>>
>>> > Does anyone know of any compilers which use INTENT declarations to guide
>>> > code generation?
>
>Yes. Ada compilers have used that since the '95 language revision, possibly
>earlier and it is enforced. I was so happy to see it mentioned that it was
>in the Fortran (2008?) standard but reading this thread it looks like it's
>not supposed to be implemented in the same way. What a shame...

Don't believe all that you read .... It has been there, and
enforced, since Fortran 90. HOWEVER, because Fortran takes
compatibility extremely seriously, you can avoid enforcement
by using 'Old Fortran' techniques. Ada does not have the same
problem of compatibility with pre-1980 code.


Regards,
Nick Maclaren.

[William Clodius]

Fred Williamson <fred.wi...@nomail.org> wrote:

> On 2015-02-01, William Clodius <wclo...@earthlink.net> wrote:
> ><john.c...@simconglobal.com> wrote:
> >
> >> >
> >> > Does anyone know of any compilers which use INTENT declarations to guide
> >> > code generation?
>
> Yes. Ada compilers have used that since the '95 language revision, possibly
> earlier and it is enforced. I was so happy to see it mentioned that it was
> in the Fortran (2008?) standard but reading this thread it looks like it's
> not supposed to be implemented in the same way. What a shame...

Every sophisticated compiler will use the as if rule to perform
optimizations, and a consistent use of INTENT will provide more
information about the behavior of the code that the optimizer can
exploit. INTENT has been in the standard (with modules roughly
equivalent to Ada packages) since Fortran 90. However for compatibility
with older code INTENT has not been ever required, and is of minimal use
for some things such as C code compatibility. Still any conscientious
user will use INTENT and modules werever possible.

>
> >> Thanks to those who have pointed out the the world's best climatologists
> >> and aerospace engineers are not the best Fortran programmers. We know.
>
> Did you ever say a mouthfull there! The idea behind this kind of stuff is to
> protect people from other people and occasionally from themselves. Personally
> I am all in favor of that when done in an intelligent manner. The larger the
> project the more you need clear interfaces.
>
> Bottom line is there should be no side effects to subroutines or functions
> (I think that is called PURE in new Fortran) and to make that happen all the
> arguments should have documented modes like in, out, inout.

The standard has always made the behavior of side effect in functions
undefined, though that has not stopped users from using them, and
compilers from letting them get away with it. The term side effect has
several different meanings in computer science, and in its narrowest
usages would disallow any I/O, or INTENT(INOUT) variables, and perhaps
INTENT(OUT) variables, replacing them entirely by functions. That narrow
definition is impractical to enforce in any significantt Fortran code.

[robin....@gmail.com]

On Sunday, February 1, 2015 at 8:50:20 PM UTC+11, john.c...@simconglobal.com wrote:

> > Does anyone know of any compilers which use INTENT declarations to guide code generation?

Of course, if any procedure in the calling chain has a dummy argument
that does not specify INTENT (IN) for an argument that is passed down
several procedures as an INTENT (IN), then the procedure that does not
specify INTENT (IN) will break the chain, and it is highly unlikely
that any compiler will detect an assignment to such a variable in
the procedure in which no INTENT is specified.

In the case of a procedure that does specify INTENT (IN) for a
particular dummy argument, and which has an assignment to the dummy argument,
that violation should be picked up, even if the subroutine is compiled
separately.

What the compiler can detect is a dummy argument with INTENT (IN)
being passed to another procedure in which the corresponding
dummy argument does not have INTENT (IN).
For that to happen, you need to have an explicit interface.

The example you gave (of three procedures) does not use an
explicit interface, and parameter passing is in accordance with
the old (and error-prone) FORTRAN 77 and earlier mechanism.

To get the best out of your compiler, you need to stick to
those new features of Fortran 90 (and later) that were expressly
put in to deal with procedure calls and parameter passing.

[Nick Maclaren]

In article <7c0616d3-9ab0-43a0...@googlegroups.com>,

Yes. There was a question in WG5/J3 about passing a (hardware)
read-only assumed-shape array from C to Fortran, and it was
agreed (with dissenters) that it is not allowed, because of the
problem of (a) dropping the INTENT(IN) and (b) then passing it
as explicit-size or assumed-size.

HOWEVER, once you start using parallel programming and specialist
I/O, there are objects that are fundamentally read-only, and the
only solution is to ensure that does not happen. That issue is
one of the reasons that poorly engineering applications have so
much trouble with those facilities.

That is why I say that any correct compiler should generate the
copy back only if neither the actual argument nor the interface
dummy argument have INTENT(IN). My previous posting was actually
incorrect, for the reasons you (and others) give - in order to
get INTENT to work properly, all interfaces must be explicit.
But that's easy to do by writing a script to create a module
with all external procedure interfaces in it, and to include
that everywhere it is used.

One of the greatest advantages of Fortran over C++ is that this
sort of tool can be written by any good programmer, and it
does not need someone to modify a compiler like gcc. Parsing
Fortran enough to do this is easy.


Regards,
Nick Maclaren.

[Beliavsky]

One can set g95 compilation options so that procedure arguments without specified INTENT are rejected.

For the code

subroutine display(i)
integer :: i
print*,"i=",i
end subroutine display

compiling with

g95 -c -Wextra -Werror=163 no_intent.f90

gives the error message

In file no_intent.f90:1

subroutine display(i)
1
Error (163): Actual argument 'i' at (1) does not have an INTENT

I don't know of an analogous gfortran compiler option.

On Friday, January 30, 2015 at 1:33:51 PM UTC-5, john.c...@simconglobal.com wrote:
> We find large numbers of INTENT (IN) violations in some of the codes we analyse. They occur when an argument is declared INTENT (IN) and is passed down into another routine which changes it. It appears that the construct is un-maintainable in large codes with many authors.
>

> The INTENT declarations are checked locally by all the compilers we have tested. The construct is useful in that it prevents some errors, and documents the beliefs of the author of the code. The concern is that the Fortran standard suggests that INTENT specifications may be used to guide code generation. It might be considered useful, particularly in multiprocessor systems, if INTENT(IN) arguments didn't need to be exported, or INTENT(OUT) arguments didn't need to be imported. The difficulty in maintaining the construct indicates that this would be a serious trap.
>
> We experimentally removed all of the non-mandatory INTENT declarations from some large codes, and tested for changes in behaviour. So far, we have found none.

>
> Does anyone know of any compilers which use INTENT declarations to guide code generation?
>

[john.c...@simconglobal.com]

Please do not mis-understand me. I consider specification of INTENT to be an extremely valuable facility. However, we find large numbers of INTENT violations in existing programs. This is a measurement, not an opinion (And, by the way, this is not our code). If this were not a trap, fewer people would fall into it. What I am trying to do is to assess the seriosness of the trap. If it leads to bad code generation it is serious.

The problem could be removed if all sub-programs were enclosed in modules and all interfaces were fully defined. We have the engineering tools to do this (It isn't completely trivial, but it can be done). Is it worth it? There is a penalty in enclosing routines in modules. Almost any coding change in a low-level routine then triggers a rebuild of the entire system, even if the change has nothing to do with the interfaces. Perhaps we can do something with makefiles to prevent that?

Many thanks for all of the comments.

John

[Beliavsky]

On Monday, February 2, 2015 at 8:39:21 AM UTC-5, john.c...@simconglobal.com wrote:
> Please do not mis-understand me. I consider specification of INTENT to be an extremely valuable facility. However, we find large numbers of INTENT violations in existing programs.

It is because INTENT was specified that you know that the program does not behave the way some of the programmers thought it should. Now there is a chance to fix it.

[Richard Maine]

<john.c...@simconglobal.com> wrote:

> Almost any coding change in a low-level routine then triggers a rebuild of
> the entire system, even if the change has nothing to do with the
> interfaces. Perhaps we can do something with makefiles to prevent that?

Submodules can fix that. Admitedly, that's in the future, at least in
terms of being implemented widely enough to be able to assume that
they would be available in whatever environment you needed.

But this thread was talking about ideas for future standards. Future
standards start from the latest standards already published, so one does
need to look there. In my opinion, looking at what can be done with the
latest versions of the standard is better than trying to emasculate
features to better accomodate to f77-ish styles by ignoring intent in
code generation. I'm afraid that emasculation is what that strikes me
as. I have a mental image of a monkey covering its eyes to "see no evil"
on the theory that if he doesn't see an error in the code, then maybe it
won't cause him problems. I'd much rather make it easier to find the
errors.

--
Richard Maine
email: last name at domain . net
domain: summer-triangle

[Ian Harvey]

On 2015-02-03 12:39 AM, john.c...@simconglobal.com wrote:
> The problem could be removed if all sub-programs were enclosed in
> modules and all interfaces were fully defined.

You need to ensure all interfaces are fully defined (and all relevant
dummy arguments have an intent specification), but that does not mean
that you have to put all sub-programs in modules. It does then mean
that you have to make sure that procedure interface specifications are
consistent with the interface of the procedure, and that you don't
permit two definitions of the interface of a procedure to be accessible
in a scope at the same time. Current compilers can help with both of those.

[john.c...@simconglobal.com]

On Monday, February 2, 2015 at 5:13:22 PM UTC, Richard Maine wrote:
> <john.c...@simconglobal.com> wrote:
>
> > Almost any coding change in a low-level routine then triggers a rebuild of
> > the entire system, even if the change has nothing to do with the
> > interfaces. Perhaps we can do something with makefiles to prevent that?
>
> Submodules can fix that.

Thank you. Yes, I think that should (eventually) be the way to go.

At present, this monkey is peeping through his fingers to try to see which evil will cause most grief. The program I am most worried about is the climate code, WRF. If we were able to persuade the community to put everything into modules, I think the rebuild time for any change to the framework would climb from the current value of 20 minutes to well over an hour. That evil would kill development. If the coding errors in INTENT have no effect on execution (And we have never found one) then the evil is limited to the errors caused by the misunderstandings of the developers. If not, then by ignoring the issue we will spawn a whole new class of bug. If the developers create interfaces they will almost certainly write their misconceptions into the interfaces. They have demonstrated very successfully that they cannot maintain the INTENT declarations in the present environment.

We can find and fix all of the INTENT errors automatically. We have tools to do this, and that is how we know how many there are. This is not a solution. If the developers cannot maintain the construct they will make more errors, and we cannot mandate the tools which they use.

We will pray for sub-modules. We will need them in (at least) 6 compilers.

Best wishes,

John

[robin....@gmail.com]

On Wednesday, February 4, 2015 at 6:16:37 AM UTC+11, j.no...@simconglobal.com wrote:
> On Monday, February 2, 2015 at 5:13:22 PM UTC, Richard Maine wrote:

> > <j.no...@simconglobal.com> wrote:
> >
> > > Almost any coding change in a low-level routine then triggers a rebuild of
> > > the entire system, even if the change has nothing to do with the
> > > interfaces. Perhaps we can do something with makefiles to prevent that?
> >
> > Submodules can fix that.
>
> Thank you. Yes, I think that should (eventually) be the way to go.
>
> At present, this monkey is peeping through his fingers to try to see which evil will cause most grief. The program I am most worried about is the climate code, WRF. If we were able to persuade the community to put everything into modules, I think the rebuild time for any change to the framework would climb from the current value of 20 minutes to well over an hour. That evil would kill development. If the coding errors in INTENT have no effect on execution

Coding errors re INTENT are detected at compilation time. i.e.,
if INTENT is specified, and in the procedure there is an assignment
to the dummy argument, the error can be detected.
Without INTENT (IN) specified, there is no such error. The code is correct.

> (And we have never found one) then the evil is limited to the errors caused by the misunderstandings of the developers. If not, then by ignoring the issue we will spawn a whole new class of bug. If the developers create interfaces they will almost certainly write their misconceptions into the interfaces.

Really?

> They have demonstrated very successfully that they cannot maintain the INTENT declarations in the present environment.

Well, then, you will have to disabuse them.

> We can find and fix all of the INTENT errors automatically. We have tools to do this, and that is how we know how many there are. This is not a solution. If the developers cannot maintain the construct they will make more errors, and we cannot mandate the tools which they use.

New code needs to be checked.

[glen herrmannsfeldt]

robin....@gmail.com wrote:

(snip)

> Coding errors re INTENT are detected at compilation time. i.e.,
> if INTENT is specified, and in the procedure there is an assignment
> to the dummy argument, the error can be detected.
> Without INTENT (IN) specified, there is no such error. The code is correct.

As I remember, there is one case that INTENT(IN) can't detect at
compile time, but is still legal. That is, calls without INTENT.

As in versions before INTENT, you can call routines with non-modifiable
arguments, as long as you don't modify them. For external routines,
it can't be detected at compile time on most systems, but could be
at link time. I don't know any system that does detect it at
link time.

If you call "dusty deck" routines, they won't have INTENT.
I suppose one could go through and add them.

-- glen

[john.c...@simconglobal.com]

This is the case which I am concerned about. An INTENT(IN) argument is passed down into another routine for which the interface is not visible and is modified in that routine. If the routines are compiled separately, the compiler cannot detect this. Most systems use a linker which has no mechanism to detect the problem. One system, Salford/Silverfrost FTN95 detects the problem at run-time, but this is the only one we know.

A developer who calls a routine looks at an argument, sees that it is declared INTENT(IN) and programs accordingly. This causes errors.

The errors may be more serious if the compilation process assumes that INTENT(IN) arguments don't get changed. Hence the original question.

John

[Thomas Koenig]

john.c...@simconglobal.com <john.c...@simconglobal.com> schrieb:

> A developer who calls a routine looks at an argument, sees that
> it is declared INTENT(IN) and programs accordingly. This causes
> errors.

You mean something like

module foo
implicit none
contains
subroutine bar(n)
integer, intent(in) :: n
print *,"bar before dusty", n
call dusty(n)
print *,"bar after dusty", n
end subroutine bar
end module foo

program main
use foo
implicit none
integer :: n
n = 5
call bar(n)
end program main

subroutine dusty(n)
integer n
n = n - 1
end

?

I agree that it would be nice to have a compiler check for that.
Does any compiler do that?

[john.c...@simconglobal.com]

>
> You mean something like
>
> module foo

> implicit none -----

Yes. Salford/Silverfrost FTN95 (Under Windows) will do that:

The switch /lgo means load and go. Otherwise you need to compile and then link.

E:\simcon\test>ftn95 /checkmate dusty.f90 /lgo
[FTN95/Win32 Ver. 4.9.0 Copyright (C) Silverforst Ltd 1993-2005]
Licensed to: Mr John Collins
Organisation: SIMCON

PROCESSING MODULE [<FOO> FTN95/Win32 v4.9.0]
NO ERRORS [<BAR> FTN95/Win32 v4.9.0]
NO ERRORS [<FOO> FTN95/Win32 v4.9.0]
NO ERRORS [<MAIN> FTN95/Win32 v4.9.0]
NO ERRORS [<DUSTY> FTN95/Win32 v4.9.0]
Creating executable: E:\simcon\test\lgotemp@.exe
Program entered
bar before dusty 5

Then a window opens under the debugger with the message:


Call stack status:
Error 14, Attempt to alter an actual
argument that is a constant, an expression,
an INTENT(IN) argument, or a DO variable

DUSTY
FOO!BAR
main

There are also tools to find these - e.g. fpt or PlusFort. fpt gives:

!H!****************************************************************************
!H! File: dusty_f90.fpt
!H! Output by FPT 3.8-i Intel-Linux On 6-FEB-15 At 12:49:38 Input files:
!H! Main: /home/john/simcon/test/dusty.f90
!H! Current: /home/john/simcon/test/dusty.f90
!H! Licensee: SimCon: Development version.
!H!****************************************************************************
MODULE foo
IMPLICIT NONE
CONTAINS
SUBROUTINE bar(n)
INTEGER,INTENT(IN)::n
!----------------------------^-------------------------------------------------
!!! FPT - 2491 INTENT declared IN but argument is written to:
!------------------------------------------------------------------------------
PRINT *,"bar before dusty",n
CALL dusty(n)
PRINT *,"bar after dusty",n
END SUBROUTINE bar
END MODULE foo
!
PROGRAM main
USE foo
IMPLICIT NONE
INTEGER::n
n=5
CALL bar(n)
END PROGRAM main
!
SUBROUTINE dusty(n)
INTEGER n
n=n-1
END

Best wishes,

John

[Ian Harvey]

> I agree that it would be nice to have a compiler check for that.
> Does any compiler do that?

>ifort /Qdiag-enable:sc /warn:all "2015-02-07 dusty.f90"
Intel(R) Visual Fortran Intel(R) 64 Compiler XE for applications running
on Intel(R) 64, Version 15.0.1.148 Build 20141023
Copyright (C) 1985-2014 Intel Corporation. All rights reserved.
...
ifort: remark #10336: Static analysis complete; results available in
".\r006sc\r006sc.inspxe"

>inspxe-cl -report problems
P1: Error: IN arg modified: New
1
Other
2015-02-07 dusty.f90(7): error #12013: dummy argument "N" declared as
INTENT(IN) shouldn't be modified, but it is modified in "DUSTY" at
(file:2015-02-07 dusty.f90 line:22)
P1.1: Error: IN arg modified: New
2015-02-07 dusty.f90(7): error #12013: dummy argument "N" declared as
INTENT(IN) shouldn't be modified, but it is modified in "DUSTY" at
(file:2015-02-07 dusty.f90 line:22)
X1: Definition: U:\projects\FortranMisc\FortranMisc\2015-02-07
dusty.f90(7): Function BAR
X2: Bad memory write: U:\projects\FortranMisc\FortranMisc\2015-02-07
dusty.f90(22): Function DUSTY

[robin....@gmail.com]

On Friday, February 6, 2015 at 9:25:37 PM UTC+11, glen herrmannsfeldt wrote:

> r.no...@gmail.com wrote:
>
> (snip)
>
> > Coding errors re INTENT are detected at compilation time. i.e.,
> > if INTENT is specified, and in the procedure there is an assignment
> > to the dummy argument, the error can be detected.
> > Without INTENT (IN) specified, there is no such error. The code is correct.
>
> As I remember, there is one case that INTENT(IN) can't detect at
> compile time, but is still legal. That is, calls without INTENT.

Huh? You say INTENT (IN) can't detect.
Then you say calls without INTENT.
How it that going to detect anything?
To detect an error, you need INTENT (IN).
That's what we've been talking about.

> As in versions before INTENT, you can call routines with non-modifiable
> arguments, as long as you don't modify them. For external routines,
> it can't be detected at compile time on most systems,

What can't be detected?
When the external routine is compiled with INTENT (IN),
an assignment to the dummy argument will be detected --
and at compile time.

And anyway, we're not talking about routines without INTENT;
we're talking about routines having dummy arguments with INTENT(IN).

[robin....@gmail.com]

On Friday, February 6, 2015 at 10:38:15 PM UTC+11, j.no...@simconglobal.com wrote:

> This is the case which I am concerned about. An INTENT(IN) argument is passed down into another routine for which the interface is not visible and is modified in that routine.

You need to be using explicit interfaces, as I said before.

> If the routines are compiled separately, the compiler cannot detect this.

It can. The fact that the procedure has INTENT (IN) for a dummy argument
will produce an error message when the compiler finds an assignment
to that dummy argument. That's how it works.

> Most systems use a linker which has no mechanism to detect the problem.

The linker is there to link.

The compiler is there to tell you at compile time
when you assign a value to a dummy argument that has INTENT (IN)
specified.

> One system, Salford/Silverfrost FTN95 detects the problem at run-time, but this is the only one we know.
>
> A developer who calls a routine looks at an argument, sees that it is declared INTENT(IN) and programs accordingly. This causes errors.

That's because he has looked at the wrong thing.
He needs to look at the specification of the procedure that he is calling,
and program the call accordingly.

> The errors may be more serious if the compilation process assumes that INTENT(IN) arguments don't get changed.

The compiler checks that they don't in the procedure.

[robin....@gmail.com]

On Friday, February 6, 2015 at 11:29:59 PM UTC+11, Thomas Koenig wrote:
> j.no...@simconglobal.com <j.no...@simconglobal.com> schrieb:

>
> > A developer who calls a routine looks at an argument, sees that
> > it is declared INTENT(IN) and programs accordingly. This causes
> > errors.
>
> You mean something like
>
> module foo
> implicit none
> contains
> subroutine bar(n)
> integer, intent(in) :: n
> print *,"bar before dusty", n
> call dusty(n)
> print *,"bar after dusty", n
> end subroutine bar
> end module foo
>
> program main
> use foo
> implicit none
> integer :: n
> n = 5
> call bar(n)
> end program main
> subroutine dusty(n)
> integer n

This procedure needs to have INTENT (IN).
You don't have an interface for this procedure either.
This is the obsolete FORTRAN method of passing arguments,
and without an explicit interface, you can't expect anything.
Don't mix obsolete FORTRAN code with Fortran 90+ code.

> n = n - 1
> end
>
> ?
>
> I agree that it would be nice to have a compiler check for that.

You are mixing obsolete code with F90+ code.
Why do you think that the F90 features relating to
procedure calling and arguments were added?

[Gordon Sande]

The Fortran 66 PFORT Verifier did such an anlysis on a static basis. It
suffered
from the obvious problem that this is run time and data dependent so
they called
wolf on a worst case analysis. They were also worried about aliasing issues as
it was developed about the time when the first non call-by-reference Fortran
compilers showed up.

[Ron Shepard]

On 2/6/15 6:29 AM, Thomas Koenig wrote:

> subroutine dusty(n)
> integer n
> n = n - 1
> end

If you really do have access to the source code to your external
subroutines, as suggested here, then you can fix your problem by
declaring the intent in the external subprogram and making the interface
explicit in the calling program. In this case:

subroutine dusty(n)
integer, intent(inout) :: n

n = n - 1
end

When you do this, then the compiler will detect the mismatch between the
calling program, with INTENT(IN), and the called subroutine, with
INTENT(INOUT). I think this mismatch detection is required by the
standard, although you might need to specify compiler options to enable
it. All of the f90 and later compilers that I've used will detect this
error.

As I mentioned in a previous post, there are several ways to make the
interface explicit. The best way depends on the details of your actual
application.

Maybe something that you don't realize is that an undeclared INTENT is
not the same as INTENT(INOUT). It is primarily this issue of compile
time argument checking that is different between the two. Sometimes, you
really do need an undeclared INTENT argument, and in these cases, then
you can't have the compiler check for mismatches even with an explicit
interface. But when you can do both things, declare INTENT and have an
explicit interface, then you get compile time checking of the arguments.

$.02 -Ron Shepard

[john.c...@simconglobal.com]

> >ifort /Qdiag-enable:sc /warn:all "2015-02-07 dusty.f90"
> Intel(R) Visual Fortran Intel(R) 64 Compiler XE for applications running
> on Intel(R) 64, Version 15.0.1.148 Build 20141023
> Copyright (C) 1985-2014 Intel Corporation. All rights reserved.
> ...
> ifort: remark #10336: Static analysis complete; results available in
> ".\r006sc\r006sc.inspxe"
>
> >inspxe-cl -report problems
> P1: Error: IN arg modified: New
> 1
> Other
> 2015-02-07 dusty.f90(7): error #12013: dummy argument "N" declared as
> INTENT(IN) shouldn't be modified, but it is modified in "DUSTY" at
> (file:2015-02-07 dusty.f90 line:22)
> P1.1: Error: IN arg modified: New
> 2015-02-07 dusty.f90(7): error #12013: dummy argument "N" declared as
> INTENT(IN) shouldn't be modified, but it is modified in "DUSTY" at
> (file:2015-02-07 dusty.f90 line:22)
> X1: Definition: U:\projects\FortranMisc\FortranMisc\2015-02-07
> dusty.f90(7): Function BAR
> X2: Bad memory write: U:\projects\FortranMisc\FortranMisc\2015-02-07
> dusty.f90(22): Function DUSTY

Can ifort now do this if the routines are compiled independently in different files? My version can't!

John

[john.c...@simconglobal.com]

On Friday, February 6, 2015 at 2:20:46 PM UTC, robin....@gmail.com wrote:

> > subroutine dusty(n)
> > integer n
>
> This procedure needs to have INTENT (IN).
> You don't have an interface for this procedure either.
> This is the obsolete FORTRAN method of passing arguments,
> and without an explicit interface, you can't expect anything.
> Don't mix obsolete FORTRAN code with Fortran 90+ code.
>
> > n = n - 1
> > end

As far as I can see, the code of dusty is standard conforming. The INTENT specification is not mandatory and the code is not obsolete. It would become obsolete if it were rejected by compilers, and that would probably be a very good idea, except that most existing programs would no longer compile.

I strongly agree that specifying INTENT for all arguments and placing all sub-programs in modules would be a desirable way of solving the problem. But I do not think that this will be achieved without a change to the standard.

Best wishes,

John

[Richard Maine]

Ron Shepard <nos...@nowhere.org> wrote:

> Maybe something that you don't realize is that an undeclared INTENT is
> not the same as INTENT(INOUT).

Yes, and some of the cases of undeclared intent in dusty deck code can
get pretty nasty. An argument can be used for input on some calls and
output on other calls, depending on the values of other arguments. For
the cases where the argument is used as input, the actual argument can
be (and often is) a constant or other expression, which wouldn't be
alowed with intent(inout).

Horrible, horrible coding style. I'd suggest all sorts of extreme
punishment for the perpetrators, but they didn't know better back then,
so that would be like punishing infants. Yes, this stuff happens in
dusty code. It tends to tempt me to rip out the code in question and
redo it, but that's not always viable with 3rd-party code.

[glen herrmannsfeldt]

robin....@gmail.com wrote:
> On Friday, February 6, 2015 at 11:29:59 PM UTC+11, Thomas Koenig wrote:

(snip)

>> subroutine dusty(n)
>> integer n

>> n = n - 1
>> end

> This procedure needs to have INTENT (IN).

Since it modifies n, it probably should not have INTENT(IN).

> You don't have an interface for this procedure either.
> This is the obsolete FORTRAN method of passing arguments,
> and without an explicit interface, you can't expect anything.
> Don't mix obsolete FORTRAN code with Fortran 90+ code.

As far as I can tell, no INTENT isn't even obsolescent yet.

The way it is written in Fortran 2008, obsolescent features have
a better way to do something in Fortran 77.

(snip)

-- glen

[glen herrmannsfeldt]

Gordon Sande <Gordon...@gmail.com> wrote:
> On 2015-02-06 11:38:12 +0000, john.c...@simconglobal.com said:

(snip, I wrote)

>>> As in versions before INTENT, you can call routines with non-modifiable
>>> arguments, as long as you don't modify them. For external routines,
>>> it can't be detected at compile time on most systems, but could be
>>> at link time. I don't know any system that does detect it at
>>> link time.

(snip)

>> This is the case which I am concerned about. An INTENT(IN) argument is
>> passed down into another routine for which the interface is not visible
>> and is modified in that routine. If the routines are compiled
>> separately, the compiler cannot detect this.

(snip)

> The Fortran 66 PFORT Verifier did such an anlysis on a static basis.
> It suffered from the obvious problem that this is run time and
> data dependent so they called wolf on a worst case analysis.
> They were also worried about aliasing issues as it was developed
> about the time when the first non call-by-reference Fortran
> compilers showed up.

Which compilers were those? As far as I know, it goes pretty
far back.

-- glen

[glen herrmannsfeldt]

robin....@gmail.com wrote:

(snip, I wrote)

>> As I remember, there is one case that INTENT(IN) can't detect at
>> compile time, but is still legal. That is, calls without INTENT.

> Huh? You say INTENT (IN) can't detect.
> Then you say calls without INTENT.
> How it that going to detect anything?
> To detect an error, you need INTENT (IN).
> That's what we've been talking about.

If a routine with an INTENT(IN) argument calls a routine, and
passes that argument along to one without INTENT, the compiler
can't detect it. It is legal as long as the called routine doesn't
modify it, and it might even have statements that could modify it.

>> As in versions before INTENT, you can call routines with non-modifiable
>> arguments, as long as you don't modify them. For external routines,
>> it can't be detected at compile time on most systems,

> What can't be detected?
> When the external routine is compiled with INTENT (IN),
> an assignment to the dummy argument will be detected --
> and at compile time.

Except the case above.

> And anyway, we're not talking about routines without INTENT;
> we're talking about routines having dummy arguments with INTENT(IN).

That call other routines.

-- glen

[Gordon Sande]

The original Fortran II was a call-by-reference implementation. There was
not enough optimization that aliasing was not an issue. The Fortran IV for
IBM/360 had copy-in/copy-out for scalars so aliasing became an issue and as
there started to be some optimization with intermediate values in registers
across statements. The issue of storing into literals was/is an ongoing issue.

As a worst case static analyser PFORT could be a real beast in all the problems
it pointed at.

[robin....@gmail.com]

On Saturday, February 7, 2015 at 4:13:31 AM UTC+11, john.c...@simconglobal.com wrote:
> On Friday, February 6, 2015 at 2:20:46 PM UTC, robin....@gmail.com wrote:
>
> > > subroutine dusty(n)
> > > integer n
> >
> > This procedure needs to have INTENT (IN).
> > You don't have an interface for this procedure either.
> > This is the obsolete FORTRAN method of passing arguments,
> > and without an explicit interface, you can't expect anything.
> > Don't mix obsolete FORTRAN code with Fortran 90+ code.
> >
> > > n = n - 1
> > > end
>
> As far as I can see, the code of dusty is standard conforming.

As is all obsolete FORTRAN code (pre F90).
But as we know, old practices are prone to error
that are undetected by compilers.
Using the modern forms permit checks to be carried out
that can't be with old FORTRAN compilers.
Incidentally, the F compiler implements the modern Fortran forms,
and omits the old, error-prone forms.

> The INTENT specification is not mandatory

to allow obsolete code to continue to be be compiled.

> and the code is not obsolete.

Not in the standard's definition, but obsolete in the sense
that the old forms lead to undetectable errors.

> It would become obsolete if it were rejected by compilers,

You miss my point. The obsolete forms are error-prone.
Errors can pass undetected with the old forms.
With the new forms, errors can be detected.

> and that would probably be a very good idea, except that most existing programs would no longer compile.

Old (pre-F90) programs and those that avoid the modern forms
continue to compile, with few exceptions, for compatability reasons.

But those can let programming errors go undetected.

> I strongly agree that specifying INTENT for all arguments and placing all sub-programs in modules would be a desirable way of solving the problem.

Then why are you arguing against using these modern forms?

> But I do not think that this will be achieved without a change to the standard.

It doesn't require a change in the standard to get
the error-checking about which I wrote.

[robin....@gmail.com]

On Saturday, February 7, 2015 at 5:23:26 AM UTC+11, glen herrmannsfeldt wrote:

> r.no...@gmail.com wrote:
> > On Friday, February 6, 2015 at 11:29:59 PM UTC+11, Thomas Koenig wrote:
>
> (snip)
>
> >> subroutine dusty(n)
> >> integer n
> >> n = n - 1
> >> end
>
> > This procedure needs to have INTENT (IN).
>
> Since it modifies n, it probably should not have INTENT(IN).

Something about thickness of a couple of bricks.
The purpose of INTENT (IN) is to DETECT inadvertent
programming errors such as this in which a dummy argument
is modified when it shouldn't be.

> > You don't have an interface for this procedure either.
> > This is the obsolete FORTRAN method of passing arguments,
> > and without an explicit interface, you can't expect anything.
> > Don't mix obsolete FORTRAN code with Fortran 90+ code.
>
> As far as I can tell, no INTENT isn't even obsolescent yet.

Are you not able to recognise bad programming practice?

> The way it is written in Fortran 2008, obsolescent features have
> a better way to do something in Fortran 77.

????

[robin....@gmail.com]

On Saturday, February 7, 2015 at 5:33:24 AM UTC+11, glen herrmannsfeldt wrote:

> r.no...@gmail.com wrote:
>
> (snip, I wrote)
> >> As I remember, there is one case that INTENT(IN) can't detect at
> >> compile time, but is still legal. That is, calls without INTENT.
>
> > Huh? You say INTENT (IN) can't detect.
> > Then you say calls without INTENT.
> > How it that going to detect anything?
> > To detect an error, you need INTENT (IN).
> > That's what we've been talking about.
>
> If a routine with an INTENT(IN) argument calls a routine, and
> passes that argument along to one without INTENT, the compiler
> can't detect it.

That's what we've been saying.
That's because modern and obsolete forms have been intermixed.

> It is legal as long as the called routine doesn't
> modify it,

Legal doesn't make it correct.

> and it might even have statements that could modify it.

????

> >> As in versions before INTENT, you can call routines with non-modifiable
> >> arguments, as long as you don't modify them. For external routines,
> >> it can't be detected at compile time on most systems,
>
> > What can't be detected?
> > When the external routine is compiled with INTENT (IN),
> > an assignment to the dummy argument will be detected --
> > and at compile time.
>
> Except the case above.

That's because INTENT (IN) hasn't been used.

> > And anyway, we're not talking about routines without INTENT;
> > we're talking about routines having dummy arguments with INTENT(IN).
>
> That call other routines.

with INTENT (IN).

[Ian Harvey]

Yes, noting that I am using a component from their professional suite of
tools. I don't think this capability is particularly new.

Putting the main program and module into "dusty-a" and the external
procedure into "dusty-b", and compiling:


>ifort /c /Qdiag-enable:sc "2015-02-07 dusty-a.f90"
...

>ifort /c /Qdiag-enable:sc "2015-02-07 dusty-b.f90"
...

>ifort /Qdiag-enable:sc "2015-02-07 dusty-a.obj" "2015-02-07 dusty-b.obj"

...
ifort: remark #10336: Static analysis complete; results available in

".\r000sc\r000sc.inspxe"

>inspxe-cl -report problems
P1: Error: IN arg modified: New
1
Other

2015-02-07 dusty-a.f90(7): error #12013: dummy argument "N" declared as

INTENT(IN) shouldn't be modified, but it is modified in "DUSTY" at

(file:2015-02-07 dusty-b.f90 line:3)

P1.1: Error: IN arg modified: New

2015-02-07 dusty-a.f90(7): error #12013: dummy argument "N" declared as

INTENT(IN) shouldn't be modified, but it is modified in "DUSTY" at

(file:2015-02-07 dusty-b.f90 line:3)
X1: Definition: U:\projects\FortranMisc\2015\2015-02-07
dusty-a.f90(7): Function BAR
X2: Bad memory write: U:\projects\FortranMisc\2015\2015-02-07
dusty-b.f90(3): Function DUSTY


But perhaps it won't do this sort of analysis for much longer.

[FortranFan]

It's unclear why you keep suggesting a change to the standard, first to discourage the use of INTENT by compilers in code generation and this time to force the specification of INTENTs and placement in submodules. I don't see why the standard is relevant for this.

This seems to be the domain of compilers and code analysis (including static) tools.

As discussed elsewhere, compilers can support a warning flag (say -Wintent in the case of gfortran) that alerts to situations involving procedures where INTENT is missing. In addition, compilers can alert to situations when explicit interfaces are missing. Development teams can have a requirement such flags should be used in their work and all the ensuing warnings must be addressed before code gets "accepted."

While working with existing code, analysis tools can alert to situations where callee does not have INTENT whereas the actual argument in the caller corresponds to an INTENT(IN) dummy argument. The code analyst can then take suitable actions to improve the code.

So it is up to development teams and other code service providers to make best use of such tools to firm up the code they are working with.

It is time perhaps for organizations to start giving priority to "porting" their FORTRAN 77 and older code to modern Fortran.

[Ian Harvey]

In the following, all arguments have INTENT(IN) and all procedures have
an explicit interface, yet there is still a violation of the
restrictions around INTENT(IN) that will not be diagnosed by most
compilers (and the compilers that do diagnose it would likely still
diagnose it even if some arguments were missing INTENT or implicit
interfaces were in use).

PROGRAM p
IMPLICIT NONE
CALL execute
CONTAINS
SUBROUTINE execute
INTEGER :: variable
variable = 2
PRINT "('Before variable was ',I0)", variable
CALL sub(variable)
PRINT "('After variable was ',I0)", variable
END SUBROUTINE execute
SUBROUTINE sub(arg)
INTEGER, INTENT(IN), TARGET :: arg
INTEGER, POINTER :: ptr
ptr => arg
CALL xyz(ptr)
END SUBROUTINE sub
SUBROUTINE xyz(ptr)
INTEGER, POINTER, INTENT(IN) :: ptr
ptr = 3
END SUBROUTINE xyz
END PROGRAM p

(However, I repeat my view that that the standard should not include any
suggestion that compilers should not take advantage of INTENT
specification when generating code. I think the likelihood of this
(specific) sort of inadvertent violation is small; tools to identify
these sorts of violations exist, even if they are not used as part of
the very frequent, short term code-compile-execute loop; and the
requirements around INTENT(IN) aren't particularly special relative to
other requirements that programmers may happen to inadvertently violate,
which we all merrily accept.)

[glen herrmannsfeldt]

Gordon Sande <Gordon...@gmail.com> wrote:

(snip)

>>> They were also worried about aliasing issues as it was developed
>>> about the time when the first non call-by-reference Fortran
>>> compilers showed up.

>> Which compilers were those? As far as I know, it goes pretty
>> far back.

> The original Fortran II was a call-by-reference implementation.
> There was not enough optimization that aliasing was not an issue.

> The Fortran IV for IBM/360 had copy-in/copy-out for scalars so
> aliasing became an issue and as there started to be some
> optimization with intermediate values in registers across
> statements. The issue of storing into literals was/is an
> ongoing issue.

OK, I used the OS/360 compilers for many years, and this was
well documented.

But Fortran IV goes back at least to the 7090, and also the 7090
was used for much of the development of OS/360. I wouldn't have
been surprised if the 7090 compilers also did it.

For S/360, it takes one extra instruction for each indirect
load/store needed for call by reference. With a local copy, you
save that instruction, but need two or three for each copy.

I don't know 7090 addressing enough to say about that one.

-- glen

[Ian Chivers]

Nag detects the error.

c:\document\fortran\third_edition\examples>nagfor -C=all dusty.f90 -o
nagdusty.e
NAG Fortran Compiler Release 6.0(Hibiya) Build 1028
[NAG Fortran Compiler normal termination]

c:\document\fortran\third_edition\examples>nagdusty.exe
bar before dusty 5
Runtime Error: dusty.f90, line 23: Dummy argument N is associated with
an expres
Program terminated by fatal error

c:\document\fortran\third_edition\examples>

[Gordon Sande]

On 2015-02-07 07:49:05 +0000, glen herrmannsfeldt said:

> Gordon Sande <Gordon...@gmail.com> wrote:
>
> (snip)
>
>>>> They were also worried about aliasing issues as it was developed
>>>> about the time when the first non call-by-reference Fortran
>>>> compilers showed up.
>
>>> Which compilers were those? As far as I know, it goes pretty
>>> far back.
>
>> The original Fortran II was a call-by-reference implementation.
>> There was not enough optimization that aliasing was not an issue.
>
>> The Fortran IV for IBM/360 had copy-in/copy-out for scalars so
>> aliasing became an issue and as there started to be some
>> optimization with intermediate values in registers across
>> statements. The issue of storing into literals was/is an
>> ongoing issue.
>
> OK, I used the OS/360 compilers for many years, and this was
> well documented.
>
> But Fortran IV goes back at least to the 7090, and also the 7090
> was used for much of the development of OS/360. I wouldn't have
> been surprised if the 7090 compilers also did it.

If I have it right Fortran IV showed up on IBSYS and was a purely
call-by-reference just like Fortran II under FAP. The Fortran IV
for IBM/360 had the copy-in/copy-out which made aliasing an issue
whcich became an even bigger issue with heavier optimization that
was developed.

There was a /360 emulator for IBSYS on the 7090 that would have
been used at IBM. One would expect that there were even cross
assemblers to do the bootstrapping onto the new architechure.

> For S/360, it takes one extra instruction for each indirect
> load/store needed for call by reference. With a local copy, you
> save that instruction, but need two or three for each copy.
>
> I don't know 7090 addressing enough to say about that one.

IBM 7090s had indirection. One of the things that got lost in
moving to the shorter word (32 instead of 36 bits) was indirection.
It was not an issue in the Fortran object code as a subroutine
typically had a prefix which took the addresses from the call
and plugged them into the code. Memory protection made that a
problem on the newere hardware. Self modifying code has all
sorts of other issues but was an effective implementation strategy
on that machine at that time.

> -- glen

[glen herrmannsfeldt]

Gordon Sande <Gordon...@gmail.com> wrote:

(snip, I wrote)

>> OK, I used the OS/360 compilers for many years, and this was
>> well documented.

>> But Fortran IV goes back at least to the 7090, and also the 7090
>> was used for much of the development of OS/360. I wouldn't have
>> been surprised if the 7090 compilers also did it.

> If I have it right Fortran IV showed up on IBSYS and was a purely
> call-by-reference just like Fortran II under FAP. The Fortran IV
> for IBM/360 had the copy-in/copy-out which made aliasing an issue
> whcich became an even bigger issue with heavier optimization that
> was developed.

I don't know if it was there in the beginning, but when I knew it,
you could put the dummy argument in slashes, and get real call by
reference.

> There was a /360 emulator for IBSYS on the 7090 that would have
> been used at IBM. One would expect that there were even cross
> assemblers to do the bootstrapping onto the new architechure.

There are a few descriptions of the process of generating OS/360,
and that sounds about right.

>> For S/360, it takes one extra instruction for each indirect
>> load/store needed for call by reference. With a local copy, you
>> save that instruction, but need two or three for each copy.

>> I don't know 7090 addressing enough to say about that one.

> IBM 7090s had indirection. One of the things that got lost in
> moving to the shorter word (32 instead of 36 bits) was indirection.

I know the PDP-10 instruction set better thana the 7090, and
that is also 36 bits. For the PDP-10, if the indirect bit in
an instruction is set, it loads that word from memory. It then
looks at the indirect bit in that word, and if set, loads the
addressed word. There is a timer to stop infinite recursion.

Seems to me that simplifying the instruction set by removing
indirection was the beginning of the move to RISC.

Otherwise, it takes an extra L (load) instruction for each
indirect reference. Local scalars are addressed by the program
base register(s).

> It was not an issue in the Fortran object code as a subroutine
> typically had a prefix which took the addresses from the call
> and plugged them into the code. Memory protection made that a
> problem on the newere hardware. Self modifying code has all
> sorts of other issues but was an effective implementation strategy
> on that machine at that time.

The OS/360 Fortran library has self modifying code. The compiler
generated code doesn't, as far as I know, but data and code are
pretty close together.

-- glen

[William Clodius]

Gordon Sande <Gordon...@gmail.com> wrote:

> <snip>

>
> The original Fortran II was a call-by-reference implementation. There was
> not enough optimization that aliasing was not an issue. The Fortran IV for
> IBM/360 had copy-in/copy-out for scalars so aliasing became an issue and
> as there started to be some optimization with intermediate values in
> registers across statements. The issue of storing into literals was/is an
> ongoing issue.
>
> As a worst case static analyser PFORT could be a real beast in all the
> problems it pointed at.

That strikes me as odd. While Fortran II was from before my time, they
were frequently discussed of comp.compilers and Backus's artile,
Wexelblat's "History of Programming, Languages." In both IBM's Fortran
II (at least on the 7090) had a reputation of having more optimization
than Fortran IV, though Fortran IV had fewer system specific features.
People used to comment on usenet that they would do most development in
Fortran IV, but then tweek the code for Fortran II to get the betteer
runtime.

[Gordon Sande]

The impression I picked up over time was that FII did quite well on the
calculation of subscripts and path dependent optimizations (recall it had
the FREQUENCY statement). The serious FIV optimization was with Fort H on
the 360 and not the IBSYS FIV on 7090.

[glen herrmannsfeldt]

Gordon Sande <Gordon...@gmail.com> wrote:
> On 2015-02-07 21:45:23 +0000, William Clodius said:

>> Gordon Sande <Gordon...@gmail.com> wrote:

<snip>
>>> The original Fortran II was a call-by-reference implementation.

(snip)

>>> As a worst case static analyser PFORT could be a real beast in all the
>>> problems it pointed at.

>> That strikes me as odd. While Fortran II was from before my time, they
>> were frequently discussed of comp.compilers and Backus's artile,
>> Wexelblat's "History of Programming, Languages." In both IBM's Fortran
>> II (at least on the 7090) had a reputation of having more optimization
>> than Fortran IV, though Fortran IV had fewer system specific features.
>> People used to comment on usenet that they would do most development in
>> Fortran IV, but then tweek the code for Fortran II to get the betteer
>> runtime.

Stories of the first Fortran compiler seem to say that it was very
good at optimizing. At least enough to surprise its writers.
It was believed at the time that it had to be good or people wouldn't
use it. I don't know how much of that was still true for Fortran II.

The 704, 709, and 7090 aren't all that different. Adding the features
of Fortran IV may have reduced the optimization, at least in the
early versions.

> The impression I picked up over time was that FII did quite well on the
> calculation of subscripts and path dependent optimizations (recall it had
> the FREQUENCY statement). The serious FIV optimization was with Fort H on
> the 360 and not the IBSYS FIV on 7090.

Yes. Again, Fortran H did enough optimization to surprise those
who worked on it. But it was designed to do that in 256K core,
and that is with overlays. Fortran G was designed for 128K, and
did that without any overlays.

-- glen

[John Harper]

Thomas Koenig wrote:

> john.c...@simconglobal.com <john.c...@simconglobal.com> schrieb:

>
>> A developer who calls a routine looks at an argument, sees that
>> it is declared INTENT(IN) and programs accordingly. This causes
>> errors.
>

> You mean something like
>
> module foo
> implicit none
> contains
> subroutine bar(n)
> integer, intent(in) :: n
> print *,"bar before dusty", n
> call dusty(n)
> print *,"bar after dusty", n
> end subroutine bar
> end module foo
>
> program main
> use foo
> implicit none
> integer :: n
> n = 5
> call bar(n)
> end program main
>
> subroutine dusty(n)
> integer n

> n = n - 1
> end
>

> ?
>
> I agree that it would be nice to have a compiler check for that.

> Does any compiler do that?

G95 does not do it by default but g95 -Wextra gives 2 compile-time warnings
with that program, one about the implicit interface of dusty and one that
its actual argument has no intent. Unfortunately g95 -Werror -Wextra which
turns warnings into errors stops compiling after the first one.

[John Harper]

G95 and gfortran both complained about that program if and only if I
specified -std=f95. So did ifort -stand f95 . All 3 compilers did what the
f95 standard requires.

[Ian Harvey]

On 2015-02-10 9:49 AM, John Harper wrote:
> Ian Harvey wrote:
...

The above is a Fortran 2003 (or F2008) program - the diagnostics are
likely just noting use of features introduced with Fortran 2003 as
extensions. I would be surprised if they are identifying the problem
that is the subject of this thread.

I think this variant demonstrates the same issue under Fortran 95:

PROGRAM p95
IMPLICIT NONE
TYPE t
INTEGER, POINTER :: ptr
END TYPE t

CALL execute
CONTAINS
SUBROUTINE execute
INTEGER :: variable
variable = 2
PRINT "('Before variable was ',I0)", variable
CALL sub(variable)
PRINT "('After variable was ',I0)", variable
END SUBROUTINE execute
SUBROUTINE sub(arg)
INTEGER, INTENT(IN), TARGET :: arg

TYPE(t) :: dt
dt%ptr => arg
CALL xyz(dt)
END SUBROUTINE sub
SUBROUTINE xyz(dt)
TYPE(t), INTENT(IN) :: dt
dt%ptr = 3
END SUBROUTINE xyz
END PROGRAM p95

I would expect some sort of static analysis or runtime testing would be
required to identify the issue. Such analysis and testing is likely
just as applicable to cases where no intent is specified for the
relevant arguments in called procedures or where procedure interfaces
are implicit.

But appropriate static analysis and runtime testing tools and compilers
are practically available, so the prospect of this error going
undiagnosed doesn't particularly bother me, relative to other
programming errors that may be made.

[James Van Buskirk]

"Nick Maclaren" wrote in message news:mal35b$mpr$1...@needham.csi.cam.ac.uk...

> In article <45665aab-3525-4263...@googlegroups.com>,
> <john.c...@simconglobal.com> wrote:
> >Does anyone know of any compilers which use INTENT declarations to guide
> >co
> >de generation?

> No, but all will, under some circumstances. The first one I
> thought of is:

> Passing an assumed-shape array or array section to an
> explicit-size or assumed-size argument, where it needs to
> it but MUST NOT copy back.

Ok, I underestimated the significance of what you said above. Afer
reviewing the thread, will test further downthread.

[James Van Buskirk]

"Nick Maclaren" wrote in message news:manka0$2n3$1...@needham.csi.cam.ac.uk...

> Yes. There was a question in WG5/J3 about passing a (hardware)
> read-only assumed-shape array from C to Fortran, and it was
> agreed (with dissenters) that it is not allowed, because of the
> problem of (a) dropping the INTENT(IN) and (b) then passing it
> as explicit-size or assumed-size.

Do you mean explicit-shape above? It’s easy enough to morph an
explicit-shape array into an object that is not simply contiguous,
after all.

> HOWEVER, once you start using parallel programming and specialist
> I/O, there are objects that are fundamentally read-only, and the
> only solution is to ensure that does not happen. That issue is
> one of the reasons that poorly engineering applications have so
> much trouble with those facilities.

> That is why I say that any correct compiler should generate the
> copy back only if neither the actual argument nor the interface
> dummy argument have INTENT(IN). My previous posting was actually
> incorrect, for the reasons you (and others) give - in order to
> get INTENT to work properly, all interfaces must be explicit.
> But that's easy to do by writing a script to create a module
> with all external procedure interfaces in it, and to include
> that everywhere it is used.

On reviewing this thread and section 12.5.2, this seems to me to be
a real problem. There are so many ways an array (or a character
variable which can be morphed into an array) can end up in read-
only memory. A C global variable with the const attribute may be
placed in read-only memory, for example. Also the Fortran
processor might want to place non-definable things like arrays or
character variables with the PARAMETER attribute or expression
actual arguments or dummy variables with both INTENT(IN) and
VALUE attributes in read-only memory, or for that matter create read-
only page aliases for INTENT(IN) dummy arguments, but if the standard
doesn’t shut the door on this copy-in/copy-out possibility then it’s
not allowed to do so. Is something like:

10 If the dummy argument is an explicit-shape array, an assumed-shape
array with the CONTIGUOUS attribute, or an assumed-size array, and the
effective argument is not simply contiguous and is not an array section
with a vector subscript then the effective argument shall be definable
and if both the dummy argument and effective argument have the TARGET
attribute

o on invocation of the procedure, whether any pointers associated with
the effective argument become associated with the corresponding dummy
argument is processor dependent, and
o when execution of the procedure completes, the pointer association
status of any pointer that is pointer associated with the dummy
argument is processor dependent.

feasible? Is a zero-sized object vacuously definable?

Another thing I noticed in that section was:

7 Except in references to intrinsic inquiry functions, if the dummy
argument is nonoptional and the actual argument is allocatable, the
corresponding actual argument shall be allocated.

Is this modified in subsequent interpretations to take into account
the changes in specification inquiries that now include non-intrinsic
functions?

[James Van Buskirk]

"Ian Harvey" wrote in message news:mb3nh3$bf5$1...@dont-email.me...

> (However, I repeat my view that that the standard should not include any
> suggestion that compilers should not take advantage of INTENT
> specification when generating code. I think the likelihood of this
> (specific) sort of inadvertent violation is small; tools to identify
> these sorts of violations exist, even if they are not used as part of
> the very frequent, short term code-compile-execute loop; and the
> requirements around INTENT(IN) aren't particularly special relative to
> other requirements that programmers may happen to inadvertently violate,
> which we all merrily accept.)

As Nick said earlier, not only is it a good thing that compilers take
advantage of INTENT(IN), at times it is required.

module mod1
implicit none
character(*), parameter :: x = 'This is a constant string.'
end module mod1

module mod2
implicit none
contains
subroutine sub1(x)
character(*) x
call sub2(x,len(x))
end subroutine sub1
subroutine sub2(x,size)
integer size
character x(size)
call sub3(x)
end subroutine sub2
subroutine sub3(x)
character x(:)
!INTENT(IN) :: x
call sub4(x(1::2))
end subroutine sub3
subroutine sub4(x)
!INTENT(IN) :: x
character x(*)
end subroutine sub4
end module mod2

program main
use mod1
use mod2
implicit none
write(*,'(a)') x
call sub1(x)
write(*,'(a)') x
end program main

Both gfortran and ifort throw an error at runtime for the above program
with the INTENT(IN) statements commented out, but ifort runs to
completion if either or both of them are in effect whereas gfortran only
works if the INTENT(IN) statement in subroutine sub4 is in effect.

[Ian Harvey]

With the standard as it is, isn't the "required" aspect just a compiler bug?

[James Van Buskirk]

"Ian Harvey" wrote in message news:mbota6$omt$1...@dont-email.me...

> On 2015-02-14 5:52 PM, James Van Buskirk wrote:

> > As Nick said earlier, not only is it a good thing that compilers take
> > advantage of INTENT(IN), at times it is required.

[snip example]

> > Both gfortran and ifort throw an error at runtime for the above program
> > with the INTENT(IN) statements commented out, but ifort runs to
> > completion if either or both of them are in effect whereas gfortran only
> > works if the INTENT(IN) statement in subroutine sub4 is in effect.

> With the standard as it is, isn't the "required" aspect just a compiler
> bug?

There are other ways the critical variable can be placed in read-only
memory. The standard doesn’t forbid that for arguments that are not
syntactically definable. But once that happens for an array or character
variable, we can compose a similar example where the Fortran processor
would normally perform a copy-in/copy-out to pass a discontiguous actual
argument to a contiguous dummy with no INTENT, like in Note 5.17.

Given that the Fortran processor doesn’t have any way of knowing whether
the actual argument (if it has no INTENT) lies in read-only memory, the
only way to perform the copy-out is to compare the resulting dummy argument
with the actual argument and not copy anything unless the two are different.
Are QNaNs different from SNaNs? Do differences in bits that don’t affect
the value of the variable (as in some implementations of LOGICAL types, or
structures that require padding for alignment) make a difference?

But as the standard is written it seems the Fortran processor has to do
this comparison before it can copy out, which seems absolutely horrible to
me, so it looks more like a bug in the standard because I speculate that
no compilers really do that required comparison.

[Ian Harvey]

On 2015-02-15 4:02 PM, James Van Buskirk wrote:
> "Ian Harvey" wrote in message news:mbota6$omt$1...@dont-email.me...
>
>> On 2015-02-14 5:52 PM, James Van Buskirk wrote:
>
>> > As Nick said earlier, not only is it a good thing that compilers take
>> > advantage of INTENT(IN), at times it is required.
>
> [snip example]
>
>> > Both gfortran and ifort throw an error at runtime for the above program
>> > with the INTENT(IN) statements commented out, but ifort runs to
>> > completion if either or both of them are in effect whereas gfortran
>> only
>> > works if the INTENT(IN) statement in subroutine sub4 is in effect.
>
>> With the standard as it is, isn't the "required" aspect just a
>> compiler bug?
>
> There are other ways the critical variable can be placed in read-only
> memory. The standard doesn’t forbid that for arguments that are not
> syntactically definable. But once that happens for an array or character
> variable, we can compose a similar example where the Fortran processor
> would normally perform a copy-in/copy-out to pass a discontiguous actual
> argument to a contiguous dummy with no INTENT, like in Note 5.17.
>
> Given that the Fortran processor doesn’t have any way of knowing whether

> the actual argument (if it has no INTENT) lies in read-only memory...

If the code is conforming and the standard provides an interpretation
for that conforming code, then the processor is constrained by the
standard (subject to the size/complexity escape clause) in terms of the
behaviour it must exhibit.

One consequence of that may well be that the Fortran processor and its
companion C processor can no longer put things in read only memory and
then work directly with them.

(If a user runs around behind the Fortran/C processors back and plays
tricks, then that's the user's problem.)

But a Fortran processor implemented on the operating systems that are
prevalent today does have a way of knowing whether the storage for the
data of an actual argument lies in read only memory - consider the
capabilities offered by VirtualQuery on Windows or /proc/nnn/map on linux.

The Fortran processor could also arrange to make a copy of a thing that
is in read only memory, and subsequently work with that copy, when it
sees that thing being passed out of the domain of the restrictions
associated with INTENT(IN) and the like.

Because those processors have chosen to use read only memory for a
standard Fortran thing (a named constant), and given the code appears to
be conforming and an interpretation is established, I think all you are
showing with that aspect is a compiler bug.

But I agree that you are also also showing that INTENT(IN) changes the
code that is generated, in a significant way - which is what the OP was
asking about.

[glen herrmannsfeldt]

James Van Buskirk <not_...@comcast.net> wrote:
> "Ian Harvey" wrote in message news:mbota6$omt$1...@dont-email.me...
>
>> On 2015-02-14 5:52 PM, James Van Buskirk wrote:

(snip)

>> > Both gfortran and ifort throw an error at runtime for the
>> > above program with the INTENT(IN) statements commented out,

(snip)

>> With the standard as it is, isn't the "required" aspect just a compiler
>> bug?

> There are other ways the critical variable can be placed in read-only

> memory. The standard doesn???t forbid that for arguments that are not

> syntactically definable. But once that happens for an array or character
> variable, we can compose a similar example where the Fortran processor
> would normally perform a copy-in/copy-out to pass a discontiguous actual
> argument to a contiguous dummy with no INTENT, like in Note 5.17.

Seems to me that there are some cases where the compiler doesn't
know if the copy is required.

But I always thought that the standard allowed for the copy,
even when it wasn't required.

> Given that the Fortran processor doesn???t have any way of knowing whether

> the actual argument (if it has no INTENT) lies in read-only memory, the
> only way to perform the copy-out is to compare the resulting dummy argument
> with the actual argument and not copy anything unless the two are different.

> Are QNaNs different from SNaNs? Do differences in bits that don???t affect

> the value of the variable (as in some implementations of LOGICAL types, or
> structures that require padding for alignment) make a difference?

Well, OK, but hopefully all the padding stays the same.

> But as the standard is written it seems the Fortran processor has to do
> this comparison before it can copy out, which seems absolutely horrible to
> me, so it looks more like a bug in the standard because I speculate that
> no compilers really do that required comparison.

Well, as above, compilers should be sure that the copy is required
before doing it. That is less work (usually) than verifying that
the data hasn't changed.

But in cases where the copy is required, yes, it seems like a
mistake to me. Or disallow keeping it in read-only memory.

-- glen

[glen herrmannsfeldt]

Ian Harvey <ian_h...@bigpond.com> wrote:

(snip)

> On 2015-02-15 4:02 PM, James Van Buskirk wrote:

>> Given that the Fortran processor doesn???t have any way of knowing whether

>> the actual argument (if it has no INTENT) lies in read-only memory...

> If the code is conforming and the standard provides an interpretation
> for that conforming code, then the processor is constrained by the
> standard (subject to the size/complexity escape clause) in terms of the
> behaviour it must exhibit.

PL/I from the beginning required a modifiable copy for expressions
and constants passed to subroutines. That was when a not so unusual
bug in Fortran programs was modifying a constant. (For one,
compilers might have been better at keeping only one copy.)

> One consequence of that may well be that the Fortran processor and its
> companion C processor can no longer put things in read only memory and
> then work directly with them.

Does anyone know recent cases (on systems that don't put constants
in read-only memory) of an actual bug (not just a test case)
where a constant was modified?

(If a user runs around behind the Fortran/C processors back and plays
> tricks, then that's the user's problem.)

> But a Fortran processor implemented on the operating systems that are
> prevalent today does have a way of knowing whether the storage for the
> data of an actual argument lies in read only memory - consider the
> capabilities offered by VirtualQuery on Windows or /proc/nnn/map on linux.

> The Fortran processor could also arrange to make a copy of a thing that
> is in read only memory, and subsequently work with that copy, when it
> sees that thing being passed out of the domain of the restrictions
> associated with INTENT(IN) and the like.

Seems to me that is a good choice.

> Because those processors have chosen to use read only memory for a
> standard Fortran thing (a named constant), and given the code appears to
> be conforming and an interpretation is established, I think all you are
> showing with that aspect is a compiler bug.

> But I agree that you are also also showing that INTENT(IN) changes the
> code that is generated, in a significant way - which is what the OP was
> asking about.

-- glen

[James Van Buskirk]

"Ian Harvey" wrote in message news:mbpcpa$r5s$1...@dont-email.me...

> One consequence of that may well be that the Fortran processor and its
> companion C processor can no longer put things in read only memory and
> then work directly with them.

I have been bitten by the bug where a named constant was overwritten.
I can’t remember all the details, but I do recall that it was a
relatively difficult bug to exterminate because the error didn’t all
happen in one place, it was the interaction between separately
correct components of the program that caused the problem. Had the
named constant been placed in read-only memory the point of failure
would have reduced the debugging effort almost to a no-op. Oh yeah,
I think there was an ELEMENTAL procedure involved where I couldn’t
put any WRITE statements and the debugger had a bug where it just
didn’t work in ELEMENTAL procedures and the procedure was indeed
invoked elementally, so that the code had to be restructured to find
the bug.

Also C seems to be used for low-level stuff so that it simply has to
be able to touch read-only memory directly.

> But a Fortran processor implemented on the operating systems that are
> prevalent today does have a way of knowing whether the storage for the
> data of an actual argument lies in read only memory - consider the
> capabilities offered by VirtualQuery on Windows or /proc/nnn/map on linux.

That might be a possibility, but I don’t know that you could get
vendors to follow along, especially since it could impair performance
in innocent cases. If users wanted to get their performance back they
could invoke a wrapper procedure with an INTENT(IN) assumed-shape
dummy that called the procedure with the no-INTENT contiguous dummy.
They didn’t storm the committee’s castle with pitchforks and firebrands
when VALUE \CUP OPTIONAL went through though, so maybe they would
follow along with this.

> The Fortran processor could also arrange to make a copy of a thing that is
> in read only memory, and subsequently work with that copy, when it sees
> that thing being passed out of the domain of the restrictions associated
> with INTENT(IN) and the like.

And the like including TARGET and VOLATILE, I suppose?

> Because those processors have chosen to use read only memory for a
> standard Fortran thing (a named constant), and given the code appears to
> be conforming and an interpretation is established, I think all you are
> showing with that aspect is a compiler bug.

> But I agree that you are also also showing that INTENT(IN) changes the
> code that is generated, in a significant way - which is what the OP was
> asking about.

Or should so change the code. At least I agree that not avoiding the
copy-out when the actual argument was INTENT(IN) and the dummy argument
had no INTENT (or perhaps had an implicit interface) is a bug in
gfortran.

[robert....@oracle.com]

On Saturday, February 14, 2015 at 9:02:52 PM UTC-8, James Van Buskirk wrote:

> Given that the Fortran processor doesn't have any way of knowing whether
> the actual argument (if it has no INTENT) lies in read-only memory, the
> only way to perform the copy-out is to compare the resulting dummy argument
> with the actual argument and not copy anything unless the two are different.
> Are QNaNs different from SNaNs? Do differences in bits that don't affect
> the value of the variable (as in some implementations of LOGICAL types, or
> structures that require padding for alignment) make a difference?
>
> But as the standard is written it seems the Fortran processor has to do
> this comparison before it can copy out, which seems absolutely horrible to
> me, so it looks more like a bug in the standard because I speculate that
> no compilers really do that required comparison.

Why does it seem horrible? Oracle Solaris Studio Fortran uses this implementation.

Bob Corbett

[glen herrmannsfeldt]

How about if it is a reeealy big array, and the routine is called
many times?

But okay, the copy also takes a lot of time, maybe about the same
amount as the compare. You can stop comparing when you find a
difference, so most of the time it comes about about the same.

-- glen

[James Van Buskirk]

"glen herrmannsfeldt" wrote in message
news:mbvfhr$krs$1...@speranza.aioe.org...

> But okay, the copy also takes a lot of time, maybe about the same
> amount as the compare. You can stop comparing when you find a
> difference, so most of the time it comes about about the same.

No. The standard allows for partially definable objects. See Notes
12.34 & 12.35.

[robert....@oracle.com]

Right. The original implementation did the compare for all elements and did the store out if the values were different. That ran slower than the simple copy out in cases where many elements were copied. The latest version does compares until a difference is found, and then does a simple copy out for the rest of the array. The new version tends to be about as fast or faster than the simple copy out.

Robert Corbett

[robert....@oracle.com]

On Tuesday, February 17, 2015 at 1:47:11 PM UTC-8, James Van Buskirk wrote:
> "glen herrmannsfeldt" wrote

>
> > But okay, the copy also takes a lot of time, maybe about the same
> > amount as the compare. You can stop comparing when you find a
> > difference, so most of the time it comes about about the same.
>
> No. The standard allows for partially definable objects. See Notes
> 12.34 & 12.35.

What difference does that make? The issue here is that a constant has been placed in read-only storage and then passed as an actual argument. A later call might cause the argument to be copied in and later copied out. If none of the values have changed, the value need not be copied out.

Robert Corbett

[Ron Shepard]

On 2/14/15 11:02 PM, James Van Buskirk wrote:

> Given that the Fortran processor doesn’t have any way of knowing whether
> the actual argument (if it has no INTENT) lies in read-only memory,

This seems to be an incorrect assumption. I guess there might be several
ways to define read-only memory, but however it is done, it should be
possible to test to see if a particular argument's address is in that
range or has that flag.

> the
> only way to perform the copy-out is to compare the resulting dummy argument
> with the actual argument and not copy anything unless the two are
> different.

It seems to me like a processor should always copy-out argument values
as long as it thinks they can change. The exceptions would then be when
the actual argument is in read-only memory, when it is an expression or
a parameter or is PROTECTED, or when INTENT(IN) is declared for the
dummy argument. I guess there could be other situations too, but those
are the ones that come to mind. In all cases, the calling program knows
those things, so the processor should know what to do.

If something is supposed to be unchanged, and through the sequence of
subroutine calls the processor can't tell, then it seems like it should
copy-out back up to the point where it can tell. If the program changed
something that was not supposed to change, then that is a programmer
error. Of course, we want the compiler to help find those cases, but it
isn't the compiler's fault if it can't, it is still a programmer error.

$.02 -Ron Shepard

[glen herrmannsfeldt]

James Van Buskirk <not_...@comcast.net> wrote:

I am not sure which distinction you are making. Partially defined
or not, the value shouldn't change if the program doesn't change it.

Now, some processors might not be able to properly compare the
values, but the implementor should know that. It might be that
some systems allow for parity errors in partially defined objects,
or some other reason the compare could fail. But if the implementation
knows that can't happen, it should be able to do the compare.

Now, more interesting is that the value might have NaN, and NaN
always compares not equal. Should one consider that?

-- glen

[robert....@oracle.com]

On Tuesday, February 17, 2015 at 6:05:03 PM UTC-8, glen herrmannsfeldt wrote:

> Now, more interesting is that the value might have NaN, and NaN
> always compares not equal. Should one consider that?

Oracle Solaris Studio Fortran uses integer comparisons to see if values have changed, even if the program considers the values to be floating-point values.

Robert Corbett

[glen herrmannsfeldt]

I figured that, but in the sense of the standard you don't know.

You know that the hardware you use can do that. There might be
hardware that can't.

-- glen

[Richard Maine]

glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:

> robert....@oracle.com wrote:
> > On Tuesday, February 17, 2015 at 6:05:03 PM UTC-8, glen herrmannsfeldt
wrote:
>
> >> Now, more interesting is that the value might have NaN, and NaN
> >> always compares not equal. Should one consider that?
>
> > Oracle Solaris Studio Fortran uses integer comparisons to see
> > if values have changed, even if the program considers the values
> > to be floating-point values.
>
> I figured that, but in the sense of the standard you don't know.

Well, the sense of the standard is that all of this is up to the
particular implementation. Also that you don't really need to know. If
you need to know that sort of implementation detail, other than perhaps
to evaluate performance issues, then your code isn't standard
conforming.

I'm not sure what the point here is. That it is possible for
implementations to be done incorrectly? Well, yes, but that seems pretty
high on the scale of obviousness. More interesting to me would be that
it is possible for implementations to be both correct and reasonably
efficient. That's perhaps not quite so obvious, but I take Robert's
posts as saying that it is so.

--
Richard Maine
email: last name at domain . net
domain: summer-triangle

[James Van Buskirk]

wrote in message
news:9ec9d93d-ea9b-4ca6...@googlegroups.com...

Suppose we wanted to solve a 2-d boundary value problem on a rectangular
grid with Dirichlet boundary conditions on two opposite sides. We want
the boundary points to be undefinable because they are part of the
statement of the problem, but it’s convenient for them to be part of the
grid array as well. What to do?

Well, we can round the column length of the array up to the next integer
multiple of a page and then allocate enough memory for the expanded
array + 1 page – 1 element, then get a pointer to the first page
boundary in that memory and then with C_F_POINTER we can point to the
desired array. Now we can write the boundary values into the first and
last columns and then request the OS to mark the pages containing those
columns as READONLY. Then we pass an array section to an assumed-shape
dummy argument with only the part of the array that corresponds to the
actual problem.

So the situation is much as outlined in Notes 12.34 & 12.35 in that the
called procedure has an array with parts definable and parts not, so
only the intelligence composing the program knows which parts not to
write.

Now what happens when this assumed-shape array gets passed to a dummy
argument that must be contiguous? The called procedure is written so
that the first and last columns don’t get defined, but on return, the
Fortran processor is supposed to perform a copy-out (or not). All
goes smoothly on copying the first column because checks show that
none of its elements have been changed so none of its READONLY memory
gets written to. But somewhere in the middle, a change is detected,
so the processor switches to blindly copying without further checking.
When the last column is reached an exception is raised.

It seems to me that any random collection of pages could be marked
READONLY, so the Fortran processor would in principle have to
restart the checks on every page.