This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch/fortran] Add documentation section about implemented F2003 features
On Aug 2, 2005, at 11:43 PM, Janne Blomqvist wrote:
F95 automagically deallocates non-saved allocatables when
they go out of scope. In F90 it is the responsibility of the
programmer to remember the deallocate.
That doesn't mean that an f90 compiler won't do the deallocation; that
just means that the standard doesn't specify it.
Practically speaking, I guess the usual
implementation of F90 allocatables would imply leaking the memory and
continuing happily,
No. I disagree - vehemently. You miss my main point. The usual
implementation of f90 allocatables today is identical to that of f95
allocatables. Although the f90 standard doesn't require it, the f95
working is a valid implementation of the f90 standard. I'm quite
confident that it is the most common implementation today, since most
compilers today are f95 ones. There *IS* no other canonical f90
implementation that is normally expected by f90 users.
Even before f95, my experience was that the usual implementation was to
give an error if you tried to do anything subsequently with the
variable. I personally observed this happening with at least some
implementations. I could imagine the possibility of implementations
that effectively treated allocatables as saved, though I don't recall
for sure whether any worked that way. I somewhat doubt that there were
ever *ANY* implementations that leaked memory in the fashion that you
mention. Such implementation would have been allowed by the standard,
and it is possible that there was one somewhere, but it certainly was
not a "usual" implementation in any sense of the word.
I personally can't see a single reason why an
F90 allocatable in the undefined status would be beneficial.
Me neither. Not have I ever heard of anyone that does.
Say, an inexperienced programmer is ordered by his boss
to write a Fortran program, picks up a Fortran 90 book somewhere,
looks at the gfortran man page and sees that we have a -std=f90
switch, starts programming and at some point forgets to deallocate an
allocatable and later tries to access it again. Well, there we have
WWIII.
I see that I am not communicating my point. I am not asking for
implementation of some different scheme. I am telling you that the
scheme you have right now *IS* a valid f90 implementation. It is the
most common f90 implementation today, and is the preferred one. So what
happens to that programmer is that he gets the f95 scheme and his array
is automatically deallocated. Nothing in the f90 standard actually
requires WWIII. The whole point of "undefined" is that it is up to the
compiler what to do. Compilers today sensibly choose to do the f95
thing.
Recall that just like undefined variable values (way back to f66),
"undefined" is not a testable state. When the standard says that
something is undefined, that never lays a requirement on a compiler.
That translates to "the compiler can do whatever it darn well wants".
Perhaps a better wording would be "undefined by the standard" which is
not at all the same thing as "undefined by the compiler".
So he thinks
that .f90 means the program is F90, looks at the man page and enables
the -std=f90 option. Well, what if the program in fact was F95 and the
programmer hasn't bothered to deallocate as he knows that the compiler
will take care of it (that's what I personally do, for example)? WWIII
again?
Nothing different at all will happen because a std=f90 option won't
affect allocatable treatment in that way. It would make no sense at all
for it to, and I seriously doubt that any compiler anywhere would do
that with a std=f90 option.
Misuse of allocatables like that isn't even one of the things that the
standard mandates diagnosis of, so the std=f90 switch probably has no
effect here at all. If someone really, really wanted to go to special
effort to try to verify 90 compliance even at run-time, then I could
imagine that one *MIGHT* implement it so that you would get an error
message. The only purpose of that would be to help enforce f90
compliance - not to help non-compliant programs run. An error message
is what some pre-f95 compilers did. I don't know that any f95 compilers
tie such a message to a std=f90 switch; I'd guess not, but it is at
least plausible. Seems like extra work for minimal gain. I can imagine
no reason at all why any f95 compiler would even have an option to do
anything other than the standard f95 thing or an error message. That
would be truly odd. Have you *EVER* seen such a thing or are you
speculating?
I don't see a justification
why gfortran should go out of its way to help the user shoot himself
in the foot.
Me neither. This is about the documentation - not about the compiler
workings. I'm just telling you that you are making incorrect
implications in your documentation. The behavior that you have right
now *IS* valid f90 behavior, so I advise against saying or implying
otherwise.
I meant an option -std=f90, which would flag the new F95 features as
illegal,
Yes. Though mostly only the compile-time ones (particularly the ones
that the f90 standard requires diagnosis of). It isn't possible or
expected to flag all the run time ones.
not automatically deallocate non-saved allocatables etc.
No. See above.
I
hope I have explained well enough why I think that the F95
allocatables are a good thing
Agree. Again, I've never known a single person who thought otherwise.
That includes the people who wrote it. It was more of an oversight and
failure to come up with a good alternative. I don't think they thought
this was actively a good idea as much as that they didn't have a good
idea at the time (but later found one).
and that F90 allocatables should not be
supported,
See above. You already do support "f90 allocatables". There is no such
thing as an f90 allocatable that isn't also an f90 allocatable.
--
Richard Maine | Good judgment comes from experience;
Richard.Maine@nasa.gov | experience comes from bad judgment.
| -- Mark Twain