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:
$ ifort -debug -openmp -fpp -o openmp_sample openmp_sample.f90
$ . /opt/intel/inspector_xe_2011/inspxe-vars.sh
Copyright (C) 2009-2011 Intel Corporation. All rights reserved.
Intel® Inspector XE 2011 (build 147581)
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:
The last step of course launches Intel Inspector XE:
This first time in I'll construct a project to hold the inspection results, and set up that project to launch openmp_sample itself:
I’ll create the project in my source code directory:
I’ll call the project ompsample:
The only property I need to identify is the Application:
Then I’m ready to collect a result:
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.
The dials whirl, the machine runs, and the tool keeps updating its progress as the data are collected and post-processed:
eventually producing a result:
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.
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:
When I hit Create the rule is added to the list and the problem report is updated appropriately:
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:
To solve that I apply a second suppression directly to observation X3:
With both suppressions in place, I rerun the same inspector, now getting a different result:
(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:
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.