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

Debug Watch on a typed argument gives bogus(?) member names

chris-sn
Beginner
1,039 Views
I have some FORTRAN code in a static library, which is being called from a C++ DLL.

One of the external subroutines is like this:

subroutine InControl(cstruct) BIND(C,name='InControl')
INCLUDE 'link_fnl_static.h'
USE, INTRINSIC :: ISO_C_BINDING
use ModControl
implicit none

TYPE, BIND(C) :: MYFTYPE
logical(C_BOOL) :: c_fFinalStd
logical(C_BOOL) :: c_fSmartRunin
integer(C_INT) :: c_iCavitation
integer(C_INT) :: c_mIteration
integer(C_INT):: c_iEquationT(4)
integer(C_INT) :: c_iAccuracy
real(C_DOUBLE):: c_GridFactor
real(C_DOUBLE):: c_ToleranceA(5)
real(C_DOUBLE) :: c_ToleranceR(5)
real(C_DOUBLE):: c_ToleranceF
real(C_DOUBLE) :: c_ToleranceT
real(C_DOUBLE) :: c_Tfluid
character(kind = C_CHAR, LEN =32):: c_Fluid
END TYPE MYFTYPE

TYPE (MYFTYPE), intent(in) :: cstruct

fFinalStd = cstruct.c_fFinalStd
(more of the same)

This seems to be working, but if I look at cstruct in the debugger instead of seeing members like cstruct.c_fFinalStd I see this:

- cstruct {...} TYPE(MYFTYPE)
cstruct%C_TSTART
cstruct%C_TSTOP
cstruct%C_TSTARTG
cstruct%C_TSTOPG
cstruct%C_TSTEPG
cstruct%C_TSTEPT
cstruct%C_TSTEPF

Anyone know what's going on here?

0 Kudos
1 Solution
Steven_L_Intel1
Employee
1,039 Views
Just to let people know - this was indeed a bug in 11.1, but is already fixed for the next major release.

View solution in original post

0 Kudos
7 Replies
Steven_L_Intel1
Employee
1,039 Views
Can you provide a buildable and runnable test case that shows this behavior? The percent characters are correct - not dots - but the component names should be right.
0 Kudos
chris-sn
Beginner
1,039 Views
I've justspotted what has happened. I have two subroutines in different files,one of which begins as per my original post, and the other begins:

subroutine InTime(cstruct) BIND(C,name='InTime')

USE, INTRINSIC :: ISO_C_BINDING
use ModTime
implicit none

TYPE, BIND(C) :: MYFTYPE
real(C_DOUBLE):: c_TStart
real(C_DOUBLE):: c_TStop
real(C_DOUBLE) :: c_TStartG
real(C_DOUBLE):: c_TStopG
real(C_DOUBLE) :: c_TStepG
real(C_DOUBLE) :: c_TStepT
real(C_DOUBLE) :: c_TStepF
END TYPE MYFTYPE

TYPE (MYFTYPE) , intent(in) :: cstruct

When debugging within the original subroutine it seems to be picking up the type of cstruct from the other subroutine.

So it looks to melike either:
- The definition of MYTYPE is global, not local to the subroutine, but the compiler doesn't complain about the double definition
- The definition of MYTYPE is local to the subroutine, but the debugger is getting confused

Be grateful if you can confirm, and let me know if you still need a code example.

0 Kudos
Steven_L_Intel1
Employee
1,039 Views
I need an example. I suspect that you've missed something more.
0 Kudos
chris-sn
Beginner
1,039 Views
OKwill do, but it will take mea while to get rid of all the extraneous stuff. In the meantime renaming the type in one of the subroutines has made the problem go away.
0 Kudos
chris-sn
Beginner
1,039 Views
Steve I have a (fairly) small example for you, in case I have accidentally left some commercially sensitive name or comment in it I ought to supply it for your eyes only.

If I post here with a file attachement, and marking it private, will that do the trick?
0 Kudos
Steven_L_Intel1
Employee
1,039 Views
Yes, that works fine.
0 Kudos
Steven_L_Intel1
Employee
1,040 Views
Just to let people know - this was indeed a bug in 11.1, but is already fixed for the next major release.
0 Kudos
Reply