Analyzing Fortran Program Correctness on Linux* using Intel Parallel Studio XE

Intel® Parallel Composer 2011 XE contains sample programs for C, C++ and Fortran that can be used to learn the analysis tools included in Intel Parallel Studio 2011 XE.  This article will walk through the process of playing with Intel Inspector XE by making use of one of those sample codes.  First, let's find out what sample programs are available.  The default install location for Intel Composer XE is /opt/intel/, wherein a directory specific to the installed version will be created, and to which a set of symbolic links will be directed from /opt/intel/composerxe.  Visiting this latter directory, I follow the links through Samples/en_US/Fortran (outside the US your path may vary) to discover a collection of projects:
 

Fortran%20code%20samples

The directory "openmp_samples" is a tantalizing prospect for inspection, but we best not try to play with it here inside the install directory, where we may or may not have permission to create new files.  Instead, I'll copy the contents (a single file called openmp_sample.f90) into a directory inside my home directory (say, ~/projects/ompsample).

To compile this, using a bash shell, I first source the environment to let me run the compiler in my project directory:

[shell] . /opt/intel/composerxe/bin/compilervars.sh intel64[/shell]

(specifying the intel64 argument to indicate I want to use the 64-bit version of the compiler).  In the source file is the advice to use a couple switches for compiling it:

Sample%20compile%20and%20run


To prepare the program for inspection, I add one argument to the compile ("-debug") and also in my bash shell I source the script that will add Intel Inspector XE to my PATH:

[shell] [~/projects/ompsample] $ ifort -debug -openmp -fpp -o openmp_sample openmp_sample.f90 [~/projects/ompsample] $ . /opt/intel/inspector_xe_2011/inspxe-vars.sh Copyright (C) 2009-2011 Intel Corporation. All rights reserved. Intel® Inspector XE 2011 (build 147581) [~/projects/ompsample] $ inspxe-gui [/shell]


The last step of course launches Intel Inspector XE:

KB110509-03.png

This first time in I'll construct a project to hold the inspection results, and set up that project to launch openmp_sample itself:

KB110509-04.png

I’ll create the project in my source code directory:

Selecting%20project%20directory

I’ll call the project ompsample:

KB110509-06.png

The only property I need to identify is the Application:

KB110509-07.png

Then I’m ready to collect a result:

KB110509-08.png

From among the available analyses, I choose to locate deadlocks and data races and at this point all I need to do is hit Start.

KB110509-09.png

The dials whirl, the machine runs, and the tool keeps updating its progress as the data are collected and post-processed:

KB110509-10.png

eventually producing a result:

KB110509-11.png

And a surprising result it is. Intel Inspector XE appears to find a data race in the OpenMP directives used to parallelize the main loop in this sample. We’ve already analyzed this and discovered there really was a problem in the OpenMP runtime library, a race condition on a loop variable that should have been marked “private.” It is a benign race, all threads rushing to set the same, unchanging value for the suspect variable. While it is a bug in the compiler, it is not something that should cause any code to malfunction, and even this will be fixed in a future release.

KB110509-12.png


But since we're here, we might as well take advantage of this to show another feature of Intel Inspector XE, a way to tell the tool to ignore these signatures because we've already identified them, using a feature called private suppression.  In the window above I'll right-click over the first of the observations in this problem report:

Selecting the Suppress menu item produces a private suppression rule:

KB110509-13.png

When I hit Create the rule is added to the list and the problem report is updated appropriately:

KB110509-14.png

Please note: a little care must be taken here. Sometimes a problem set may require multiple rules in order to completely suppress it. Note that suppressing the first of the three observations marks out off second observation but not the third:

KB110509-15.png

To solve that I apply a second suppression directly to observation X3:

KB110509-16.png

With both suppressions in place, I rerun the same inspector, now getting a different result:

KB110509-17.png

(I’ve adjusted the placement of this text to save some space (normally centered in a large pane), but the text is what you should see.)

So this means I should take care to maintain my list of suppressions to remove the clutter that might obscure new observations representing meaningful errors in my code while selectively removing suppressions whose underlying problems have been fixed (either by user source changes or as the result of a tool/library update).   Intel Inspector XE provides such a place for managing suppressions, the table below that appears in the project properties:

KB110509-18.png

Intel® Inspector XE provides the features to discover bugs in memory and thread use for Fortran users as we have demonstrated here using one of the sample codes that ships with the compiler. Try it, on this or some other application.

Para obtener más información sobre las optimizaciones del compilador, consulte el aviso sobre la optimización.