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

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

chris-sn
初學者
1,043 檢視
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 積分
1 解決方案
Steven_L_Intel1
1,043 檢視
Just to let people know - this was indeed a bug in 11.1, but is already fixed for the next major release.

在原始文章中檢視解決方案

7 回應
Steven_L_Intel1
1,043 檢視
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.
chris-sn
初學者
1,043 檢視
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.

Steven_L_Intel1
1,043 檢視
I need an example. I suspect that you've missed something more.
chris-sn
初學者
1,043 檢視
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.
chris-sn
初學者
1,043 檢視
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?
Steven_L_Intel1
1,043 檢視
Yes, that works fine.
Steven_L_Intel1
1,044 檢視
Just to let people know - this was indeed a bug in 11.1, but is already fixed for the next major release.
回覆