Phillip Helbig wrote:
>>How is CONTAINS supposed to work legally. There is no full explanation
>>in my help or manuals.
>
>
> I've used it for years. I think we use the same compiler. :-)
>
You don't just think we do, you know we do :-)


>
>>If I have the situation where SUBROUTINE A calls SUBROUTINE B, and
>>SUBROUTINE B calls subs C and D, since CONTAINS cannot be nested , can I
>>write:
>
>
> Right, CONTAINS cannot be nested.
>
>
>>SUBROUTINE A
>>
>>CALL B
>>
>>CONTAINS
>>
>>SUBROUTINE B
>>CALL C
>>CALL C
>>CALL D
>>END SUBROUTINE
>>SUBROUTINE C
>>END SUBROUTINE
>>SUBROUTINE D
>>END SUBROUTINE
>>END
>
>
> This looks OK on the face of it. (I recommend putting the names of the
> subroutines in the END SUBROUTINE statement, though.)
>
Agreed about the names, just being lazy here.


>
>>Before I contact the vendor, I would like to know the legality of this
>>sequence. It compiles but gives me incorrect results.
>
>
> Does it compile without even a warning when all the compiler options are
> set to produce strict warnings? As to the results, you probably need to
> post a more complete example.
>
Yes, no warnings. We always want to get whatever informationals or
warnings the compiler wants to give us and then eliminate the cause of
the message.

In this case, I eventaully tracked this down with the debugger. And
another case for IMPLICIT NONE. In the sequence above, none of A, B, C
or D had used it and most variables were assuming implicit typing. I
had combined the routines with contains and had not added any explicit
type declarations.

In B, the call to D was within a DO I loop passing subscripts (I) of
arrays into simple variable dummy arguments. D contained a local DO I
loop and somehow, since it presumably thought it inherited I from B,
managed to make a complete mess of the subscripts in the call arguments.

By changing the loop variable name in D, the correct results were
obtained. Since D, according to the annotations, was in-lined to B, I
am reporting this to the vendor as a compiler bug as it should have
given me an error that told me that the loop control variable was
identical to that in an outer loop.

>
>>I also found that if C and D were functions I would get a compilation
>>warning that one of them had been completely wiped out by the compiler.
>
>
> Do you mean "optimised away"?
>
No, I forgot the exact wording while I was writing the above. It was
"F90-W-WARNING, Routine XXX is not called and has been eliminated."
This is obviously not the same as being eliminated. This was a similar
structure to the above code sketch and the function was D being used in
B. Changing the function call to a subroutine with an extra output
argument did not "eliminate" it.

>
>>A debug session shows me that it enters routine C, but seems not to have
>>inherited variables from B. Therefore, a secondary question, should all
>>contained routines only inherit from A, or if called from B do they
>>inherit B's variables too? I get a compilation warning that a variable
>>that I assumed was inherited from B in C is used before a value is set.
>>B always sets the variable before the call.
>
>
> No, just from A. Calling C from B is the same as if these were both
> external subroutines. (If C inherited from B, this would be "implicit
> nesting".)
>
>
Thanks I had guessed that but thought I would confirm.

>>These warnings tend to give me the impression that CONTAINS can only go
>>down one level unless the compiler totally in-lines the code.
>
>
> I don't follow this. It cannot be nested, as you said.
>
Bad phrasing on my part. Sorry to confuse. I was really just
paraphrasing, in what I thought easier language, what I had said in my
previous paragraph :-(

>
>>My compiler inlines B into A and also declares that it has in-lined D
>>into A, but no mention of C, wherein lies my failures.
>
I was wrong, my failures were in D as noted above. It was the nature of
the failures prior to my full investigation that made me think this. C
was calculating the variables correctly, but D was happily overwriting
them was its subscript mix-ups.

>
> Do you see a difference between compiling with and without optimisation?

No, since the debugger showed up the errors, and obviously I had /noopt
for a debug session.

Many thanks,

Regards, Paddy



***********************************************************************

"This electronic message and any attachments may contain privileged
and confidential information intended only for the use of the
addressees named above. If you are not the intended recipient of
this email, please delete the message and any attachment and advise
the sender. You are hereby notified that any use, dissemination,
distribution, reproduction of this email is prohibited.

If you have received the email in error, please notify TransGrid
immediately. Any views expressed in this email are those of the
individual sender except where the sender expressly and with
authority states them to be the views of TransGrid. TransGrid uses
virus scanning software but excludes any liability for viruses
contained in any attachment.

Please note the email address for TransGrid personnel is now
[log in to unmask]"

***********************************************************************