problem in interface
in [Fortran]
|
Prev: What exactly does the SAVE statement do ?
Next: "static" explanation. What exactly does it mean?
From: Richard Maine on 25 May 2010 20:24 mecej4 <mecej4.nyetspam(a)operamail.com> wrote: > rudra wrote: > > > This might be a silly question and/or i am missing a faq but plz help > > me. I have a subroutine declared as: > > < subroutine declared with 67 arguments > > > > In the main program, I have defined an interface > < interface declared with 67 arguments > > > > > and then called the subroutine as > > < subroutine call with 63 arguments > Good job (even though you later coment off-by-one) of doing the counting that I said seemed like too much pain. I guess taking off my wife's shoes wouldn't have been enough either. :-) I've seen compilers that wouldn't even take that many arguments. I doubt Intel has a limit that low, but I'm pretty sure I recall a limit of 63 from some compiler or other once. I think I might even have seen lower ones, but I'm at least a little confident of the 63. (Maybe an old Microsoft compiler???) -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: rudra on 26 May 2010 02:22 I know its quite messy to find things out from this. Is there any way or if someone is interested, I can send the full package...I am struggling with this problem for last 6 month(if not more). Plz help
From: Louis Krupp on 26 May 2010 04:15 On 5/25/2010 11:58 PM, rudra wrote: > If you do not mind a long post, plz let me allow to post the code > snippets. > You can, if you plz, check the thread > http://software.intel.com/en-us/forums/showthread.php?t=74110 > in intel forum as the full code are attached there. > > THE SUBROUTINE: <snip> > IS MAKEd AS: > .f.o: > $(FC) -c $(PREFLAGS) $(FFLAGS) $< > mv $(*F).o $(*D) > # > .c.o: > $(CC) $(CCFLAGS) -c $< > mv $(*F).o $(*D) > > .f90.o: > $(FC) -c $(PREFLAGS) $(FFLAGS) $< > > lm-lib.o:MAIN/lm-lib.f90 $(lmobj)#MAIN/lm-lib-end.f90 > $(FC) -c MAIN/lm-lib.f90 > > THIS IS DONE IN LMTO-A directory, AND MAKEd WITHOUT ANY COMPLAIN > > THEN I HAVE(IN ANOTHER DIRECTORY NAMED ASR) <snip> > WHICH IS MAKEd AS: > $(PROG): $(FOBJ) > $(PFC) $(FFLAGS) $(FPAR) -o ${PROG} $(FOBJ) -I${LMPATH}/LMTO-A/ > (LMPATH IS DEFINED AS /home/rudra/asr_full) > ...... > main.o : main.f90 util.o ldos.o fermi.o band.o dos.o \ > mmat.o hop.o shared.o param.o kind.o cgreen.o \ > bit_unm.o nis.o pardos.o file.o prinit.o \ > ../LMTO-A/lm-lib.o > > NOW, WHILE MAKEing, I AM GETTING ERROR: > $ make > ifort -c -openmp main.f90 > ifort -openmp -o irun band.o cgreen.o dos.o fermi.o hop.o kind.o > ldos.o main.o mmat.o newfit.o param.o pardos.o shared.o thread.o > util.o bit_unm.o nis.o file.o prinit.o -I/home/rudra/ASR_FULL/LMTO- > A/ > main.o: In function `MAIN__': > main.f90:(.text+0xac5): undefined reference to `mlm_a_mp_lm_a_' > make: *** [irun] Error 1 > At this point, seeing your entire makefile (and its entire output) might be more useful than seeing the code. Are you using the "-openmp" flag consistently? What happens if you try to build without -openmp? As a wild guess, you might be compiling your main program with -openmp and your module without it. Louis
From: rudra on 26 May 2010 04:46 On May 26, 1:15 pm, Louis Krupp <lkrupp_nos...(a)indra.com.invalid> wrote: > > As a wild guess, you might be compiling your main program with -openmp > and your module without it. You are right. The module in question(in LMTO-A) is compiled without openmp while those in ASR is with openmp. But the subroutine in question is always called outside the openmp region
From: dpb on 26 May 2010 09:13
rudra wrote: > On May 26, 1:15 pm, Louis Krupp <lkrupp_nos...(a)indra.com.invalid> > wrote: >> As a wild guess, you might be compiling your main program with -openmp >> and your module without it. > > You are right. The module in question(in LMTO-A) is compiled without > openmp while those in ASR is with openmp. But the subroutine in > question is always called outside the openmp region I don't know anything about the effects of trying that or not; somebody else surely does but it would certainly seem worthwhile in eliminating the possible discrepancy simply as an expedient test. But, I notice the previous link step left an unresolved external so there's obviously still some problem(s) that shouldn't be too hard to sort out to at least get a clean build. And, I'll return to the previous mantra of the need for a self-consistent build of all the pieces w/ all options being consistent--it surely sounds and smells like something of the sort may be a problem. Of course, again, w/ such a terribly complex call structure and poorly formatted code to even begin to look at, it's quite high probability that even if you now have via the module gotten the number and type of arguments to agree you still have one or more errors in more subtle ways that are index related or so on. I, as Richard, seem to recall a great deal of confusion earlier on the types of argument arrays and a mishmash of styles...there's another point of potential problems... In general, my advice is to step back and reconsider the structure of this mess and do something about that first. If you've had six months of no joy going this route it seems clear it's time to look for a path to the freeway instead of trying the off-road track over the mountains on foot. -- |