Strange Subroutine%UserDefinedType error message

[IanH]

I'm getting a bizarre error with 10.1.030:

filezzz.f90(xx) Error: This name does not have a type, and must have an explicit type. [FOO%BAR]
(yy) Severe: FATAL ERROR - possible out of order or missing USE

- FOO is a public subroutine defined in a separate module that is being USEd
- BAR is a public user defined type (not a component of a type!) defined in a different, separate module that is being USEd
- The line that supposedly has the error is an OPEN statement that references neither FOO or any BARs.

FOO's arguments do include a couple of BARs, the subroutine that contains the offending line does call FOO and does have a few BARs as local variables. I didn't think the order of USE statements was significant.

Any hints as to how this could pop up? I'm wondering whether I've got some sort of weird name clash going on.

IanH

(I can't use the 11.0.xxx series of compilers because they ICE elsewhere (already reported)).

[Steven_L_Intel1]

I would be more likely to guess a compiler bug here - that "FATAL ERROR" message is always associated with a compiler bug. Can you provide the sources needed to reproduce this? (Include sources of any modules used.) Have you tried it with 11.0 to see if it compiles?

[IanH]

Quoting - Steve Lionel (Intel)

I would be more likely to guess a compiler bug here - that "FATAL ERROR" message is always associated with a compiler bug. Can you provide the sources needed to reproduce this? (Include sources of any modules used.) Have you tried it with 11.0 to see if it compiles?

Ok, I'll file this with premier support.

I had switched from 11.0.066 back to 10.1 because of internal compiler errors that occur elsewhere in the code (these have already been reported to premier support).

I'm a bit boxed in now. Any insights on known issues with certain constructs that I can then try and avoid would be appreciated. This issue has emerged while integrating library routines together, not while writing new stuff, so there isn't really a previous code version that I can drop back to.

[Steven_L_Intel1]

I couldn't even begin to guess. If I saw a source to work with, I might be able to figure out something. In the past, errors such as this have been triggered by inheriting symbols from multiple modules, some with PRIVATE. Sometimes removing the PRIVATE helps.