crosstool-ng/config/cc/gcc.in.2

# gcc configuration options

config CC_ENABLE_CXX_FLAGS
    string
    prompt "Flags to pass to --enable-cxx-flags"
    default ""
    help
      Enter here the value of the gcc's ./configure option --enable-cxx-flags.
      Leave empty if you don't know better.
      
      Note: just pass in the option _value_, that is only the part that goes
      after the '=' sign.

config CC_CORE_EXTRA_CONFIG_ARRAY
    string
    prompt "Core gcc extra config"
    default ""
    help
      Extra flags to pass onto ./configure when configuring the core gcc.
      
      The core gcc is a stripped down, C-only compiler needed to build
      the C library. Kinda bootstrap gcc, if you wish.
      
      You can enter multiple arguments here, and arguments can contain spaces
      if they are properly quoted (or escaped, but prefer quotes). Eg.:
          --with-foo="1st arg with 4 spaces" --with-bar=2nd-arg-without-space

config CC_EXTRA_CONFIG_ARRAY
    string
    prompt "gcc extra config"
    default ""
    depends on ! BARE_METAL
    help
      Extra flags to pass onto ./configure when configuring gcc.
      
      You can enter multiple arguments here, and arguments can contain spaces
      if they are properly quoted (or escaped, but prefer quotes). Eg.:
          --with-foo="1st arg with 4 spaces" --with-bar=2nd-arg-without-space

config STATIC_TOOLCHAIN
    select CC_STATIC_LIBSTDCXX if CC_GCC_4_4_or_later

config CC_STATIC_LIBSTDCXX
    bool
    prompt "Link libstdc++ statically into the gcc binary"
    default y
    depends on CONFIGURE_has_static_libstdcxx
    depends on CC_GCC_4_4_or_later
    help
      Newer gcc versions use the PPL library which is C++ code.  Statically
      linking libstdc++ increases the likeliness that the gcc binary will
      run on machines other than the one which it was built on, without
      having to worry about distributing the matching version of libstdc++
      along with it.

#-----------------------------------------------------------------------------
# Optimisation features

comment "Optimisation features"

config CC_GCC_USE_GRAPHITE
    bool
    prompt "Enable GRAPHITE loop optimisations"
    default y
    depends on CC_GCC_HAS_GRAPHITE
    select CC_GCC_USE_PPL_CLOOG
    help
      Enable the GRAPHITE loop optimsations.
      
      This requires the PPL and CLooG companion libraries, and
      those will be automatically build for you.
      
      On some systems (eg. Cygwin), PPL and/or CLooG may not
      build properly (yet), so you'll have to say 'N' here.

# The way LTO works is a bit twisted.
# See: http://gcc.gnu.org/wiki/LinkTimeOptimization#Requirements
# Basically:
#   - if binutils has plugins: LTO is handled by ld/gold by loading
#     the plugin when linking
#   - if binutils does not have plugins: LTO is handled by collect2
# In any case, LTO support does not depend on plugins, but takes
# advantage of it
# Also, only the 4.5 series needs libelf for LTO; 4.6 has dropped
# the dependency.
config CC_GCC_USE_LTO
    bool
    prompt "Enable LTO"
    default y
    depends on CC_GCC_HAS_LTO
    select CC_GCC_USE_LIBELF if CC_GCC_4_5
    help
      Enable the Link Time Optimisations.
      
      This will require the libelf companion library, and it
      wil be build automatically for you.

#-----------------------------------------------------------------------------
comment "Settings for libraries running on target"

config CC_GCC_ENABLE_TARGET_OPTSPACE
    bool
    prompt "Optimize gcc libs for size"
    default y
    help
      Pass --enable-target-optspace to crossgcc's configure.
      
      This will compile crossgcc's libs with -Os.

config CC_GCC_LIBMUDFLAP
    bool
    prompt "Compile libmudflap"
    help
      libmudflap is a pointer-use checking tool, which can detect
      various mis-usages of pointers in C and (to some extents) C++.
      
      You should say 'N' here, as libmduflap generates instrumented
      code (thus it is a bit bigger and a bit slower) and requires
      re-compilation and re-link, while it exists better run-time
      alternatives (eg. DUMA, dmalloc...) that need neither re-
      compilation nor re-link.

config CC_GCC_LIBGOMP
    bool
    prompt "Compile libgomp"
    help
      libgomp is "the GNU implementation of the OpenMP Application Programming
      Interface (API) for multi-platform shared-memory parallel programming in
      C/C++ and Fortran". See:
        http://gcc.gnu.org/onlinedocs/libgomp/
      
      The default is 'N'. Say 'Y' if you need it, and report success/failure.

config CC_GCC_LIBSSP
    bool
    prompt "Compile libssp"
    help
      libssp is the run-time Stack-Smashing Protection library.
      
      The default is 'N'. Say 'Y' if you need it, and report success/failure.

#-----------------------------------------------------------------------------

comment "Misc. obscure options."

config CC_CXA_ATEXIT
    bool
    prompt "Use __cxa_atexit"
    default y
    depends on ! BARE_METAL
    help
      If you get the missing symbol "__cxa_atexit" when building C++ programs,
      you might want to try disabling this option.

config CC_GCC_DISABLE_PCH
    bool
    prompt "Do not build PCH"
    help
      Say 'y' here to not use Pre-Compiled Headers in the resulting toolchain.
      at the expense of speed when compiling C++ code.
      
      For some configurations (most notably canadian?), PCH are broken, and
      need to be disabled. Please see:
        http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40974

config CC_GCC_SJLJ_EXCEPTIONS
    tristate
    prompt "Use sjlj for exceptions"
    depends on ! BARE_METAL
    default m
    help
      'sjlj' is short for setjmp/longjmp.
      
      On some architectures, stack unwinding during exception handling
      works perfectly well without using sjlj, while on some others,
      use of sjlj is required for proper stack unwinding.
      
       Option  | sjlj use           | Associated ./configure switch
      ---------+--------------------+--------------------------------
         Y     | forcibly used      | --enable-sjlj-exceptions
         M     | auto               | (none, ./configure decides)
         N     | forcibly not used  | --disable-sjlj-exceptions
      
      It should be safe to say 'M' or 'N'.
      
      It can happen that ./configure is wrong in some cases. Known
      case is for ARM big endian, where you should say 'N'.

config CC_GCC_LDBL_128
    tristate
    prompt "Enable 128-bit long doubles"
    default m
    depends on CC_GCC_4_2_or_later
    help
      Saying 'Y' will force gcc to use 128-bit wide long doubles
      Saying 'N' will force gcc to use 64-bit wide long doubles
      Saying 'M' will let gcc choose (default is 128-bit for
                 glibc >= 2.4, 64-bit otherwise)
      
      If in doubt, keep the default, ie. 'M'.