Cannot bind expression to breakpoint.

[tsimm3]

After upgrading to Intel FORTRAN 2013 and Visual Studio 2012 I cannot set breakpoints the same way that I used to.

I frequently want to set a conditional breakpoint where the condition is something like ‘A(I) .EQ. 0’. When I try it now I get the error message “Cannot bind expression to breakpoint”. I’ve also noticed that I cannot watch variables that are defined in a module without including the module name. For example, I used to be able to watch a variable named VAR and now I have to use MODULE_NAME::VAR in the watch window.

Are these issues related? And is there a compiler setting that will restore the previous operation?

[Steven_L_Intel1]

I wonder if you don't have the Fortran debug support loaded for some reason. When you view the Locals list of variables, are the types displayed as Fortran types or C types?

[tsimm3]

They are displayed as Fortran. INTEGER(4), CHARACTER(80), etc.

[Steven_L_Intel1]

When you say "used to", what were you using before?

The problem with using A(I) in an expression is that the debugger wants to convert that to an address at the time you set the breakpoint. It doesn't re-evaluate A(I) after each statement.

As for module variables, if you use the variable then you should be able to see it directly in the debugger. It works when I try it. Perhaps you can provide an example showing where it doesn't?

[tsimm3]

I've discovered that I only have the problem setting the conditional breakpoint using data that has been dynamically allocated. Here is a sample that shows the problem.

module mod1
integer :: i, x=5
integer, allocatable :: a(:), b(:)
end module

program test
use mod1
implicit none

allocate(a(100))
allocate(b(100))

do i = 1, 100
a(i) = i**2
b(i) = a(i) + 1
enddo

end

I attached a screenshot of the code window, the error message and the watch window.

[tsimm3]

I have set conditional breakpoints in this manner for several years using compilers going back to CVF at least. In recent years I’ve been using Intel Fortran compilers. I believe I’ve used versions 9 and 11 without experiencing this problem, although the process of setting conditional breakpoints does seem to change with each version.

I can exam variables from a module if they are used in the subroutine that I’m currently debugging, but have to use the module name to examine them if they are not used locally. I believe that in the past I could examine any variable in the module as long as the module was used by the subroutine.

I tried to post a message showing that the problem only occurs when I use dynamically allocated arrays, but I was told it was being reviewed before it could be posted. Possibly because I attached a file. Here is source code that demonstrates the problem when trying to set a conditional breakpoint 'a(i) .gt. 100'.

module mod1

  integer :: i, x=5

  integer, allocatable :: a(:), b(:)

end module

program test

use mod1

implicit none

allocate(a(100))

allocate(b(100))

do i = 1, 100

  a(i) = i**2            !can’t set a breakpoint conditional on a(i) .gt. 100

  b(i) = a(i) + 1

enddo

 end

[jimdempseyatthecove]

If you read Steve's statement: The problem with using A(I) in an expression is that the debugger wants to convert that to an address at the time you set the breakpoint. It doesn't re-evaluate A(I) after each statement.

You will see why you do not get the results you want.

This may be a good time to make a request for expression evaluation to be specifiable (programmers choice) as either a) at time of setting, or b) on each trip through code.

I can see a case for either.

Jim Dempsey

[Steven_L_Intel1]

This is probably not under our control. VS6 (used with CVF) was quite a bit different from VS2002 and later. In current versions of Visual Studio, you can set "data breakpoints" with conditions, but the thing you're watching has to be a fixed address. Here is what the dialog looks like:

For things like this, Microsoft doesn't give us control to add additional breakpoint types - all we can do is evaluate the expression passed to us and return an address when you establish the breakpoint.

[tsimm3]

That is the dialog box for a new breakpoint. I have used it, with inconsistent results, to break when a value changes.

To set a breakpoint when an array element takes on a certain value I use the Breakpoint Condition dialog box. I'm trying to attach a screenshot.

I realize the inconsistent behavior over the years could be caused by Visual Studio. I have found that it's easier to get information here than from Microsoft, so I was hoping it was a compiler issue.

[Steven_L_Intel1]

Ah - now that you showed some source I see...  The real problem is the use of the allocatable array. If it isn't an allocatable array, you can do this. I'll ask the developers if this can be resolved.

[tsimm3]

Yes, that's right. Here is simpler code that demonstrates the problem. I can set a conditional break 'c(i) .gt. 100' but cannot set 'b(i) .gt. 100'

program test

implicit none

integer i, x
integer, allocatable :: a(:), b(:)
integer c(100)

allocate(a(100))
allocate(b(100))
do i = 1, 100
a(i) = i**2
b(i) = a(i)
c(i) = a(i)
continue       !setting breakpoints on this line
enddo

end

[Steven_L_Intel1]

Yes, I have an even simpler program that shows this difference. I'll comment that again we have an example where a test program would have saved a lot of time and effort - simply describing what you think is the problem often leads us astray. Issue ID is DPD200247390.

[tsimm3]

Thanks. I'll remind you that I sent the sample code early this morning in the early stage of our communication. For some reason when I submitted it I received a message that it was being reviewed before it could be posted. I'm not sure when it appeared on the forum. Perhaps you didn't see it immediately. 

[Steven_L_Intel1]

I never saw the code at all - sorry for the confusion.

[tsimm3]

No problem. I didn't realize it was related to allocatable arrays until I developed the sample code. Next time I'll try to have sample code ready when I post the original question.

[dajum]

Steve - has this been fixed in some version?
 

[Steven_L_Intel1]

No - I have pinged the developer and asked for status.

[Steven_L_Intel1]

The developers now tell me that the Microsoft debugger interface has limitations that prevent us from resolving this issue. They will take it up with Microsoft but don't expect any solution to appear this year.