Alvaro Fernandez writes:
> [Alvaro] I meant: _when_ does the compiler _set aside memory_ for this
> array?
Oh. I had no clue that this was what you were asking. The answer is
processor-dependent. The standard doesn't cover things like that at
all. But in practice, the most common answer is that the compiler
*NEVER* sets aside memory for dummy argument arrays. The memory is in
the actual argument and the dummy just "points" to that memory that
already exists.
The next-to-most-common answer is that the memory is set aside on
entry to the procedure. That is the copy in part of copy-in/copy-out
so often discussed here. The conditions that trigger it have nothing
to do with optionality. Presumably, if the actual isn't present
then no memory will be set aside; it certainly wouldn't need to be,
but that's a compiler implementation detail.
In theory, a compiler could do many things, including "lazy" copy
methods where the copy is delayed until it is needed. I don't
know of any optimizers smart enough to play that kind of trick,
but it might happen - particularly with interprocedural analysis
and inlining.
Anyway, it is all very processor dependent, and none of it has
anything to do with what is or is not legal code. This is a compiler
implementation detail. It may have to do with how efficient code
is.
> [Alvaro] To be pedantic, I meant "an if-then block wherein the PRESENT()
> intrinsic is called". Since it is impossible _in my experience_ to
> reference an optional argument except inside such a structure, I have
> taken to calling them "if(present) blocks".
...
> [Alvaro] Perhaps it has been the compilers I have dealt with, but
> without the reference being inside a check using PRESENT, I find I can't
> reference the argument, whether present or not. But that's another
> issue.
If that is really true, then those compilers are *SERIOUSLY* broken -
so seriously broken that it strikes me as implausible (though not
impossible). There simply is no such concept and inventing a name for
the non-concept doesn't help. I'd like to see an actual sample and
corresponding compiler messages. Shouldn't take more than about half
a dozen lines of code to trigger that. Also, are these warning
messages or errors? If they are warnings and if they are the result
of flow analysis instead of block structure, then they might make
sense. But any compiler that complains about, for example
subroutine sub(x)
real, optional, intent(in) :: x
write (*,*) 'Here we are.'
if (.not.present(x)) return !-- Nothing else to do.
write (*,*) x
return
end subroutine sub
is so badly broken that you should demand your money back. Scarcely
seems worth the trouble of submitting a bug report. Note that there
isn't a block in sight. However the compiler might well be able to
do flow analysis and conclude that x was never referenced except
when it was present. This is not only legal, it is a perfectly
reasonable style...particularly if there are lots of optional
arguments.
Even without the test, the code
subroutine sub(x)
real, optional, intent(in) :: x
write (*,*) 'Here we are.'
write (*,*) x
return
end subroutine sub
is legal as long as it is never called without an argument. Perhaps
a little strange and thus worth a warning, but if it generates an
error, then submit a bug report - the compiler is non-conforming.
> <html> [and a lot of html stuff]
... (please don't do this)
--
Richard Maine | Good judgment comes from experience;
[log in to unmask] | experience comes from bad judgment.
| -- Mark Twain
|
