CODEWITHSUNDEEP
compiler-errorsfortran
canavanin
canavanin

Reputation: 2709

Fortran compiler error

I'm trying to compile my program with the intel Fortran compiler for Linux (version 12.0.3) and I'm getting this error:

buggy.f90(206): error #6219: A specification expression object must be a dummy
argument, a COMMON block object, or an object accessible through host or use 
association   [SPECTRUM]
    type(spect)                       :: spectrum
 ----------------------------------------^

This is within a module. type(spect) comes from another module, which I use at the beginning of the troublesome module. Here's some code; more details can be found below.

module non_buggy

   implicit none

   type axis
      character(len=6) :: nucleus
      integer          :: num_data_points
      real             :: spectral_width
   end type axis

   type spect
      integer                 :: num_dim
      type(axis), allocatable :: axes(:)
      real, allocatable       :: intensity(:)
      character(len=10)       :: type = ''
   end type spect

   type(spect), target :: spectrum  ! might this be a cause of error?

   contains
   ! ...
end module non_buggy


module buggy

   use non_buggy

   implicit none

   contains

   subroutine no_problem_here()

      type(spect) :: spectrum  ! compiles beautifully
      ! ...
   end subroutine no_problem_here

   subroutine problem()
      type(spect) :: spectrum  ! does not compile, but no error if I change the variable name
      ! ...
   end subroutine problem
end module buggy

I have read about what the error means, but I have the impression that does not apply to what I'm doing in my code - no array bounds are specified on those lines. As the error goes away if I rename the second occurrence of spectrum to something else, I was wondering whether the problem might have something to do with the module variable spectrum in module non_buggy (but then the error persists, even if I comment out the line in which the module variable is declared). If a Fortran expert could clarify that issue I would be most grateful.

Thanks a lot in advance!

Upvotes: 1

Views: 4835

Answers (2)

Stefano Borini
Stefano Borini

Reputation: 143755

Can't reproduce with ifort 11 on linux and osx. I don't have ifort 12 so I can't verify, but the point here is that you are exporting spectrum from the module, which is most likely a bad idea. Always use the keyword private in your modules, and make public explicitly only what you want to let out.

If you want to make spectrum a module variable (something I don't understand, why would you? do you expect one and only one spectrum ? Are you sure about it?) you may also consider if you need a save keyword to preserve the values.

Finally, you are overshadowing a module variable. Idiotic fortran has no concept of namespacing. If you slam everything from a module within another module, you pollute your namespace, and you are very likely to end up with these cases. Favor subroutine import in some cases, to limit the damage (although it becomes less communicative). Keep your module vars to a minimum, and when you do, either prefix them with a unique prefix, or simply don't use them and discipline yourself in OOP-like layouting of your code.

Modules should be stateless. You gain both in flexibility and reduced multithreading headaches.

Upvotes: 4

Francois Jacq
Francois Jacq

Reputation: 1274

I don't see any error in you code sample, even if it is error prone to declare local variables (within the routines no_problem_here and problem) having the same name (spectrum) as a global variable (the one on the module non_buggy).

What compiler are you using ? I compiled your sample with ifort 11.1 and gfortran 4.7.0 without trouble (just in commenting the keyword CONTAINS of the module non_buggy because ifort complains that there is no instruction between "contains" and "end module").

Upvotes: 2

Related Questions