Please don't send me copies of comp-fortran-90 postings. Thanks.
Friedrich Hertweck said:
>Are you saying that a compiler is NOT required to diagnose the violation of
>a rule? I must say that I have difficulties understanding Sec. 1.5 (Conformance).
>My naive assumption is that all rule violations should be diagnosed.
>Maybe I am wrong here.
You are indeed wrong.
Section 1.5 does not require all rule violations to be diagnosed, only
to diagnose a
"form or relationship that is not permitted by the numbered syntax
rules or their associated constraints"
(it goes on to list further things that must be diagnosed).
So a requirement on the program that is not described by a syntax rule or a
constraint, and is not one of the other things listed that require a
diagnosis (e.g. kind type parameter values), need not be diagnosed.
I note in passing that diagnosing some of the rules would be an intolerable
burden in production programs, as the overhead would be immense.
[I said]
>> i.e. no matter with how much trickery you hide the fact from the compiler,
>> you just are not allowed to alter the value of INTENT(IN) dummy arguments
>> during that procedure's execution. But the compiler need not complain - it
>> can start WW3 instead.
[F.H. asked]
>What is WW3?
World War 3.
Equally, it could delete your files, reformat your disc, display the complete
works of Shakespeare, give a segmentation fault, ... or produce something
that looks like the answer which you are expecting.
The fact is that once a program is not "standard-conforming" (i.e. it has
violated the rules laid down by the standard), it is not "Fortran" (as far
as the standard is concerned) and the standard does not (and cannot) say
anything about programs that are not Fortran.
[...]
>At least three compilers do NOT accept indexed array sections
>(among them also NAG F95):
Oh, you are talking about vector-subscripted array sections (as they are
called). I agree with you on that point then!
However, you don't need vector subscripts to force copy-in/copy-out argument
passing - ordinary array sections can do it when the dummy argument is not
assumed-shape, so you are still in trouble.
>> >So I maintain my position that a good compiler should be able to check on
>> >these things.
>>
>> This would certainly be nice; I don't know of any that do as yet - we've
>> added quite a few inter-procedural checks recently but we don't yet spot
>> these particular problems with pointers.
>>
>> The problem here is that the standard wording is vague: the facility is
>> >supposed to be PROCESSOR DEPENDENT, so the user must check it.
>>
>> Hmm, I think that the problems here are such that a user is not meant to
>> use it.
>
>While you (Malcolm Cohen) argue from the standpoint of compiler vendors,
>I try to argue from the standpoint of the user:
Actually I am writing with my "standards" and "portability" and "user" hats
on at least as much as with my "compiler vendor" hat on.
In particular, when it comes to what the standard says, I am arguing from
the standpoint of the standard.
> is it legitimate to ask for
>a data structure to be viewed in different ways? I believe it is.
The Fortran standard does not agree with you here.
It specifies a small number of ways of getting "different views" of a
data structure (mostly EQUIVALENCE), and your program is not using any of
them.
Indeed, since it does not satisfy the rules the standard requires it to
satisfy, it is fair to say that it is not "Fortran".
[...]
>> The processor dependency is not necessarily checkable (it may
>> vary unpredictably - the user cannot rely on a check in one instance
>> meaning that it will work in future calls).
>
>This now is an issue of product stability. If you have a (supposedly well
>documented) feature in a compiler that is declared ba the standard as
>"processor dependent", a user might well use it and invest quite a bit of
>programming effort. It will be hard for him if the manufacture just takes it away.
>
>(Was that not a reason to have all of F77 in F90?)
You don't seem to have understood my point, which is that some of these
things can conceivably vary during execution. Considering things like
distributed-memory architectures, automatic garbage collection and storage
reclamation, it is certainly not beyond the realms of possibility that
the processor-dependency (of pointer-association through arguments) could
vary from one CALL to another within a single execution of a single program.
E.g. with a message-passing architecture, it could be passing global array
(arrays that happen to be stored globally) by reference and local arrays by
copy-in/copy-out. Or a vector architecture could pass big arrays by reference
and small arrays in the vector registers.
>> With a sufficiently checking compiler, your program would cease to work
>> because of the undefined pointer.
>
>True.
>But because I argue goal-oriented I would like to have a more modern
>facility that would resolve Van Snyders problem.
I think Van is best placed for solving his own problems actually...
...but we have certainly left the realm of current day Fortran here.
(Besides which I have at least one idea - as a user - of how this kind of
problem can be solved portably and reliably within the current standard,
so I'm not 100% convinced that one needs to extend the current standard.
...if we are goal-oriented we should be talking about how to safely,
portably and efficiently solve the application problem, which is not
about establishing impossible aliases but which is about processing data.
>Technically, there
>are no diffculties:
>In this particular case what happens with pointer assignment is obvious;
>for this reason all systems behave alike, and also reasonably. (The address
>of the data object and its shape are placed into the pointer data structure
>and returned by the function. You can easily check that when you print
>the contents of the pointer data structure. Yes, you can do it in Fortran.)
>That is what MUST happen as long as the pointer inside the function is valid;
>the problem only arises when the procedure terminates: the STATUS
>of the pointer becomes undefined, but the information is still there.
The information may be garbage, particularly in the case of parallel execution.
An undefined pointer does not have reliable information in it that you can
use to any good effect.
>> With a sufficiently optimising compiler, your program would give the
>> result you expect but more complicated "real" programs would give
>> results you would not expect because of the unexpected (and invalid)
>> aliasing you have set up.
>
>I fail to see what this has to do with optimization:
Tnings like registers (including vector registers), copy-in/copy-out argument
passing (very prevalent on massively parallel systems), etc. can totally
wreck your results, because you have LIED to the compiler.
You have given the compiler a guarantee that two entities are not aliased,
when in fact they are.
>I would require from
>an optimizing compiler NEVER to change the semantics of a program
Your program ***HAS NO SEMANTICS***. It is not "Fortran".
The standard gives no meaning to your program, because your program
does not obey its *REQUIREMENTS*. [Cue WW3 analogy - the compiler, whether
optimising or not, can do anything it pleases with such a program].
>What I am willing to accept is that a compiler with more thorough analyzing
>would issue a WARNING that the pointer returned by the function has undefined
>status.
No, it would likely terminate your program with extreme prejudice once it
has spotted the undefined pointer.
There is nothing really different between this and an array subscripting
error - both do lead to completely undefined behaviour, can lead to weird
results when no checking is being done, and should terminate the program
if checking is being done.
>Another way would be to have an additional intrinsic pointer procedure
>(permitted by the standard) like:
> RESTRUCTURE(arr,shape)
>where arr is an array of any rank (with the target attribute), and shape a
>rank-1 array with the shape of the result. With p defined as an array with
>the pointer attribute, say: <type of x1>, pointer :: p(:,:), the statement
> p => RESTRUCTURE(x1, (/ n1, n2 /))
>would do what is required, provided SUM(shape)==SIZE(arr).
>It would be in the interest of the users if vendors could agree on that.
I am not totally unsympathetic to this idea, though it does have some
potential problems. (In particular, it cannot be applied universally because
that would mean that computing machine addresses from subscripts would no
longer be a simple linear transformation of the subscript values).
Also, I think it would work much better as a new statement than as an
intrinsic function. Putting these things into the middle of expressions
seems to me to be just asking for trouble.
*****************
However, there is user demand for lots of things, both to the standards
bodies and to the vendors. As I mentioned before, I am unconvinced that
the language is so deficient in this particular area that urgent action
needs to be taken. There seems to be a lot of "more important" things
to be added (both to compilers and to the standard).
>> My summary: just don't do this folks. It's too complicated, you'll
>> probably shoot yourselves in the foot.
>
>I do not agree that it is too complicated, in my opinion it is very simple
>and straightforward.
If you think it is simple then perhaps you do not understand it fully.
I have tried to explain a few of the complications above, but there are
certainly lots more.
>Instead of "shooting ourselves in the foot" we need
>another solution than going back to Fortran 77 or (forward?) to C
How does going back to Fortran 77 help you? Not at all! You can still do
Fortran 77 stuff in Fortran 90/95! (I don't know of any vendor who does not
include all of F77, even though F95 omits a few obscure F77 features).
>(where these things are done all the time - but on a lower level because
>you actually can use addresses of object directly).
No, Fortran 77 does not let you use addresses of objects directly.
You must be thinking of a different language.
And I completely disagree with the thrust of your sentiments: using addresses
of objects directly
(1) inhibits optimisation [there is a good reason that much of Fortran is
more efficient than the equivalent C!]
and
(2) promotes poor programming practices, leading to poor maintainability and
hideous lurking bugs [buffer overrun exploits anyone?]
Cheers,
--
...........................Malcolm Cohen, NAG Ltd., Oxford, U.K.
([log in to unmask])
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
