get compiler error when should not

[zmth]

i want to pass variable array size to subroutine. the following will illustrate

integer*1 i,is ,j,j1,j2,m1,m2,np,npmx,nps
integer*1,allocatable::ilisin),ils)
common nps,npmx,np
npmx=2;nps=3
allocate(ilisin(nps),ils(2*nps-min(3,nps)))
call wigd(1,ilisin,0,ils)
end
subroutine wigd(ii,ilisin,imn,ils);integer*1 i,ii,imn,np,nps
integer*1,allocatable::ilisin),ils);common nps,np
print*,"nps",nps
end

NOw it gives error as says interface required. So i read all about this ' interface ' which should not be required anyway as no reason for fortran to require it but anyway i put in the interface command as follows.

integer*1 i,is ,j,j1,j2,m1,m2,np,npmx,nps
integer*1,allocatable::ilisin),ils)
common nps,npmx,np
npmx=2;nps=3
allocate(ilisin(nps),ils(2*nps-min(3,nps)))
call wigd(1,ilisin,0,ils)
end
interface
subroutine wigd(ii,ilisin,imn,ils);integer*1 i,ii,imn,np,nps
integer*1,allocatable::ilisin),ils);common nps,np
print*,"nps",nps
end; end interface

And it comes back with another error saying two main programs !! Does anyone know why this is not working ?

 

[xwb]

Move the definition of your routine before the main program.

 

[salgerman]

Either use Fortran90 or Fortran77...and cut this bs about neither and both.

 

[zmth]

yes thanks i did figure out yesterday to move it up and in fact I had to actually write some of the code twice as that interface does not actually call the subroutine - seems like they would have made fortran 90 so that one would not have to use that interface statement but i finally got it to work surprisingly. Tried to optionally use the module statement to also do away with the common statements but unfortunately code blocks with gnu fortran will not allow any module statements due to a fault of one or the other most likely gnu fortran - in fact it is so full of bugs i will likely have to abandon and write programs in Basic.

 

[Beilstwh]

Of course it calls the subroutine
call wigd(1,ilisin,0,ils)

on the last line of the main routine. How can it validate the routine when it hasn't even seen the subroutine defination yet.

Bill
Lead Application Developer
New York State, USA

 

[salgerman]

There you go again, zmth, blaming the compiler and not looking to your own ignorance...sorry if such choice of word sounds rather harsh, I only mean in its more factual meaning...you just don't know Fortran very well and do not even aknowledge it.

No shame on not knowing something, you know? Every one was born knowing nothing and nobody knows everything. And the moment you claim to know something, that's the moment you stop learning anymore about it.

In a couple of other earlier threads, here and the physics forum, you were pretty stuborn about not being at fault...I don't know about everybody else, but it sure puts me off and don't even feel like helping; I'd tell you, a little humility would go a long way.

Good luck.

gsal

P.S. "Growing old is mandatory. Growing up is optional."

 

[zmth]

Of course it calls the subroutine
call wigd(1,ilisin,0,ils)

on the last line of the main routine. How can it validate the routine when it hasn't even seen the subroutine defination yet. "

NO not exactly as the original problem using module rather than interface was not with my code NOR gfortran but with code::blocks as I did the same exact code program, much longer and more involved than that simple example , at the command line in dos using gfortran and using module not the less desirable interface and all worked well and that was with the module and main program in either order ! But not when done in code::blocks. Beginning to understand .f90 better now - maybe someday about pointers but not quite yet-thanks for your help.

 

[mikrom]

Hi zmth,

When you are posting the code, so paste your code between these TGML tags:
[pre]

[/pre]
...and ...
[pre]

[/pre]

unfortunately code blocks with gnu fortran will not allow any module statements

You will find in this forum lot of code examples with modules, which were succesfully compiled in gfortran, which implies that modules work well in gforran.
You mix here the problems which you have probably with your IDE Code::Blocks. IMHO, IDEs are for beginners counterproductive, because they usually cannot set them properly (which is probably your case too). On the beginning it's better to use a good editor and compile/execute the program at the command line.

due to a fault ... most likely gnu fortran - in fact it is so full of bugs i will likely have to abandon and write programs in Basic.

Your remarks are very offensive to the address of GNU Fortran compiler... but thing: if it was so bad, no one would use it
You are not right, gfortran is very good and productive stable compiler with a large user community.

Think a little bit before you something say: You don't have the required level of knowledge, to be able to assess whether there are bugs in the compiler.

But you can try g95 too, which is other free and very good compiler.

One of the big advantages of the free compilers is the large user community, so if you have a problem you will probably find an answer, because somebody has solved it before.

If you are not happy with a free compiler, you can buy a commercial one and see if it makes you happy and if you will get better support. I'm forced to use at my work a very expensive commercial development tools and I must say that the support is terrible - there isn't a user community, no information, no support.

And finally, if you're not able or willing to learn this language, then you can try Basic or another programming language.

But do not be offensive. This is a programmers forum. We are here to help each other and to expand our own knowledge.

 

[zmth]

apparently you did not read my last post where i said the problem was NOT gfortran nor my code but with code::blocks. My fortran 90,95 code compiles and runs fine when invoking gfortran from dos command line. Yes prior to that it was a bit hasty to blame gfortran.

 

[zmth]

But the gfortran manual is incomplete. They go into detail about various options and flags but leave off the most important ones such as small c as in for example
gfortran -c file.f90 and small o as in gfortran -o name file.f90

and basically don't say anything about basic invocation to compile which also may use one of these.
And in the intrinsics left out statement SELECT CASE

 

[mikrom]

The command line options you mentioned are common for GNU compilers (gcc, g++, gfortran):
You an use command line option --help to get the description:

$[highlight] gfortran --help[/highlight]
Usage: gfortran.exe [options] file...
Options:
  ...
  ...
[highlight]  -c                       Compile and assemble, but do not link
  -o <file>                Place the output into <file>[/highlight]
  ...
  ...

For example if you have a source file called zmth.f95 and you want create from it an executable called zmth (on windows zmth.exe) you can use this simple command

$ gfortran zmth.f95 -o zmth

 

[zmth]

-c Compile and assemble, but do not link
-o <file> Place the output into <file>

Yea I figured that out prior but was saying it is really strange that something that basic and fundamental is not in the gnu fortran manual along with the basic invocation

gfortran file.f90 to compile and link and make a.exe .

 

[salgerman]

But it is.

If you go the gfortran user's manual, look at the table of contetns, you will see Chapter 2 Fortran Command Options...click on the page number, which is a link...then, read those short paragraphs.

 

[zmth]

You mean where is written :

" See Section “GCC Command Options” in Using the GNU Compiler Collection (GCC)
,for information on the non-Fortran-specific aspects of the gcc command (and, therefore,
the gfortran command) "

which is not in that book but in a different one ? For example in this book regarding
-c is only capital -C which is not the same.

 

[salgerman]

Yeap, that's correct.

I guess it takes a bit of history to know why that is the case; certainly, they do not want to duplicate efforts.

The thing is that all these tools are prepare by the same group and they are meant to work similarly. If I remember correctly, there was a time when you could compile any of the available languages by simply typing a 'gcc' command...and it would figure it out; the 'gcc' command itself worked as a front end for C, C++, Java, even Fortran compilers. I am not sure if that is still the case.

Basically, when it comes to finding out how to use a program (let alone programming in it), you really need to keep your detective hat on...and this is also true even for commercial, supported programs. Lastly, google is your friend; but there will be various links and you gotta make the most of them.