Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

Subroutine / Undefined Address

gwen06
Beginner
1,780 Views

Hello,

I am trying to pass two lines of charactersfrom asubroutineto an another one :

For the first one :

[bash]SUBROUTINE METH() IMPLICIT NONE CHARACTER(len=20) :: A CHARACTER(len=20) :: B A = "Azerty" B = "Ytreza" CALL APPMETH(A,B) END [/bash]

and for the second one :

[bash]SUBROUTINE APPMETH(C,D) IMPLICIT NONE CHARACTER(len=20) :: C CHARACTER(len=20) :: D print *,C print *,D END [/bash]


Nevertheless, the variable D seems not be defined in the second subroutine.
The error message'Undefined Address' is given in the debugger and the D character array is not printed on the screen.

What is wrong ? Which mistake have I done ?

Gwen

0 Kudos
8 Replies
Arjen_Markus
Honored Contributor I
1,780 Views
Try it with:

SUBROUTINE APPMETH(C,D)

IMPLICIT NONE

CHARACTER(len=*) :: C

CHARACTER(len=*) :: D

print *,C

print *,D

END

I think the fixed character lengths you use in APPMETH get in the way.

Regards,

Arjen

0 Kudos
gwen06
Beginner
1,780 Views
Sorry, but it is worse !!

Indeed, the message 'Undefined Address' appears now in the debugger for the two variables C and D.
And the printing on the screen of C and D is completly bad.

Now the character line D is not the single one with this error.

Regards,

Gwen
0 Kudos
mecej4
Honored Contributor III
1,780 Views
There is more to this problem than what you have shown. The code below, which is a complete program with your code, compiles and runs with no errors. Please give particulars regarding compiler version, operating system, and the compiler options used to build and run.

[fortran]PROGRAM XYZ
CALL METH
END

SUBROUTINE METH()
IMPLICIT NONE
CHARACTER(len=20) :: A
CHARACTER(len=20) :: B

A = "Azerty"
B = "Ytreza"
CALL APPMETH(A,B)

END

SUBROUTINE APPMETH(C,D)
IMPLICIT NONE
CHARACTER(len=20) :: C
CHARACTER(len=20) :: D

print *,C
print *,D

END

[/fortran]
0 Kudos
gwen06
Beginner
1,780 Views

Hi mecej4,

I have tested these lignes, that it is to say to put all the lines in the same file and it's run correctly.

The problem is that I used Microsoft Visual 2005 and Intel Fortran Compiler and when the same contain is put in two separated files, it does not run.

I have the good result in one single file and an unexpected behaviour when the same lines are put in two files (the first argument is correctly written and the second one is incorrect and produce the error message).

Does anybody know what are the options I need to correct ?
Is there something to change in the options ?

Best Regards,

0 Kudos
Lorri_M_Intel
Employee
1,780 Views
Are both source files compiled the same way?Is one compiled with /iface:cvf perhaps, but the other one is not?

Really, we need to know what command line options you are using, and what version of the compiler you are using. VS2005 covers several versions of Intel Fortran.

Regards,

--Lorri
0 Kudos
gwen06
Beginner
1,780 Views

Thanks a lot Lorri !!

You were completely right.
The two files were in two different Fortran Project.

One of them has used the 'calling convention' in the options :

CVF

And the second one :

C, REFERENCE

And that was the origin of this problem !!

Now I used the same 'calling convention' and the result are the expected ones.

Could you just describe me what does this 'calling convention' correspond ?
Is one this option 'better' than the other one ?

Thanks,

Gwen

0 Kudos
mecej4
Honored Contributor III
1,780 Views
It is almost impossible to describe calling conventions without descending to the machine level and describe calling conventions in terms of

(i) registers: are arguments passed in registers? How many, and in what order? Are some registers required to be restored before returning?

(ii) stack: on X86 and X64 architectures, the number of logical registers in user code is 8 or 16 integers, and 8/16/... in the FPU. When subroutines and functions have many arguments, it is not possible to pass all arguments through registers, and some or all of the arguments are passed on the stack. The caller pushes some or all arguments on the stack. The called subroutine has to know where to find the arguments, and whether it should clean up the stack before returning, or if the caller itself will clean up the stack.

(iii) hidden arguments for string lengths, descriptors

From your point of view, at least at this stage it should be enough to know that a consistent calling sequence should be used. Let the defaults work, and do not use the /iface:CVF or other such options at all. Later, when you need to use object libraries that were built with a different calling convention and you do not have access to the source codes, you can learn about mixing calling conventions.
0 Kudos
John_B__Walter
Beginner
1,780 Views
There are some other options that you want to watch as well, to make sure to have consistency between
your files used for the same project.

Like Structure Member Alignment under Data, if you're passing a structure.

This type of error can result in the linker telling you there is an unsatisfied external (missing subroutine) when you know its not missing. That's because it looks different to the linker if the subroutine arguments are different. Or it can result in the receiving routine getting garbled data.

It's helpful to use the same options for all your sources to minimize these surprises.
0 Kudos
Reply