Note: links to SPEC CPU2006 documents on this web page assume that you are reading the page from a
directory that also contains the other SPEC CPU2006 documents. If by some chance you are reading this web page from a
location where the links do not work, try accessing the referenced documents at one of the following locations:

The $SPEC/Docs/ (Unix) or %SPEC%\Docs\
(Windows) directory on a system where SPEC CPU2006 has been installed.

The Docs/ directory on your SPEC CPU2006 distribution media.

Introduction

This document describes various useful utilities that ship with SPEC CPU2006. It is assumed that you have already read runspec.html and config.html.

On Windows Systems

Most of the examples in this document have been written in Unix syntax. That means you'll need to use your
imagination just a bit as you read this document:

If you see:

Just pretend you saw:

cat

type

cp

copy

diff

fc

grep

findstr

ls

dir

/

\

$SPEC

%spec%

configpp

"configpp" is a short way to say:

$ runspec --action configpp

That switch is mentioned in runspec.html but you'll find much more
about the config file preprocessor in config.html. The configuration file
is specified using the --config switch, or -c for short, at the command line. For example, the following two
command are equivalent:

The preprocessed configuration file will be dumped to stdout. But the normal progress output from runspec also
goes to stdout, so the config file output will be delimited by two lines of hyphens.

There's no need to specify benchmarks to run.

As always, if you don't explicitly specify a config file via '-c <filename>', then the file
default.cfg will be used.

The configpp utility is a good way to check your configuration file for fatal errors, as the config file is
completely parsed before it's output.

(History: The configpp utility was added in SPEC CPU2006 V1.0.)

convert_to_development

The "convert_to_development" utility removes various safety checks that ensure that benchmark code, data, and tools
haven't been modified. This utility is useful if you are pursuing experimental changes that you would like to try out while
still continuing to use the SPEC tool harness. For example, you might want to add your own performance instrumentation code,
add some debugging code, or try out a modified workload.

Benchmark binaries built in one type of tree (reportable or development) cannot be used in the other type unless you set check_md5=0. Note that even in a development tree, the default for check_md5 remains 1.

Warning 1: If you use this utility, you will permanently render the current SPEC
directory tree incapable of doing reportable runs. If you are doing both development work and
reportable runs, install the suite twice in two different directory trees (for example, on different disks).

Warning 2: Because benchmark binaries built in a reportable tree
cannot be used in a development tree (unless you set check_md5=0), care should be taken to avoid
accidental deletion and rebuilding of benchmark binaries. Consider the following scenario, where the user only wanted to try
changing input files from the workload of 403.gcc:

Unless myconfig.cfg contains check_md5=0, the
effect of the above command will be to immediately rebuild 403.gcc, which probably isn't your
intent if you are only studying the effects of workload modifications for 403.gcc.

(History: The convert_to_development utility was added in SPEC CPU2006 V1.1.)

dumpsrcalt

SPEC distributes approved source changes in packages referred to as src.alts, which are applied using the config file src.alt option. In config.html, you will also find an example showing what happens when one is applied.

The dumpsrcalt tool allows you to find out what's in a src.alt without necessarily having to apply it.

dumpsrcalt takes a packaged src.alt, an installed src.alt, or just the src.alt description file
(srcalt.pm) and outputs the source changes as a unified diff file, which shows "-" for lines that are
removed and "+" for lines that are added.

A src.alt package may also contain whole new files. In fact, all will contain at least one, as the presence of a "README"
file is enforced by makesrcalt. The new files will also be printed, if they are available.

dumpsrcalt's command-line options control which parts of the src.alt are output. By default all information
known about a src.alt is printed. This includes a summary with the name of the src.alt, the benchmark to which it applies,
the versions of CPU2006 with which it may be used, and a count of new and changed files.

Here are the contents of the src.alt created in the example for makesrcalt:

Notice that the output from dumpsrcalt is suitable for use as input to many patch (1) programs,
available on Unix systems and in some add-on packages for Windows (e.g. Cygwin). If you try to apply the output of
dumpsrcalt yourself, take care to notice how paths are handled by your patch program, especially if the src.alt is
for a benchmark that has a complicated source tree. Many patch programs will pay attention to the filename but not the path
listed on the "Index:" lines, so it may be best to apply them using the "-p1" option, to cause patch to ignore
"Index:" lines and use the full paths of the files as listed in the diff.

dumpsrcalt's command-line options are intended to be self-explanatory:

$ dumpsrcalt --help
Usage: bin/dumpsrcalt [options] <benchmark> <srcaltname>
bin/dumpsrcalt [options] <path to srcalt tarball>
bin/dumpsrcalt [options] <path to srcalt.pm>
Options:
--skip-changed -- Do not output diffs of files that have changed
--skip-new -- Do not output diffs for new files
--summarize -- Do not output any diffs at all
--no-summary -- Do not output the summary for the src.alt
<benchmark> must be the full nnn.name form
<srcaltname> must match the name of the subdirectory in the benchmark's
src.alt directory

(History: The dumpsrcalt utility was added in SPEC CPU2006 V1.1.)

extract_config

If you have a rawfile, you can extract the config file that was used with it. To do so, use the extract_config
utility.

For example, starting with a freshly-installed SPEC CPU2006 directory tree:

On Windows systems

Instead of saying diff just above, you would say fc (and, as already mentioned,
dir is the Windows spelling for what Unix calls ls.)

extract_flags

If you have a rawfile, you can extract the XML flags description file that the result uses. To do so, use
extract_flags. Usage is similar to extract_raw, but unlike extract_raw, the extract_flags utility might not produce a
flags description file identical to the original flags file. This is because EOLs (end-of-line) characters are normalized to
Unix-style LF (line feed) only.

Note: If you have used a flags description file to format your result, the entire flags file is stored in
the raw file (not just the part needed for result).

For example, continuing the example from extract_raw, you can extract the flags file using the
following command:

We see no difference between the extracted flags description file and the original. Notice that the above command asked for
the flags to be written to standard out; without that switch, they would have been written to whatever filename was suggested.

If you'd like for the filename of the extracted flags file to match the rawfile, use the --nofilename option.
This will cause extract_flags to ignore the flag file's "suggested filename":

(History: as of SPEC CPU2006 V1.1) You can format a result with multiple flags files. If
you used multiple flags files as input to runspec then you will get multiple flags files when running
extract_flags.

In the above example, we begin by copying the original rawfile (always recommended anytime you use commands that create
new rawfiles). The rawformat command takes new as input and produces
as output both new.html and new.rsf. We copy only new.html to a newly created directory, where we demonstrate that extract_raw can create a copy of new.rsf that is identical to the copy in
the parent directory.

On Windows systems

Note that the file you extract from can be PDF, PostScript, or HTML, just as on Unix systems, with one important
exception: if you are using a browser that attempts to add value to the HTML when you save it, that browser may break the
embedded rawfile. For example, with Internet Explorer Version 5.00.3103.1000, if you are viewing a SPEC CPU2006 html file
and you select File -> Save As, the default for "Save as type" is
shown as

"Web Page, complete (*.htm,*.html)"

Do not accept that default if you want to be able to retrieve the rawfile later on. If you take the default,
your saved file will be incomplete. To save the web page INCLUDING the embedded rawfile, you must
change "Save as type" to

"Web Page, HTML only (*.htm,*.html)"

flag_dump

(You can also invoke this utility with the spelling: 'flags_dump')

If you have an XML flag description file, such as one extracted using extract_flags, or one
downloaded from SPEC, flag_dump will create a more
human-readable HTML version from it. The flag_dump utility will also handle more than one XML flag description at a
time.

If you are writing a flags file, you should validate that the dump is valid HTML. If it isn't, you
probably made a mistake in the HTML text that you have included inside your XML flags file. A handy HTML validator can be found
at http://validator.w3.org/.

Note that flag_dump utility assumes that you are formatting flags files written by users. These files are not
allowed to contain mandatory flags. If you attempt to use the flag_dump utility to format any of the
suite-provided flag files such as flags_mandatory.xml or the benchmark flag files that reside in
$SPEC/benchspec/CPU2006/*/Spec/ directory, the utility will exit with an error message such as the one below.

% cd $SPEC/benchspec
% flag_dump flags_mandatory.xml
Processing flags_mandatory.xml...
ERROR: The flag file at
flags_mandatory.xml
contains one or more flags in the class "mandatory", which is not
allowed.
%

(History: The flag_dump utility was added in SPEC CPU2006 V1.0.)

go (Unix only)

When you source the shrc, as described in runspec.html, the 'go' shell alias is created. go is a handy utility to
navigate the directory structure of a SPEC source tree. Here are the various things it understands and the places they will take
you:

If you say

You'll end up in

go
go top

$SPEC

go bin

$SPEC/bin (where the tools live)

go config

$SPEC/config

go result
go results

$SPEC/result

go doc
go docs

$SPEC/Docs

go cpu

$SPEC/benchspec/CPU2006

go benchmark

The top level directory for the named benchmark, if it can be
found. (Examples follow)

go 401

$SPEC/benchspec/CPU2006/401.bzip2

go perlb

$SPEC/benchspec/CPU2006/400.perlbench Notice
that abbreviated names are accepted. But if the abbreviation is
ambiguous, the command will pick the first match, so pay attention
to the reply:

The named subdirectory of the directory tree for the
referenced benchmark, for example "go perlb
run". You can also name more than one level of subdirectory: "go 462 data train". (History: The
go alias existed in SPEC CPU2000, but for SPEC CPU2006 the order is new when
naming subdirectories, as is the ability to name more than one level of
subdirectory.)

go subdir

If you are already in a benchmark subtree, then you can
move to a different branch of the same benchmark, by naming the branch and
not mentioning a benchmark. For example:

go also understands -h and --help, and will output a short usage message in response to either of those arguments.

Note: If you leave the shell where you sourced shrc, the alias is no longer
available! So if you want to use this alias, do not start a sub-shell.

Note: 'go' does not know about your settings for output_root or expid, and will not be able to
take you to your run, exe, or result directories if you use those features. See ogo for something that can
help.

Users of shells compatible with csh

(History: since the release of SPEC CPU2006 V1.0,) If you use a csh-like
shell, please note that after you say source cshrc, there is a go alias that is set up
for you, which implements the same features as described above.

Windows Users

Sorry, the go feature does not exist for Windows systems.

index (UNSUPPORTED)

As you are preparing sets of results, you might find it handy to use scripts.misc/index. This
script is NOT supported - please do not submit bug reports for it. But you're welcome to try it out, like so:

In the above example, we have a couple rawfiles in a directory, generate html reports for them, and then add an
index.

makesrcalt

SPEC distributes approved source changes in packages referred to as src.alts, which are applied using the config file src.alt option. (The file config.html also has an example showing what happens when one is applied.)

A src.alt is a specialized difference file, and can't be made by hand. When you need to package some source changes,
makesrcalt is the tool you need.

If you are a developer and you believe that changes are needed to the SPEC source code, it will probably be convenient to work
in a sandbox, temporarily abandoning the tools during your development
phase. (Or, you can use convert_to_development to make the whole installation
into one big sandbox.) Once you have a pretty good idea of the changes that you want:

Create a subdirectory under the benchmark's src/ directory named "src.alt/".

Decide on a name for your src.alt. The src.alt name may contain only letters, digits, and underscores. For
convenience, it should be short. Create a subdirectory under src/src.alt/ using the name you have
chosen.

In that subdirectory, deposit any modified or new source files for the benchmark.

You must also put a file named "README" in that subdirectory. Its contents are up to you; to see examples of the kind of
information that is usually placed in README files, see www.spec.org/cpu2006/src.alt. In your draft, kindly do NOT claim that it is
approved; the release manager will do that at the last minute.

Once the directory structure is set up, creation of the src.alt package is simple: just type makesrcalt followed by the name of the benchmark and the src.alt name.

Example: We've made source changes to 403.gcc to remove preprocessor #line directives from the
c-parse.c source file. This src.alt will be called 'no_line':

$ makesrcalt 403.gcc no_line
Making 'no_line' src.alt for 403.gcc
This will be usable with version 1.2 of the suite.
Making differences and computing checksums...
Writing control file...
Gathering files...
Wrote /spec/cpu2006/403.gcc.no_line.cpu2006.v1.2.tar.xz
Finished making 'no_line' src.alt for 403.gcc. Elapsed time: 0 seconds
$

If you use --help, you'll get an up-to-date list of options. Usually, you won't need any of
these:

$ makesrcalt --help
Usage: bin/makesrcalt [options] <benchmark> <srcaltname>
Options:
--usewith <min>:<max> -- Set the versions of the suite that will accept
this src.alt (defaults to 1.1)
--notarball -- Skip packaging the src.alt as a tarball (created
by default)
--context <lines> -- Set lines of context for the diff. This defaults
to 3 and should not be changed.
--help -- Print this message
<benchmark> must be the full nnn.name form
<srcaltname> must match the name of the subdirectory in the benchmark's
src.alt directory
$

(History: the makesrcalt utility was improved in, and was documented for the first time with, SPEC
CPU2006 V1.1.)

ogo (Unix only)

When you source shrc, as described in runspec.html, the
'ogo' shell alias is created. Its function is similar to the go alias with one important difference: if
you use the output_root setting in your config file (also discussed in runspec.html) you can use ogo as a shorthand for moving around both
the original installed benchmark tree and your output tree.

To do so, simply set the GO environment variable to the same value as your output_root. Then,
'ogo' will use the contents of that variable as the top level of the benchmark tree when looking for run directories
and results.

Note the helpful message that tells you which directory you have landed in. (If you define the environment variable OGO_NO_WARN the message will be shorter - the first line "Using
value in GO..." will not be output.)

In this example, the benchmarks are installed in "/spec", and output_root is set to
"/cds_stuff" in the config file. Any runs using that config file will write their results, executables, and run
directories under "/cds_stuff". Continuing with other examples:

If you say

You'll end up in

ogoogo top

/cds_stuffYour own private output tree

ogo result

/cds_stuff/resultYour own private result directory

ogo 400 run

/cds_stuff/benchspec/CPU2006/400.perlbench/runYour own private run directories

/spec/DocsThere's only one Docs directory,
on the original installed $SPEC tree

ogo config

/spec/configThe config directory is always on the original installed tree; set its protections as described in runspec.html

ogo 400 src

/spec/benchspec/CPU2006/400.perlbench/srcRun directories are under output_root, but the benchmark
src directory is still in the original installed $SPEC tree.

ogo also understands -h and --help, and will output a short usage message in response to either of those arguments.

(History: since SPEC CPU2006 V1.1,) Saying ogo top or just ogo takes you to $GO. It used to take you to $SPEC.

Note: It's not necessary to export the "GO" variable. Declaring this variable at the command-prompt is
sufficient.

$ GO=/tmp/cds
$ echo $GO
/tmp/cds

(History: The ogo alias was added in SPEC CPU2006 V1.0.)

Users of shells compatible with csh

ogo has also been implemented for cshrc. There is one restriction: to get the full
feature set above, you must set OGO to the actual directory, not to a symbolic link.

Windows Users

Sorry, the ogo feature does not exist for Windows systems.

port_progress

The port_progress utility analyzes log files and summarizes errors. It was primarily used
during the benchmark porting phase for SPEC CPU2006, but can still come in handy, for example when trying the benchmarks with
a new compiler. To use it:

User john has asked for a summary of logs that used config files that match "dec2".

Te, Tr, and Ref indicate the Test,
Train, and Ref workloads.

In the first line of the table, the benchmark 400.perlbench is reported as successful ("S") for all 6 tests (base tuning/peak tuning, test/train/ref).

A few lines down, 410.bwaves succeeded for the test workload with base tuning, but no
information is available about the other 5 tests. The code "b?" indicates that there was at least
one build attempt for a benchmark, but it was not recorded as Successful, nor was it recorded as having a run-time
error.

The next line, 416.gamess, is blank because that benchmark was not attempted at all with
config file dec22a.cfg.

Benchmark 464.h264ref has a code "r?" for the Reference workload
with the base tuning, indicating a run-time failure. Additional information about that failure is at the bottom of the
report: the problem happened in log number 79, which used a runspec command that included the
switches listed (--define OUTDISK=/export/bmk/john/out/ -c dec22a --reportable -r int).

New with CPU2006 V1.2, you can remove reporting on base runs with --nobase or remove peak with --nopeak. This option may be convenient if,
at a particular moment, you are only debugging one type of output.

printkids.pl

Some benchmark executables are invoked multiple times. If you'd like to know how much time was spent on each invocation,
it may not be easy to tell. You could examine "speccmds.out", but that file is not easy to interpret:

printpath.pl

As a convenience for Windows users, you can use printpath.pl to print your path in an easier to read form. You
can send the output to a file, which can then be easily edited.

In the example below, printpath.pl makes it easy to notice that cygwin (a Windows/Unix compatibility product)
is in the path. SPEC recommends that your %PATH% should not include Windows/Unix compatibility products, because these
have sometimes contributed to hard-to-diagnose errors.

In the example above, to remove cygwin, the user just uses notepad to remove the second last line of the
file my-easy-to-edit-pathset.bat

rawformat

"rawformat" is the result formatter. It can be invoked directly, by typing rawformat, or
equivalently by typing runspec --rawformat. These two commands achieve the
same effect because, saying runspec --rawformat just causes runspec to
exit, invoking rawformat in its stead, and passing the formatter whatever other options you mentioned
on the command line.

The rawformat utility is also automatically invoked by runspec at
the end of a run, to generate the reports from your run.

For convenience, most rawformat options are documented in runspec.html, which see for basic information on using this command. You can also say rawformat --help to get a list of switches that are used by the formatter.

Note that when runnng rawformat, you will always get format "Submission Check", which
encourages consistent formatting for various result fields when preparing final (submittable) reports. In addition, you will
get the formats that you mention on the command line, or, if none are mentioned there, then you will get the defaults
documented under output_format. (History: the
automatic addition of subcheck to the list of outputs was added in SPEC CPU2006 V1.1)

A few additional points are worth mentioning, in the following sections.

Editing result description fields

A result rawfile may be edited to update reader fields, such as the system description. Rawfile syntax is similar to the
syntax in config files, with a few exceptions:

config files use equal signs; rawfiles use colons

the benchmark name is prepended to field names

rawfiles may not be edited beyond a certain point

rawfiles have stricter rules for field continuation

rawfiles allow two fields, sw_parallel_defeat and test_date, which are not allowed in config files

These points are described in this section.

WARNING: Before you do anything, make a backup copy of the rawfile first!

Example: What do you do when Marketing decides to change the name from "SuperHero 4" to
"SuperHero IV" just before you publish the results, or just before you're ready to submit them to SPEC? In your config
file, you had

hw_model = SuperHero 4

which has caused the rawfile to contain the line

spec.cpu2006.hw_model: SuperHero 4

and you've just been told that the name is wrong. You don't have time to re-run your test. It's too
late to change the config file.

SPEC does allow you to edit the rawfile to make corrections. Just make sure that you only edit the fields located
before the "fence":

About continuation fields in rawfiles

Notice when editing fields that have more than one line that you need to construct the numbers with correct
syntax. The syntax in the rawfile is a bit more picky than in config files (compare the following vs. the config.html section on "Field scoping and continuation". You cannot say something like
this:

When the tests were run. (History: As of SPEC CPU2006 V1.1,) Tthis
field is populated automatically based on the clock in the system under test. Setting this in the config file will
generate a warning and the setting will be ignored. If your system clock is incorrect, then the value may be edited in
the raw file. It's better to avoid the necessity to edit, by setting your system clock properly.

How do you generate a SPECrate result from a SPECspeed result? (or vice-versa)

To generate a 1-copy SPECrate result from a SPECspeed run, copy the original rawfile to another location, and use
rawformat to both generate the new rawfile and whatever other reports you want. For example:

Notice above that the round trip is complete: the original report, from run 383, matches backagain.txt in all but the time that the formatter was run.

You cannot format a multi-copy SPECrate run as a SPECspeed run; only a single-copy run.

Also notice above that output format "Submission Check" (aka subcheck) was automatically selected. This is because rawformat
is often used to check raw file edits for results that are to be submitted to SPEC for publication.

On Windows systems

You may find that --output_format will only accept one argument at a time. If so,
first create the rawfile with --output_format raw, then use the new rawfile to create the
other reports.

relocate (Unix only)

If you rearrange mount points or rename your SPEC root directory, you will probably find confusing problems like the one
in the example that follows. We used to have a working SPEC tree under /cpu2006/cpu2006-kit91, but we're going to
change that:

Limitations: There are some limitations to this tool. Most notably, it uses perl, so if the tree has
been re-arranged in such a way that perl has an identity crisis and can't find itself, you'll be in trouble. Make sure that
you have sourced shrc, as in the next example; if it still fails, you may need to reinstall the CPU2006 kit.

Important: delete the old run and build directories. When setting up run directories, the tools read
benchspec/CPU2006/nnn.benchmark/run/list to see what directories already exist. (A similar
method is used for build directories.) If the list contains references to directories that are
not underneath the current top, the intended behavior is that such directories should cause a warning, and should not be
used. For example:

Notice: Unusable path detected in run directory list file.
/brian/liberator/cpu2006/benchspec/CPU2006/998.specrand/run/list
references one or more paths which will be ignored, because they are
not subdirectories of this run directory. This condition may be a
result of having moved your SPEC benchmark tree. If that's what happened,
and if you don't need the old run directories, you can just remove
them, along with the list file. (Usually it's safe to delete old
run directories, as they are automatically re-created when needed.)

Unfortunately, it is sometimes possible to confuse the tools when the list contains directories that are not underneath
$SPEC. Although the above message is printed, the tools can actually end up using a mixture of
old and new directory paths, and nothing good can come of such mixtures. To avoid the confusion, you should delete the old
run directories right after the relocate. Old build directories should be deleted (perhaps after backing them up if you wish
to save them for reference). For example:

specdiff

In order to decide whether your system got the correct answer for a benchmark, runspec writes a file called
compare.cmd in the run directory, and then calls specinvoke, which calls specdiff. (The
specinvoke utility is described below.)

Suppose that your results are flagged as incorrect, but you'd like to have more detail. You could ask for more than 10 lines
of detail by changing the config file's default for difflines from 10 to
something else, and re-running the experiment. But, you might save a lot of time and avoid the re-run of the experiment, by
calling specdiff directly, with a different number of lines for its switch -l.

For example, a file chock-full of wrong answers for 444.namd has been created by hand. First, let's see how
specdiff would normally be run (line wraps added for readability):

The above says that normally we test for correct answers by comparing the file $SPEC/benchspec/CPU2006/444.namd/data/test/output/namd.out versus the file namd.out in the current directory. Normally, 10 lines of detail are printed. Let's change that to 15
lines, and compare versus our intentionally wrong file instead:

Changed (fixed) in V1.2: The specdiff program, as of CPU2006 V1.2,
removes previous outputs prior to running. For CPU2006 V1.0 and V1.1, you needed to remove previous outputs by hand before
your run in order to avoid confusion from output files (e.g. .mis) that were hanging around from earlier runs.

specinvoke

In order to run a benchmark, runspec writes a series of commands in the run directory, in the file
speccmds.cmd. These commands are then interpreted by specinvoke.

When something goes wrong, it is often useful to try the commands by hand. Ask specinvoke what it did, by using
the "-n" switch:

The -q and -k switches above are new with CPU2006 1.2.
They may be useful if specinvoke is being used separately as part of a benchmark development or debug effort (see runspec-avoidance.html.)

specinvoke -nn prints (but does not set) the environment

New with CPU2006 V1.2, the output of specinvoke -nn is expanded. It
now includes information about environment variables that were set by the tools prior to the invocation, which may come in
very handy if you want to run a benchmark outside the SPEC harness, for example, during a debugging or tuning effort.

Consider the following example, where OMP_NUM_THREADS is set prior to doing a (fake) invocation of runspec:

In the example above, an environment variable is set to request 1024 threads, and the setting is recorded in
speccmds.cmd. When specinvoke -nn is used, the setting is printed, along with an
export command that would put the setting into the environment (along with various other variables that the tools
noticed in the original environment).

It is important to understand that specinvoke does not actually set any environment variables for
you. Consider this simplified test case:

In the example above, the echo command prints nothing for the environment variable, despite the presence of
-E MY_IMPORTANT_ENV_SETTING enabled in the command file. So, one might ask, what good is the
feature? Well, it's very useful, if you just redirect the output of specinvoke -nn to a file, as
is commonly done:

A great convenience of the CPU2006 suite is the fact that you can now proceed to play with all the files in this run
directory, to prototype different changes and try out ideas, without fear that you will break anything. As long as you
confine your edits to (in this example) $SPEC/benchspec/CPU2006/437.leslie3d/run/build_base_silly.0000, you are in
a private sandbox and will not harm the original sources.

specrxp

To check XML flags files, runspec uses specrxp, which is
simply RXP under a unique name to ensure no possible
conflicts with other versions of rxp on your system. RXP is a validating XML parser. If your flags file passes RXP's tests, that
doesn't mean that the flags file makes sense, but it's a start.

You don't have to know anything abour specrxp, as it is called automatically. But if you want to, you can call it
directly, for example:

specrxp -V -s myflags.xml

The -V switch requests validation, and -s requests that all output be suppressed except error
messages.

Warning: Be sure to change it back to the correct location prior to attempting to submit a result
to SPEC, because SPEC probably does not have access to /Arques/Site/Lab/, and the submission handler will probably
bounce your submission.

If you get unexpected errors from specrxp:

If you get unexpected messages such as:

Warning: Start tag for undeclared element

check that you have correctly set the dtd version.

New: as of SPEC CPU2006
V1.2, please note that the dtd version is now cpuflags2.dtd, not cpuflags1.dtd.

(History: The specrxp utility was added in SPEC CPU2006 V1.1)

spectar

The utility spectar is simply GNU tar, built under a known set of circumstances at the same time as other tools
in the SPEC toolset, and renamed to avoid conflicts with any other versions of the program on your path. GNU tar, unlike
some other archiving programs, correctly handles very long path names.

specxz

The utility specxz is XZ Utils, built under a known set of circumstances at the same time as other tools in the
SPEC toolset, and renamed to avoid conflicts with any other versions of the program on your path.

Commonly-used switches work analogously to those in other compression utilities, such as -d to decompress. For
details, say specxz --help

Inclusion of specxz is new with CPU2006 V1.2. Switching compression programs has reduced the
size of SPEC distribution media. If you have written scripts that rely on specbzip2, it will be necessary to either
retain a copy of specbzip2 from your V1.1 kit, or to change your scripts to specxz. If you make the
change, you will also probably notice that specxz produces smaller files.

Warning: this idiom, commonly used on Unix systems, has been observed to fail on some tested
Windows systems:

specxz -dc mumble.tar.xz | spectar -xf - <-- may fail on Windows

If you see failures, break it into two commands.

specxz -d mumble.tar.xz <-- an alternative
spectar -xf mumble.tar

toolsver

If you have a rawfile, you can get information about the binary toolset and the versions of all of the system-independent
tools files. To do so, use the toolsver utility.

For example, starting with a freshly-installed SPEC CPU2006 directory tree: