Quick, dumb question

[kdkeefer]

Is an explicit INTERFACE block generated for a subprogram in a module? If not, and the subprogram needs one, would it go in the specification part of the module?
Thanks,
Keith

[Jugoslav_Dujic]

Don't confuse terms "explicit interface" and "INTERFACE block". Thus, the construction "explicit INTERFACE block" makes no sense :-). The latter (INTERFACE block) is one of ways for achieving explicit interface. The other two are putting the subprogram in a module and USE it ("use association"), and putting both programs either into the same module or making one internal to the other ("host association"). Thus, yes, explicit interface is generated for a subprogram in a module.

Jugoslav

[kdkeefer]

Thanks for the answer and correcting my diction. I was pretty sure that the situtation was as you described it. My question arose from desperation for the source of an "Internal Compilier Error" and an ambiguity in the Compaq LRF which states that explicit interfaces are generated for module procedures but since the manual defines a module as a form of procedure, it was not perfectly clear that interfaces were generated for subprograms contained in the module, and I am grasping at straws.
Thanks,
Keith

[Jugoslav_Dujic]

My question arose from desperation for the source of an "Internal Compilier Error"...

Need I say that the best way to find the source of Internal Compiler Error is to send your workspace to official support channel? ICE is a compiler bug -- it's the job of compiler writers to find it out :-).

Jugoslav

[kdkeefer]

Jugoslav,
The key word here is "desperate". The bug has been reported, with code exhibiting it, to Intel for over 6 weeks now. The response has been "we know what it is and it will be fixed in the next patch". Two or three patches later, it is still not fixed. In fact, I just sent another, (my 6th) message to Intel Premier Support.
I assume that I am being "blown off" as an idiot who seems to be the only one with the problem. Hence my post asking about other people who may have had a problem with IFV7.1. My observations and instinct suggest that the problem is caused by a module that compiles without error, but has some sort of defect that causes the compiler error when the module is USEd. The only thing in this module that is remotely unusual is functions that return arrays. Explicit interfaces are required for such functions, hence my question about module compilation creating interfaces for its contained procedures. Believe me, I would not be posting such obvious "flame bait" such problems that readers of the forum know should be directed toward Intel, or such obvious (I said it was dumb) questions about interfaces, unless I was desperate.
Thanks much for your help and comments.
Keith

[Steven_L_Intel1]

Keith,

You are not being "blown off" nor are any of the Intel support people "idiots". I'll check to see what happened here and get back to you. (I've been out of the office since Thursday.) I'm sorry that you've not received the support you expected and will see if I can get things straightened out or at least explained better.

Steve

[kdkeefer]

Steve,
Thanks for reading and answering. Please, I actually said "blown off *as* an idiot", not by idiots. I know Intel people are not idiots. I also know that if only one guy in 10,000+ is having a problem with their compilier, the odds are that the problem lies with the guy (me) and not the compiler. That is why I asked if anyone else had encountered to problem. I also understand that the compiler writers are overworked and this problem could take time to track down. That's why I spent a lot a time doing a lot of the "pare it down, mix and match" work that Jugoslav was ribbing me about doing instead of letting the "compiler people" fix it. I am 99% sure that the problem is in the module "utilities" that I referred to, since I get the error compiling other routines that USE it and the procedure that used to give the error, no longer USEs it and no longer gets an error.
I appologize for the fact that I seem to others to be more upset than I really am and perhaps I sound worse in e-mail.
Keith
P.S. I saw a full page ad for Compaq Fortran V6.6 in the "Programmer's Paradise" catalog.

[Jugoslav_Dujic]

I see now.

Keith, I'm not too surprised with compiler's mishandling of function returning an array; these are seldom used and a bit itchy to implement.

An obvious way to workaround the problem is to turn the function into a subroutine which returns the array as an argument. Of course, that requires a rework on the caller side as well.

Another alternative is to turn the function in question to an ELEMENTAL one (taking scalars as input and producing a scalar as output). For example, intrinsic SIN (and almost all other intrinsics) is elemental because it can be called with scalar argument returning scalar or with an array argument returning array. That won't be always possible due to limitations on ELEMENTAL routines -- all arguments must be intent(in), and no global variables may be changed within the routine (see ELEMENTAL in Programmer's guide to see if your function fits).

Jugoslav

[Jugoslav_Dujic]

...of course, you should ascertain first that the function returning the array is triggering it. The "classic" way to isolate ICEs is "dissection" method: comment all of the suspicious code first; comment calls to that routine in the caller as well; recompile both. Reduce the amount of suspicious code until you isolate it. You can use !DEC$IF(.FALSE.)...!DEC$ENDIF as "block comment" to speed up the process.

Jugoslav

[kdkeefer]

Jugoslav,
Thanks. I've actually be doing just what you suggested-commenting out or eliminating code to attempt to localize the problem. That's how my suspicions led to a defect in the preceding module. And I have be suspicious of the return of the array, as that was the only thing that was not pure "vanillia" Fortran. I thought that perhaps since so many intrinsics return arrays or array sections that all the return conventions were worked out. I guess they probably are-what may not be worked out is how they are described in a module. Using the function generates such neat, conscise code I am loath to give it up and rewriting it invites more complications. But at this point, the code only has to compile, not run, so I need only worry about my stripped down code generating too many compiler messages-that's a sure way to get an internal compiler error-overload it with a large, unforseen mess of error messages. Now that I am more confident of where the problem is and what it is, I may go to look for it. This is not the first time that I have found obscure errors in vendor code and I know that it takes some time and effort to build enough credibility so that tech support really believes that the problem may be in their code and not mine. Also, I can strip down my code to the essentials, with the fewest side effects much more quickly than tech support can. All I really wanted from them initially was just an idea of what to look for. After all, they presumably know what the compiler was doing when it gave up. I may have a go at it today.
Regards,
Keith