Malcolm Cohen schrieb:
> Friedrich Hertweck said:
> >William F Mitchell schrieb:
> >>With intent(in) the compiler can assume the argument will not be changed.
> >>If the user overrules it as you suggest, then the program is not standard
> >>conforming.
> >
> >I have not found any rule that prohibits this. In a pointer assignment
> >definition there is no constraint to that effect
>
> Programs must obey all rules in the standard, not just the constraints.
I agree with that.
> The only thing special about the constraints is that the compiler is
> required to diagnose their violation.
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.
> 5.1.2.3 states
> "The INTENT(IN) attribute specifies that the dummy argument shall neither be
> defined nor become undefined during the execution of the procedure."
>
> 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.
What is WW3?
> [...]
> >As far as I can see, the production of undefined pointers is
> >standard-conforming,
>
> Yes indeed it is; but all you can do with them is pointer-assign them to
> other pointers, you are not allowed to reference or deallocate them.
>
> ...again, the compiler need not diagnose any error you make.
>
> >It is not only the interface: the function result is a pointer-assignment.
> >A function like that does NOT make sense if it returns an undefined pointer.
>
> It might not make sense to you (or indeed to me), but pointer functions are
> perfectly entitled to return undefined pointers. It is up to the user not
> to do anything harmful with them.
>
> >Here is an improved
> >version of the function RES2 which will NOT accept the result of the RESHAPE:
> >
> > function ptr(a,n1,n2)
> > integer, pointer :: ptr(:,:)
> > integer :: n1, n2
> > integer, target, INTENT(INOUT) :: a(n1,n2)
> >
> > ptr => a
> > end function
> >
> >The INTENT(INOUT) makes sure that the actual argument a(n1,n2) cannot be
> >an expression (or, which is basically the same, an indexed array section).
>
> No it does not. It does make sure it cannot be an expression, but an
> array section is perfectly acceptable; the compiler will almost
> certainly generate a copy-in copy-out in this case (which will result
> in "ptr" being unusable).
At least three compilers do NOT accept indexed array sections
(among them also NAG F95):
DEC Visual F95:
--------------------
prog.f90(16) : Error: An array section having a vector subscript is not permitted
if
dummy argument has intent [IN]OUT [X1]
p2 => ptr(x1(z),n,n)
-------------^
IBM F95:
-----------
"prog.f90", line 16.14: 1516-056 (S) An accessible explicit interface has a
dummy argument with the INTENT(OUT) or INTENT(INOUT) attribute
specified.
Corresponding actual argument which is not definable is not permitted
in this context.
NAG F95:
------------
Error: prog.f90, line 16: Argument A (no. 1) of PTR is OUT or INOUT but is not a
variable
> >When the actual argument corresponding to a(n1,n2) does not have the TARGET
> >attribute, the function permits a pointer to be assigned to a non-target
> >object, which moreover violates the rule that a pointer shall only be
> >assigned to a target of the same type,
> >kind type parameters, and rank (sec. 7.5.2 - Pointer assignment).
>
> >I do not feel uncomfortable with this situation
>
> I agree - this is not very nice at all.
>
> >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: is it legitimate to ask for
a data structure to be viewed in different ways? I believe it is.
(Van Snyder said that in his case to copy the data, because of its size,
would not be feasible.) There is of cause one old way to do it in Fortran
(Fortran 77): by using EQUIVALENCE, probably with data in a COMMON
block. So the facility was (is) there; but this to use a pointer would probably
be a better way to describe it; one should avoid COMMON in modern Fortran
(and EQUIVALENCE anyway).
> 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?)
> 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. 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.
> 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: I would require from
an optimizing compiler NEVER to change the semantics of a program
(things like arbitrary order of evaluation, etc. are covered by the standard).
There are some examples where this is done (IBM -O3 has that property;
though they sometimes issue a warning, I never use this level, only -O2).
Reliability is first, speed is second, in my opinion.
(Everybody knows the frustration when an optimized program fails,
but the -g version works perfectly well.)
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.
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.
> 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. Instead of "shooting ourselves in the foot" we need
another solution than going back to Fortran 77 or (forward?) to C
(where these things are done all the time - but on a lower level because
you actually can use addresses of object directly).
Regards,
Friedrich
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
