Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
FPGA community forums and blogs have moved to the Altera Community. Existing Intel Community members can sign in with their current credentials.
29317 Discussions

Compiler arbitrarily ignores USE statement?!?

Dogbite
Beginner
864 Views

I am in the process of trying to scale back my program's use of memory in preparation for implementing OMP. As many of the arrays have the same dimensions I decided to replace the hard-coded numbers with values defined via the Parameter statement. As I had already placed a large number of parameters in a module, I decided to add these parameters to the existing module.

The subroutine code lookslike this:

-----------------
SUBROUTINE PROCNAME(ARG1,ARG2,ARG3)

C INFORMATIVE COMMENTS
C

USE HERS_PARAMS

INCLUDE 'SECTN.CMN'
---------------

The modules HERS_PARAMS includes the following:

----------------
INTEGER ININCR, WZIMP, NUMIMPS, FPMAX, IMP_RANGE
PARAMETER ( ININCR = 3 )
PARAMETER ( NUMIMPS = 11 )
PARAMETER ( FPMAX = 6 )
PARAMETER ( IMP_RANGE = (NUMIMPS+1)*ININCR )
------------------

The pertinent definitions in the common block are:

-------------------
REAL, DIMENSION (0:IMP_RANGE,0:FPMAX) ::
& ESALS, ESALSM, PSR, PSRM, VC

-------------------

Of the 72 subroutines that use HERS_PARAMS and include SECTN.CMN 68 compile without problem. But three subroutines and one Real Function don't seem able to use the parameter module. For each of the five arrays dimensioned above they generate "error #6756: A COMMON block data object must not be an automatic object. [arrayname]" followed by " error #6279: A specification expression object must be a dummy argument, a COMMON block object, or an object accessible through host or use association [parname]" for each of the two parameters.

For two of these routines, the set of messages is generated once, for a third twice, and for the fourth, four times.

What bad articles have I done in my youth that now the compiler would treat me this way?
0 Kudos
4 Replies
Steven_L_Intel1
Employee
864 Views
I'm sure that the compiler is not ignoring the USE statement, but something else is going on. For example, you may have a local declaration that hides a name brought in by host association.

Can you come up with a short but complete example that demonstrates the problem?
0 Kudos
Dogbite
Beginner
864 Views
I'm sure that the compiler is not ignoring the USE statement, but something else is going on. For example, you may have a local declaration that hides a name brought in by host association.

Can you come up with a short but complete example that demonstrates the problem?

Well, sometimes all that is needed is a nudge to look elsewhere, in this case, deeper into the subroutines. What I found is that all of the files generating errors contained multiple subroutines/functions, and the errors were generated because I had not inserted the USE statement for each subroutine. That done, the problem was solved.

Thanks for the nudge!
0 Kudos
Steven_L_Intel1
Employee
864 Views
You're welcome.
0 Kudos
gib
New Contributor II
864 Views
Quoting - Dogbite

Well, sometimes all that is needed is a nudge to look elsewhere, in this case, deeper into the subroutines. What I found is that all of the files generating errors contained multiple subroutines/functions, and the errors were generated because I had not inserted the USE statement for each subroutine. That done, the problem was solved.

Thanks for the nudge!
What I do is put subroutines/functions into a module, with the USE statement in the global section of the module. Nesting modules in this way I never have USE in any subprograms, only in the main. I'm not saying this is the best way, just a way.
0 Kudos
Reply