- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This works,
This does not for R, allocated
More of the same
numR is 16384, which is a mistake as it is supposed to be a power of 2 and that is not, but it is definitely defined.
dum is an integer and is defined and I can see it in the code.
Any idea when we can expect a fix. DISLIN works with IFX but not really well with IFORT, so I do not want to go back.
I am using the old FORTRAN expedient of write(*,*) dum
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
1. "numR is 16384, which is a mistake as it is supposed to be a power of 2 and that is not, but it is definitely defined."
-- What? 16384 = 2^14
2. With declarations such as
character*100 name
statements such as
name = trim(name)
serve no useful purpose, since the expression on the right of '=', after trimming, is padded at the right with enough spaces to make the resulting string have the declared length of the variable on the left of '='.
3. I do not understand what you are reporting with all those screen shots. and what you mean by "works" or "does not work". Hopefully, somebody at Intel does.
4. In some of the Visual Studio local variable displays, I suspect some memory corruption because some of the numbers (with magnitudes below 1E-300) are implausible. For example, the value 1.581010066691989D-322 reported for FPI, written out in IEEE 64-bit hexadecimal form, is simply a single space character, Z'20'.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You are correct, I use two numbers 16384 and 51 times 16384 which is 835584, blame the lateness of the hour and not a great QA.
I have been looking at trim to see the impact, not used it before this last week.
Thanks for pointing out my errors.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Problems:
1. Sometimes one can see the whole of the array in the debugger as in the first shot with R, you see each individual value, useful for debugging.
2. In the second picture the array shows say XRAY(1:1) and an upper bound, to see any value I need to go to the watch window and plug in XRAY[1000] == one at a time, it is very slow.
3. In the last shot the debugger says the variable is not defined and yet it can be seen on the screen and prints out. I did a dummy variable just to show the problem twice.
We are told that after 2024 it will only be IFX, it would be hoped that these debugging issues are fixed.
They do not stop me, they just make debugging more like MS FORTRAN 3.03 from 1988 than IFORT from 2024.
I have no doubt the people these pictures were aimed at know exactly what I am talking about, it is merely registering a note that it is annoying, not soul destroying, just brings back our youth.
I know what causes it, no doubt Intel knows as well with the passing of allocated arrays, but the squeaky wheel etc....
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
and on FPI as an unassigned variable,
In this screen shot FPI has been assigned but its value as for AS to AS6 values have not been set. So most use the standard code of 20 that has been discussed in much earlier posts, but AS5 does not and if it is not set the symbol #DEN is attached, no idea what #DEN stands for; perhaps Intel could tell us?
The ETVECTOR shows the new method of providing I presume a pointer to the array as the hexadecimal code first. That may be useful, but no idea why for the average user.
once a value for FPI is assigned it turns into a real number and the DEN disappears. looking at namealpha I see what you meant by the issue with trim as I used it.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Bill Locals
Jane Locals
module Jill
contains
subroutine Jane(M, B)
integer :: M
! real :: B(M)
real :: B(:)
write(*,*) B(M)
!write(*,*) B(M+1)
end subroutine Jane
end module Jill
program fred
use Jill, only: Jane
real :: A(500)
a = 1.0
call bill(1, 100, A )
call Jane(100,A)
end program fred
subroutine bill(N, M, B)
integer :: N, M
real :: B(N:M)
write(*,*) B(M)
!write(*,*) B(M+1)
end subroutine bill
It would seem the IFX debugger integration only evaluates the array by default if you supply the array shape/size with an explicit interface as in subroutine Jane. In bill it has upper and lower bound identities (if you pass both) but only evaluates element one. This is quite different to IFORT and I would agree fully with John is a productivity problem with IFX. There are other issues with debugging in IFX that currently prevent me from using it other than for brief tests.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
#DEN is an abbreviation for "denormal", i.e., a real number that is less in magnitude than the smallest number that can be represented with full precision -- 2.2251D-308 for double precision, IEEE representation Z'0010000000000000'.
There are some compiler options that allow you to control the treatment of such numbers, such as "denormals-are-zero", "flush-to-zero", etc.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Now DEN makes sense - thanks - I was once placed on an IEEE committee for metric and then removed as I was not an EE, but I was friends with the Committee Chair for a long time.
I took the simple step of setting all variables to zero at creation, saves a lot of messing about.
Although I always set them before use - even if they are zero.
The & symbol circled in red is telling one the variables that are passed as arguments of some form.
The watch window will not load integers.
It would be nice if the watch window listed parameters if asked, sometimes you forget a parameter in a module that you have not used for a long time.
I had an interesting tussle with a variance calculation, IFX started to spit out negative values that took a while to sort out. Painful.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@JohnNichols, can you attach a simple reproducer and explain what is not what you expect? The debugger team can't work with screen shots -- too many guesses about what your app really does.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
John,
About 20 years ago I had a similar issue with an array showing up in the Debugger without the full dimensions.
The hack solution was to declare and define a pointer to the array (this can be in conditional code if you wish).
Now you could use ASSOCIATE. This may work for you.
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@Barbara_P_Intel , ok, I spent 40 minutes trying to make a short reproducer and it was a washout,
Here is a start of a program that I have been working on, it is a mess, but it is my mess. I am sorry but your people will need to install DISLIN, about 10 minutes work.
To run it simple enter a at the requested file name and it knows what to look for.
Put a debug break on
Anywhere above line 240 in the HAAR module and you will see this in the watch window, and then look in the other window and you can see them. They are defined as far as I can see. J and M are assigned as you can see in the code, and so is X.
This is from a debug break on line 229.
This is in IFX, I could not get DISLIN and IFORT TO PLAY NICE.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jim:
I was thinking this is a good idea, but it is a kludge and let us get Intel to do the right thing. @mecej4 used this method in the structural analysis suggestions he made many years ago, brilliant really.
I have been inside the program all morning and the only problem in this module is the lack of the variable pop up if I point to it.
I thought you might like this little observation
do i = m, m+100
It is a challenge to remember that this will loop 101 times, where as this will loop 100 times
do i = 1, 100
Stopped me for 30 seconds this morning as an array overflowed.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@JohnNichols, browsing through all the posts in this thread raised a doubt in my mind about how you were using the V.S. debugger and interpreting the contents of its numerous display windows, so I will express my suspicions in that regard.
Here is a screenshot of a trivial program, compiled with /Od /Zi, opened in VS. I placed a breakpoint on line 4, let the program run up to that breakpoint, and then executed one more statement, which placed the yellow arrow on line 5. This line has not yet been executed, so j and k have not yet been defined. However, line 4 has been executed, and that caused i to be defined with the value 1. I stress: the variables j and k have not yet been defined.
This state of affairs is not in agreement with what we see in the Locals window -- note the '0's displayed for j and k in the Locals window. Those '0's are garbage. Had more refined debugging options been used during compilation, the lines for j and k may well have said something such as 'undefined'.
I wish to stress that what is caused to be displayed in Locals and Watch windows, or by hovering the mouse pointer on a variable in a code window, etc., should not be taken literally without considering the current source line and knowing which source lines have already been executed. In a more complicated program, where control flow statements, subroutine calls and function references may be present as well, keeping track of which variable values displayed in a Locals or Watch window are valid is no trivial task, and it is easy to confuse oneself.
Program being "debugged"
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@mecej4 , yes I agree with your excellent point, one needs to be careful.
But the new debugger is quite sophisticated, just a bit anemic at times.
First, I always make sure I can printout the values I am looking for, before I complain about the debugger, one has to be sure the code is correctish and the execution is past the point you are concerned about.
Secondly, these are not all the time errors, which is why you start to see them in complex and deep programs, within a subroutine within a module that makes them annoying as they occur under some circumstances.
Intel knows what I am talking about, we are clearly in the process of development, as usual we are the pickets on the lookout for errors in the code, we make good, cheap effective pickets.
What I can say is I always enjoy your posts, so thank you again.
The most annoying error is the popup line that only shows some of the variables of interest, it is a bug not a feature.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@mecej4 the display you show indicates that the Fortran debugging support is not being loaded - note the "int" for the type. It should look like this:
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks, Steve.
I usually update the bare minimum components necessary to get the current version of the compiler and libraries, including MKL, functional. The VS integration, etc., is something I rarely use in my own work, so I may not be aware of how the VS displays appear to the average user who keeps the OneAPI-VS integration up to date.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This is one of the issues, you can see that RCTHETA pops up and tells you what is in the array, as do the other RC arrays, but at the moment nothing else as a variable will highlight if I point to it. This is in the module HAAR in the subroutine HAAR_ANALYSIS.
latest Fortran files attached
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
In the same subroutine, I have stopped on the last line at the call to graph, the arrays X and Y have an error, they are allocated, and assigned values in this module and the blue screen shows the correct output using the X and Y arrays, so the unspecified error is a mystery as I have not deallocated the arrays.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
yesterday in the same subroutine, CONST would pop up but nothing else on that line. I am sorry it is hard to see.
Also are the 0x................................. numbers going to stay - they are just this side of annoying unless there is a use I am missing.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
John, you also do not have the Fortran debugging feature installed/working - you're getting the default C support, which doesn't understand much Fortran stuff. In the past, what has generally worked has been to uninstall and reinstall Fortran. I will note your propensity to use "preview" versions of VS, in which case all bets are off.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
1. How do you tell if the feature is installed - does it show up in the VS about window?
2. No, this is an Intel NUC going into the field, it has only the stock standard Windows on it, the stock standard VS 2022 - with everything turned on and the latest oneapi - with all turned on
3. I am reinstalling it all and will await your advice on how to know about the debugging in Fortran is correctly installed.

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page