From: Richard Maine on
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
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
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
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
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.

--