variable values in totalview don't match the value being printed?

[nickDS]

Hi,

I am using Intel Fortran compiler v10.1 and compiling only with the '-g' option. Inspection of some variables while stopped at a break point reveals that the value doesn't match the value that is printed to the screen. It appears that Totalview is displaying the incorrect value. For example, Totalview will list the value of 6.95, but the value printed to the screen is 7.31e-2. What are the reasons this would occur? Is there a way to fix this?

I've done 'make clean' and recompiled to ensure that all of the files were compiled with the -g option.

Thanks.

[PeterT-RogueWave]

Hello Nick,

The first question I would have is which version of TotalView are you using? We have seen problems like this in the past, but I think we have resolved most of them. The current version of TotalView is 8.6.2-2, so I would use that as a reference point. Usually, when we run into problems like this it comes down to either a lack of detail in the debug information, or TotalView not correctly interpreting the debug information. I don't see anything specific about Intel 101 in looking through our bug lists, but that doesn't mean there aren't any. Whether or not it's a debug info or a debugger problem, we're usually in the neighborhood of the variable, and if you can read the assembly (View->Source As->Both will show both Fortran and Assembler source) you can see where the value is actually being stored, and compare that to the address TotalView thinks it is. You can then adjust the address in the TotalView data window to match where the Fortran code actually thinks it is. It's not the best solution. but it might give you some idea.

If you are using 8.6.2-2, and the problem still persists, the best thing would be to get a test case to us. If the test case is not feasible, depending on proprietary code or such, I will say that we really only need the executable, not the source. Of course, if you can boil this down to a simple reproducer, that would be great, but I know that sometimes a small test case that replicates the code you are having problems with may not show the error, whereas the original code does. If neither executable or smal test case can be sent, would it be possible to send the debug information Assuming this is not a Mac, you can usually do a

readelf -w program >& debug_output

To capture the dwarf info. If you can narrow this down to a particular routine, we would just need the dwarf info from the .o file which contains that routine. If this is a Mac, the debug info is kept in the .o files, so that might be easier. Assuming it's all dwarf on the Mac.

If you need to go to the step of providing us with info to follow this up, please send it to support@totalviewtech.com, as the forum is not intended to be a place to report and resolve actual bugs.

Regards,