This is doc/gcc.info, produced by makeinfo version 4.0b from
doc/gcc.texi.

INFO-DIR-SECTION Programming
START-INFO-DIR-ENTRY
* gcc: (gcc).                  The GNU Compiler Collection.
END-INFO-DIR-ENTRY
   This file documents the use and the internals of the GNU compiler.


   Published by the Free Software Foundation
59 Temple Place - Suite 330
Boston, MA 02111-1307 USA


   Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
1999, 2000, 2001 Free Software Foundation, Inc.


   Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.1 or
any later version published by the Free Software Foundation; with the
Invariant Sections being "GNU General Public License" and "Funding Free
Software", the Front-Cover texts being (a) (see below), and with the
Back-Cover Texts being (b) (see below).  A copy of the license is
included in the section entitled "GNU Free Documentation License".

   (a) The FSF's Front-Cover Text is:

   A GNU Manual

   (b) The FSF's Back-Cover Text is:

   You have freedom to copy and modify this GNU Manual, like GNU
software.  Copies published by the Free Software Foundation raise
funds for GNU development.


File: gcc.info,  Node: Debugging Options,  Next: Optimize Options,  Prev: Warning Options,  Up: Invoking GCC

Options for Debugging Your Program or GCC
=========================================

   GCC has various special options that are used for debugging either
your program or GCC:

`-g'
     Produce debugging information in the operating system's native
     format (stabs, COFF, XCOFF, or DWARF).  GDB can work with this
     debugging information.

     On most systems that use stabs format, `-g' enables use of extra
     debugging information that only GDB can use; this extra information
     makes debugging work better in GDB but will probably make other
     debuggers crash or refuse to read the program.  If you want to
     control for certain whether to generate the extra information, use
     `-gstabs+', `-gstabs', `-gxcoff+', `-gxcoff', `-gdwarf-1+', or
     `-gdwarf-1' (see below).

     Unlike most other C compilers, GCC allows you to use `-g' with
     `-O'.  The shortcuts taken by optimized code may occasionally
     produce surprising results: some variables you declared may not
     exist at all; flow of control may briefly move where you did not
     expect it; some statements may not be executed because they
     compute constant results or their values were already at hand;
     some statements may execute in different places because they were
     moved out of loops.

     Nevertheless it proves possible to debug optimized output.  This
     makes it reasonable to use the optimizer for programs that might
     have bugs.

     The following options are useful when GCC is generated with the
     capability for more than one debugging format.

`-ggdb'
     Produce debugging information for use by GDB.  This means to use
     the most expressive format available (DWARF 2, stabs, or the
     native format if neither of those are supported), including GDB
     extensions if at all possible.

`-gstabs'
     Produce debugging information in stabs format (if that is
     supported), without GDB extensions.  This is the format used by
     DBX on most BSD systems.  On MIPS, Alpha and System V Release 4
     systems this option produces stabs debugging output which is not
     understood by DBX or SDB.  On System V Release 4 systems this
     option requires the GNU assembler.

`-gstabs+'
     Produce debugging information in stabs format (if that is
     supported), using GNU extensions understood only by the GNU
     debugger (GDB).  The use of these extensions is likely to make
     other debuggers crash or refuse to read the program.

`-gcoff'
     Produce debugging information in COFF format (if that is
     supported).  This is the format used by SDB on most System V
     systems prior to System V Release 4.

`-gxcoff'
     Produce debugging information in XCOFF format (if that is
     supported).  This is the format used by the DBX debugger on IBM
     RS/6000 systems.

`-gxcoff+'
     Produce debugging information in XCOFF format (if that is
     supported), using GNU extensions understood only by the GNU
     debugger (GDB).  The use of these extensions is likely to make
     other debuggers crash or refuse to read the program, and may cause
     assemblers other than the GNU assembler (GAS) to fail with an
     error.

`-gdwarf'
     Produce debugging information in DWARF version 1 format (if that is
     supported).  This is the format used by SDB on most System V
     Release 4 systems.

`-gdwarf+'
     Produce debugging information in DWARF version 1 format (if that is
     supported), using GNU extensions understood only by the GNU
     debugger (GDB).  The use of these extensions is likely to make
     other debuggers crash or refuse to read the program.

`-gdwarf-2'
     Produce debugging information in DWARF version 2 format (if that is
     supported).  This is the format used by DBX on IRIX 6.

`-gLEVEL'
`-ggdbLEVEL'
`-gstabsLEVEL'
`-gcoffLEVEL'
`-gxcoffLEVEL'
`-gdwarfLEVEL'
`-gdwarf-2LEVEL'
     Request debugging information and also use LEVEL to specify how
     much information.  The default level is 2.

     Level 1 produces minimal information, enough for making backtraces
     in parts of the program that you don't plan to debug.  This
     includes descriptions of functions and external variables, but no
     information about local variables and no line numbers.

     Level 3 includes extra information, such as all the macro
     definitions present in the program.  Some debuggers support macro
     expansion when you use `-g3'.

`-p'
     Generate extra code to write profile information suitable for the
     analysis program `prof'.  You must use this option when compiling
     the source files you want data about, and you must also use it when
     linking.

`-pg'
     Generate extra code to write profile information suitable for the
     analysis program `gprof'.  You must use this option when compiling
     the source files you want data about, and you must also use it when
     linking.

`-a'
     Generate extra code to write profile information for basic blocks,
     which will record the number of times each basic block is
     executed, the basic block start address, and the function name
     containing the basic block.  If `-g' is used, the line number and
     filename of the start of the basic block will also be recorded.
     If not overridden by the machine description, the default action is
     to append to the text file `bb.out'.

     This data could be analyzed by a program like `tcov'.  Note,
     however, that the format of the data is not what `tcov' expects.
     Eventually GNU `gprof' should be extended to process this data.

`-Q'
     Makes the compiler print out each function name as it is compiled,
     and print some statistics about each pass when it finishes.

`-ftime-report'
     Makes the compiler print some statistics about the time consumed
     by each pass when it finishes.

`-fmem-report'
     Makes the compiler print some statistics about permanent memory
     allocation when it finishes.

`-ax'
     Generate extra code to profile basic blocks.  Your executable will
     produce output that is a superset of that produced when `-a' is
     used.  Additional output is the source and target address of the
     basic blocks where a jump takes place, the number of times a jump
     is executed, and (optionally) the complete sequence of basic
     blocks being executed.  The output is appended to file `bb.out'.

     You can examine different profiling aspects without recompilation.
     Your executable will read a list of function names from file
     `bb.in'.  Profiling starts when a function on the list is entered
     and stops when that invocation is exited.  To exclude a function
     from profiling, prefix its name with `-'.  If a function name is
     not unique, you can disambiguate it by writing it in the form
     `/path/filename.d:functionname'.  Your executable will write the
     available paths and filenames in file `bb.out'.

     Several function names have a special meaning:
    `__bb_jumps__'
          Write source, target and frequency of jumps to file `bb.out'.

    `__bb_hidecall__'
          Exclude function calls from frequency count.

    `__bb_showret__'
          Include function returns in frequency count.

    `__bb_trace__'
          Write the sequence of basic blocks executed to file
          `bbtrace.gz'.  The file will be compressed using the program
          `gzip', which must exist in your `PATH'.  On systems without
          the `popen' function, the file will be named `bbtrace' and
          will not be compressed.  *Profiling for even a few seconds on
          these systems will produce a very large file.*  Note:
          `__bb_hidecall__' and `__bb_showret__' will not affect the
          sequence written to `bbtrace.gz'.

     Here's a short example using different profiling parameters in
     file `bb.in'.  Assume function `foo' consists of basic blocks 1
     and 2 and is called twice from block 3 of function `main'.  After
     the calls, block 3 transfers control to block 4 of `main'.

     With `__bb_trace__' and `main' contained in file `bb.in', the
     following sequence of blocks is written to file `bbtrace.gz': 0 3
     1 2 1 2 4.  The return from block 2 to block 3 is not shown,
     because the return is to a point inside the block and not to the
     top.  The block address 0 always indicates, that control is
     transferred to the trace from somewhere outside the observed
     functions.  With `-foo' added to `bb.in', the blocks of function
     `foo' are removed from the trace, so only 0 3 4 remains.

     With `__bb_jumps__' and `main' contained in file `bb.in', jump
     frequencies will be written to file `bb.out'.  The frequencies are
     obtained by constructing a trace of blocks and incrementing a
     counter for every neighbouring pair of blocks in the trace.  The
     trace 0 3 1 2 1 2 4 displays the following frequencies:

          Jump from block 0x0 to block 0x3 executed 1 time(s)
          Jump from block 0x3 to block 0x1 executed 1 time(s)
          Jump from block 0x1 to block 0x2 executed 2 time(s)
          Jump from block 0x2 to block 0x1 executed 1 time(s)
          Jump from block 0x2 to block 0x4 executed 1 time(s)

     With `__bb_hidecall__', control transfer due to call instructions
     is removed from the trace, that is the trace is cut into three
     parts: 0 3 4, 0 1 2 and 0 1 2.  With `__bb_showret__', control
     transfer due to return instructions is added to the trace.  The
     trace becomes: 0 3 1 2 3 1 2 3 4.  Note, that this trace is not
     the same, as the sequence written to `bbtrace.gz'.  It is solely
     used for counting jump frequencies.

`-fprofile-arcs'
     Instrument "arcs" during compilation to generate coverage data or
     for profile-directed block ordering.  During execution the program
     records how many times each branch is executed and how many times
     it is taken.  When the compiled program exits it saves this data
     to a file called `SOURCENAME.da' for each source file.

     For profile-directed block ordering, compile the program with
     `-fprofile-arcs' plus optimization and code generation options,
     generate the arc profile information by running the program on a
     selected workload, and then compile the program again with the same
     optimization and code generation options plus
     `-fbranch-probabilities' (*note Options that Control Optimization:
     Optimize Options.).

     The other use of `-fprofile-arcs' is for use with `gcov', when it
     is used with the `-ftest-coverage' option.  GCC supports two
     methods of determining code coverage: the options that support
     `gcov', and options `-a' and `-ax', which write information to
     text files.  The options that support `gcov' do not need to
     instrument every arc in the program, so a program compiled with
     them runs faster than a program compiled with `-a', which adds
     instrumentation code to every basic block in the program.  The
     tradeoff: since `gcov' does not have execution counts for all
     branches, it must start with the execution counts for the
     instrumented branches, and then iterate over the program flow
     graph until the entire graph has been solved.  Hence, `gcov' runs
     a little more slowly than a program which uses information from
     `-a' and `-ax'.

     With `-fprofile-arcs', for each function of your program GCC
     creates a program flow graph, then finds a spanning tree for the
     graph.  Only arcs that are not on the spanning tree have to be
     instrumented: the compiler adds code to count the number of times
     that these arcs are executed.  When an arc is the only exit or
     only entrance to a block, the instrumentation code can be added to
     the block; otherwise, a new basic block must be created to hold
     the instrumentation code.

     This option makes it possible to estimate branch probabilities and
     to calculate basic block execution counts.  In general, basic block
     execution counts as provided by `-a' do not give enough
     information to estimate all branch probabilities.

`-ftest-coverage'
     Create data files for the `gcov' code-coverage utility (*note
     `gcov': a GCC Test Coverage Program: Gcov.).  The data file names
     begin with the name of your source file:

    `SOURCENAME.bb'
          A mapping from basic blocks to line numbers, which `gcov'
          uses to associate basic block execution counts with line
          numbers.

    `SOURCENAME.bbg'
          A list of all arcs in the program flow graph.  This allows
          `gcov' to reconstruct the program flow graph, so that it can
          compute all basic block and arc execution counts from the
          information in the `SOURCENAME.da' file.

     Use `-ftest-coverage' with `-fprofile-arcs'; the latter option
     adds instrumentation to the program, which then writes execution
     counts to another data file:

    `SOURCENAME.da'
          Runtime arc execution counts, used in conjunction with the arc
          information in the file `SOURCENAME.bbg'.

     Coverage data will map better to the source files if
     `-ftest-coverage' is used without optimization.

`-dLETTERS'
     Says to make debugging dumps during compilation at times specified
     by LETTERS.  This is used for debugging the compiler.  The file
     names for most of the dumps are made by appending a pass number
     and a word to the source file name (e.g.  `foo.c.00.rtl' or
     `foo.c.01.sibling').  Here are the possible letters for use in
     LETTERS, and their meanings:

    `A'
          Annotate the assembler output with miscellaneous debugging
          information.

    `b'
          Dump after computing branch probabilities, to `FILE.14.bp'.

    `B'
          Dump after block reordering, to `FILE.28.bbro'.

    `c'
          Dump after instruction combination, to the file
          `FILE.16.combine'.

    `C'
          Dump after the first if conversion, to the file `FILE.17.ce'.

    `d'
          Dump after delayed branch scheduling, to `FILE.31.dbr'.

    `D'
          Dump all macro definitions, at the end of preprocessing, in
          addition to normal output.

    `e'
          Dump after SSA optimizations, to `FILE.04.ssa' and
          `FILE.07.ussa'.

    `E'
          Dump after the second if conversion, to `FILE.26.ce2'.

    `f'
          Dump after life analysis, to `FILE.15.life'.

    `F'
          Dump after purging `ADDRESSOF' codes, to `FILE.09.addressof'.

    `g'
          Dump after global register allocation, to `FILE.21.greg'.

    `h'
          Dump after finalization of EH handling code, to `FILE.02.eh'.

    `o'
          Dump after post-reload optimizations, to `FILE.22.postreload'.

    `G'
          Dump after GCSE, to `FILE.10.gcse'.

    `i'
          Dump after sibling call optimizations, to `FILE.01.sibling'.

    `j'
          Dump after the first jump optimization, to `FILE.03.jump'.

    `k'
          Dump after conversion from registers to stack, to
          `FILE.32.stack'.

    `l'
          Dump after local register allocation, to `FILE.20.lreg'.

    `L'
          Dump after loop optimization, to `FILE.11.loop'.

    `M'
          Dump after performing the machine dependent reorganisation
          pass, to `FILE.30.mach'.

    `n'
          Dump after register renumbering, to `FILE.25.rnreg'.

    `N'
          Dump after the register move pass, to `FILE.18.regmove'.

    `r'
          Dump after RTL generation, to `FILE.00.rtl'.

    `R'
          Dump after the second scheduling pass, to `FILE.27.sched2'.

    `s'
          Dump after CSE (including the jump optimization that
          sometimes follows CSE), to `FILE.08.cse'.

    `S'
          Dump after the first scheduling pass, to `FILE.19.sched'.

    `t'
          Dump after the second CSE pass (including the jump
          optimization that sometimes follows CSE), to `FILE.12.cse2'.

    `w'
          Dump after the second flow pass, to `FILE.23.flow2'.

    `X'
          Dump after SSA dead code elimination, to `FILE.06.ssadce'.

    `z'
          Dump after the peephole pass, to `FILE.24.peephole2'.

    `a'
          Produce all the dumps listed above.

    `m'
          Print statistics on memory usage, at the end of the run, to
          standard error.

    `p'
          Annotate the assembler output with a comment indicating which
          pattern and alternative was used.  The length of each
          instruction is also printed.

    `P'
          Dump the RTL in the assembler output as a comment before each
          instruction.  Also turns on `-dp' annotation.

    `v'
          For each of the other indicated dump files (except for
          `FILE.00.rtl'), dump a representation of the control flow
          graph suitable for viewing with VCG to `FILE.PASS.vcg'.

    `x'
          Just generate RTL for a function instead of compiling it.
          Usually used with `r'.

    `y'
          Dump debugging information during parsing, to standard error.

`-fdump-unnumbered'
     When doing debugging dumps (see `-d' option above), suppress
     instruction numbers and line number note output.  This makes it
     more feasible to use diff on debugging dumps for compiler
     invocations with different options, in particular with and without
     `-g'.

`-fdump-class-hierarchy (C++ only)'
`-fdump-class-hierarchy-OPTIONS (C++ only)'
     Dump a representation of each class's hierarchy and virtual
     function table layout to a file.  The file name is made by
     appending `.class' to the source file name.  If the `-OPTIONS'
     form is used, OPTIONS controls the details of the dump as
     described for the `-fdump-tree' options.

`-fdump-tree-SWITCH (C++ only)'
`-fdump-tree-SWITCH-OPTIONS (C++ only)'
     Control the dumping at various stages of processing the
     intermediate language tree to a file.  The file name is generated
     by appending a switch specific suffix to the source file name.  If
     the `-OPTIONS' form is used, OPTIONS is a list of `-' separated
     options that control the details of the dump. Not all options are
     applicable to all dumps, those which are not meaningful will be
     ignored. The following options are available

    `address'
          Print the address of each node.  Usually this is not
          meaningful as it changes according to the environment and
          source file. Its primary use is for tying up a dump file with
          a debug environment.

    `slim'
          Inhibit dumping of members of a scope or body of a function
          merely because that scope has been reached. Only dump such
          items when they are directly reachable by some other path.

    `all'
          Turn on all options.

     The following tree dumps are possible:
    `original'
          Dump before any tree based optimization, to `FILE.original'.

    `optimized'
          Dump after all tree based optimization, to `FILE.optimized'.

    `inlined'
          Dump after function inlining, to `FILE.inlined'.

`-fpretend-float'
     When running a cross-compiler, pretend that the target machine
     uses the same floating point format as the host machine.  This
     causes incorrect output of the actual floating constants, but the
     actual instruction sequence will probably be the same as GCC would
     make when running on the target machine.

`-save-temps'
     Store the usual "temporary" intermediate files permanently; place
     them in the current directory and name them based on the source
     file.  Thus, compiling `foo.c' with `-c -save-temps' would produce
     files `foo.i' and `foo.s', as well as `foo.o'.  This creates a
     preprocessed `foo.i' output file even though the compiler now
     normally uses an integrated preprocessor.

`-time'
     Report the CPU time taken by each subprocess in the compilation
     sequence.  For C source files, this is the compiler proper and
     assembler (plus the linker if linking is done).  The output looks
     like this:

          # cc1 0.12 0.01
          # as 0.00 0.01

     The first number on each line is the "user time," that is time
     spent executing the program itself.  The second number is "system
     time," time spent executing operating system routines on behalf of
     the program.  Both numbers are in seconds.

`-print-file-name=LIBRARY'
     Print the full absolute name of the library file LIBRARY that
     would be used when linking--and don't do anything else.  With this
     option, GCC does not compile or link anything; it just prints the
     file name.

`-print-multi-directory'
     Print the directory name corresponding to the multilib selected by
     any other switches present in the command line.  This directory is
     supposed to exist in `GCC_EXEC_PREFIX'.

`-print-multi-lib'
     Print the mapping from multilib directory names to compiler
     switches that enable them.  The directory name is separated from
     the switches by `;', and each switch starts with an `@' instead of
     the `-', without spaces between multiple switches.  This is
     supposed to ease shell-processing.

`-print-prog-name=PROGRAM'
     Like `-print-file-name', but searches for a program such as `cpp'.

`-print-libgcc-file-name'
     Same as `-print-file-name=libgcc.a'.

     This is useful when you use `-nostdlib' or `-nodefaultlibs' but
     you do want to link with `libgcc.a'.  You can do

          gcc -nostdlib FILES... `gcc -print-libgcc-file-name`

`-print-search-dirs'
     Print the name of the configured installation directory and a list
     of program and library directories gcc will search--and don't do
     anything else.

     This is useful when gcc prints the error message `installation
     problem, cannot exec cpp0: No such file or directory'.  To resolve
     this you either need to put `cpp0' and the other compiler
     components where gcc expects to find them, or you can set the
     environment variable `GCC_EXEC_PREFIX' to the directory where you
     installed them.  Don't forget the trailing '/'.  *Note Environment
     Variables::.

`-dumpmachine'
     Print the compiler's target machine (for example,
     `i686-pc-linux-gnu')--and don't do anything else.

`-dumpversion'
     Print the compiler version (for example, `3.0')--and don't do
     anything else.

`-dumpspecs'
     Print the compiler's built-in specs--and don't do anything else.
     (This is used when GCC itself is being built.)  *Note Spec Files::.

