- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
They are displayed as Fortran. INTEGER(4), CHARACTER(80), etc.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I never saw the code at all - sorry for the confusion.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Steve - has this been fixed in some version?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
No - I have pinged the developer and asked for status.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page