Update gcc-50 to SVN version 222168 (gcc-5-branch)
authorJohn Marino <draco@marino.st>
Fri, 17 Apr 2015 07:45:38 +0000 (09:45 +0200)
committerJohn Marino <draco@marino.st>
Fri, 17 Apr 2015 10:56:19 +0000 (12:56 +0200)
Last Changed Date: 2015-04-17 09:45:46 +0200 (Fri, 17 Apr 2015)

125 files changed:
contrib/gcc-5.0/LAST_UPDATED
contrib/gcc-5.0/gcc/BASE-VER
contrib/gcc-5.0/gcc/DATESTAMP
contrib/gcc-5.0/gcc/c-family/c-common.c
contrib/gcc-5.0/gcc/c-family/c-common.h
contrib/gcc-5.0/gcc/c/c-decl.c
contrib/gcc-5.0/gcc/c/c-tree.h
contrib/gcc-5.0/gcc/calls.c
contrib/gcc-5.0/gcc/cfgrtl.c
contrib/gcc-5.0/gcc/cgraphunit.c
contrib/gcc-5.0/gcc/combine.c
contrib/gcc-5.0/gcc/config/i386/i386.c
contrib/gcc-5.0/gcc/config/i386/i386.md
contrib/gcc-5.0/gcc/config/i386/intelmic-mkoffload.c
contrib/gcc-5.0/gcc/config/i386/sse.md
contrib/gcc-5.0/gcc/cp/constexpr.c
contrib/gcc-5.0/gcc/cp/lambda.c
contrib/gcc-5.0/gcc/cp/tree.c
contrib/gcc-5.0/gcc/doc/avr-mmcu.texi [deleted file]
contrib/gcc-5.0/gcc/doc/bugreport.texi [deleted file]
contrib/gcc-5.0/gcc/doc/cfg.texi [deleted file]
contrib/gcc-5.0/gcc/doc/collect2.texi [deleted file]
contrib/gcc-5.0/gcc/doc/compat.texi [deleted file]
contrib/gcc-5.0/gcc/doc/configfiles.texi [deleted file]
contrib/gcc-5.0/gcc/doc/configterms.texi [deleted file]
contrib/gcc-5.0/gcc/doc/contrib.texi [deleted file]
contrib/gcc-5.0/gcc/doc/contribute.texi [deleted file]
contrib/gcc-5.0/gcc/doc/cpp.texi [deleted file]
contrib/gcc-5.0/gcc/doc/cppenv.texi [deleted file]
contrib/gcc-5.0/gcc/doc/cppinternals.texi [deleted file]
contrib/gcc-5.0/gcc/doc/cppopts.texi [deleted file]
contrib/gcc-5.0/gcc/doc/extend.texi [deleted file]
contrib/gcc-5.0/gcc/doc/fragments.texi [deleted file]
contrib/gcc-5.0/gcc/doc/frontends.texi [deleted file]
contrib/gcc-5.0/gcc/doc/gcc.texi [deleted file]
contrib/gcc-5.0/gcc/doc/gccint.texi [deleted file]
contrib/gcc-5.0/gcc/doc/gcov-tool.texi [deleted file]
contrib/gcc-5.0/gcc/doc/gcov.texi [deleted file]
contrib/gcc-5.0/gcc/doc/generic.texi [deleted file]
contrib/gcc-5.0/gcc/doc/gimple.texi [deleted file]
contrib/gcc-5.0/gcc/doc/gnu.texi [deleted file]
contrib/gcc-5.0/gcc/doc/gty.texi [deleted file]
contrib/gcc-5.0/gcc/doc/headerdirs.texi [deleted file]
contrib/gcc-5.0/gcc/doc/hostconfig.texi [deleted file]
contrib/gcc-5.0/gcc/doc/implement-c.texi [deleted file]
contrib/gcc-5.0/gcc/doc/implement-cxx.texi [deleted file]
contrib/gcc-5.0/gcc/doc/include/fdl.texi [deleted file]
contrib/gcc-5.0/gcc/doc/include/funding.texi [deleted file]
contrib/gcc-5.0/gcc/doc/include/gcc-common.texi [deleted file]
contrib/gcc-5.0/gcc/doc/include/gpl_v3.texi [deleted file]
contrib/gcc-5.0/gcc/doc/interface.texi [deleted file]
contrib/gcc-5.0/gcc/doc/invoke.texi [deleted file]
contrib/gcc-5.0/gcc/doc/languages.texi [deleted file]
contrib/gcc-5.0/gcc/doc/libgcc.texi [deleted file]
contrib/gcc-5.0/gcc/doc/loop.texi [deleted file]
contrib/gcc-5.0/gcc/doc/lto.texi [deleted file]
contrib/gcc-5.0/gcc/doc/makefile.texi [deleted file]
contrib/gcc-5.0/gcc/doc/match-and-simplify.texi [deleted file]
contrib/gcc-5.0/gcc/doc/md.texi [deleted file]
contrib/gcc-5.0/gcc/doc/objc.texi [deleted file]
contrib/gcc-5.0/gcc/doc/optinfo.texi [deleted file]
contrib/gcc-5.0/gcc/doc/options.texi [deleted file]
contrib/gcc-5.0/gcc/doc/passes.texi [deleted file]
contrib/gcc-5.0/gcc/doc/plugins.texi [deleted file]
contrib/gcc-5.0/gcc/doc/portability.texi [deleted file]
contrib/gcc-5.0/gcc/doc/rtl.texi [deleted file]
contrib/gcc-5.0/gcc/doc/service.texi [deleted file]
contrib/gcc-5.0/gcc/doc/sourcebuild.texi [deleted file]
contrib/gcc-5.0/gcc/doc/standards.texi [deleted file]
contrib/gcc-5.0/gcc/doc/tm.texi [deleted file]
contrib/gcc-5.0/gcc/doc/tree-ssa.texi [deleted file]
contrib/gcc-5.0/gcc/doc/trouble.texi [deleted file]
contrib/gcc-5.0/gcc/dwarf2out.c
contrib/gcc-5.0/gcc/expr.c
contrib/gcc-5.0/gcc/gcov.c
contrib/gcc-5.0/gcc/gimple-fold.c
contrib/gcc-5.0/gcc/ipa-chkp.c
contrib/gcc-5.0/gcc/ipa-comdats.c
contrib/gcc-5.0/gcc/ipa-cp.c
contrib/gcc-5.0/gcc/ipa-icf-gimple.c
contrib/gcc-5.0/gcc/ipa-icf.c
contrib/gcc-5.0/gcc/ipa-inline-analysis.c
contrib/gcc-5.0/gcc/ipa-inline-transform.c
contrib/gcc-5.0/gcc/ipa-inline.c
contrib/gcc-5.0/gcc/ipa-prop.c
contrib/gcc-5.0/gcc/ipa-split.c
contrib/gcc-5.0/gcc/lra-assigns.c
contrib/gcc-5.0/gcc/lra-constraints.c
contrib/gcc-5.0/gcc/lra-int.h
contrib/gcc-5.0/gcc/lra-remat.c
contrib/gcc-5.0/gcc/lra.c
contrib/gcc-5.0/gcc/lto-cgraph.c
contrib/gcc-5.0/gcc/omp-low.c
contrib/gcc-5.0/gcc/params.def
contrib/gcc-5.0/gcc/tree-chkp.c
contrib/gcc-5.0/gcc/tree-chkp.h
contrib/gcc-5.0/gcc/tree-ssa-threadedge.c
contrib/gcc-5.0/gcc/tree-vect-data-refs.c
contrib/gcc-5.0/gcc/tree-vect-loop.c
contrib/gcc-5.0/gcc/tree-vectorizer.h
contrib/gcc-5.0/gcc/tree.h
contrib/gcc-5.0/gcc/ubsan.c
contrib/gcc-5.0/gcc/valtrack.c
contrib/gcc-5.0/gcc/varasm.c
contrib/gcc-5.0/libcpp/files.c
contrib/gcc-5.0/libcpp/lex.c
contrib/gcc-5.0/libgomp/libgomp-plugin.h
contrib/gcc-5.0/libgomp/libgomp.h
contrib/gcc-5.0/libgomp/libgomp.map
contrib/gcc-5.0/libgomp/oacc-async.c
contrib/gcc-5.0/libgomp/oacc-cuda.c
contrib/gcc-5.0/libgomp/oacc-host.c
contrib/gcc-5.0/libgomp/oacc-init.c
contrib/gcc-5.0/libgomp/oacc-int.h
contrib/gcc-5.0/libgomp/oacc-mem.c
contrib/gcc-5.0/libgomp/oacc-parallel.c
contrib/gcc-5.0/libgomp/plugin/plugin-host.c
contrib/gcc-5.0/libgomp/plugin/plugin-nvptx.c
contrib/gcc-5.0/libgomp/target.c
contrib/gcc-5.0/libiberty/at-file.texi [deleted file]
contrib/gcc-5.0/libitm/libitm.texi [deleted file]
contrib/gcc-5.0/libstdc++-v3/config/abi/pre/gnu.ver
contrib/gcc-5.0/libstdc++-v3/include/bits/atomic_base.h
contrib/gcc-5.0/libstdc++-v3/include/std/atomic
contrib/gcc-5.0/libstdc++-v3/include/std/shared_mutex

index 04f3be4..7fc42a2 100644 (file)
@@ -1,2 +1,2 @@
-221845
-Last Changed Date: 2015-04-02 19:33:22 +0200 (Thu, 02 Apr 2015)
+222168
+Last Changed Date: 2015-04-17 09:45:46 +0200 (Fri, 17 Apr 2015)
index 456c619..7fe7fa6 100644 (file)
@@ -67,6 +67,10 @@ along with GCC; see the file COPYING3.  If not see
 
 cpp_reader *parse_in;          /* Declared in c-pragma.h.  */
 
+/* Mode used to build pointers (VOIDmode means ptr_mode).  */
+
+machine_mode c_default_pointer_mode = VOIDmode;
+
 /* The following symbols are subsumed in the c_global_trees array, and
    listed here individually for documentation purposes.
 
index 5b2c5ab..cabf452 100644 (file)
@@ -358,6 +358,10 @@ struct c_common_resword
   const unsigned int disable   : 16;
 };
 
+/* Mode used to build pointers (VOIDmode means ptr_mode).  */
+
+extern machine_mode c_default_pointer_mode;
+
 /* Extra cpp_ttype values for C++.  */
 
 /* A token type for template-ids.  If a template-id is processed while
index e1741f1..e28a294 100644 (file)
@@ -168,10 +168,6 @@ static int warn_about_return_type;
 
 static bool undef_nested_function;
 
-/* Mode used to build pointers (VOIDmode means ptr_mode).  */
-
-machine_mode c_default_pointer_mode = VOIDmode;
-
 /* If non-zero, implicit "omp declare target" attribute is added into the
    attribute lists.  */
 int current_omp_declare_target_attribute;
index c879bc7..7a72665 100644 (file)
@@ -671,10 +671,6 @@ extern int current_function_returns_null;
 
 extern int current_function_returns_abnormally;
 
-/* Mode used to build pointers (VOIDmode means ptr_mode).  */
-
-extern machine_mode c_default_pointer_mode;
-
 /* In c-decl.c */
 
 /* Tell the binding oracle what kind of binding we are looking for.  */
index ec44624..970415d 100644 (file)
@@ -1321,6 +1321,15 @@ initialize_argument_information (int num_actuals ATTRIBUTE_UNUSED,
                  && TREE_CODE (base) != SSA_NAME
                  && (!DECL_P (base) || MEM_P (DECL_RTL (base)))))
            {
+             /* We may have turned the parameter value into an SSA name.
+                Go back to the original parameter so we can take the
+                address.  */
+             if (TREE_CODE (args[i].tree_value) == SSA_NAME)
+               {
+                 gcc_assert (SSA_NAME_IS_DEFAULT_DEF (args[i].tree_value));
+                 args[i].tree_value = SSA_NAME_VAR (args[i].tree_value);
+                 gcc_assert (TREE_CODE (args[i].tree_value) == PARM_DECL);
+               }
              /* Argument setup code may have copied the value to register.  We
                 revert that optimization now because the tail call code must
                 use the original location.  */
index 0e27edd..46fd958 100644 (file)
@@ -1928,7 +1928,7 @@ rtl_split_edge (edge edge_in)
               && (edge_in->flags & EDGE_CROSSING))
             {
               after = last_bb_in_partition (edge_in->src);
-              before = NEXT_INSN (BB_END (after));
+              before = get_last_bb_insn (after);
               /* The instruction following the last bb in partition should
                  be a barrier, since it cannot end in a fall-through.  */
               gcc_checking_assert (BARRIER_P (before));
index 8ac92e1..2315ba8 100644 (file)
@@ -1508,6 +1508,10 @@ cgraph_node::expand_thunk (bool output_asm_thunks, bool force_gimple_thunk)
   tree thunk_fndecl = decl;
   tree a;
 
+  /* Instrumentation thunk is the same function with
+     a different signature.  Never need to expand it.  */
+  if (thunk.add_pointer_bounds_args)
+    return false;
 
   if (!force_gimple_thunk && this_adjusting
       && targetm.asm_out.can_output_mi_thunk (thunk_fndecl, fixed_offset,
@@ -1581,6 +1585,7 @@ cgraph_node::expand_thunk (bool output_asm_thunks, bool force_gimple_thunk)
       int i;
       tree resdecl;
       tree restmp = NULL;
+      tree resbnd = NULL;
 
       gcall *call;
       greturn *ret;
@@ -1697,6 +1702,17 @@ cgraph_node::expand_thunk (bool output_asm_thunks, bool force_gimple_thunk)
       gsi_insert_after (&bsi, call, GSI_NEW_STMT);
       if (!alias_is_noreturn)
        {
+         if (instrumentation_clone
+             && !DECL_BY_REFERENCE (resdecl)
+             && restmp
+             && BOUNDED_P (restmp))
+           {
+             resbnd = chkp_insert_retbnd_call (NULL, restmp, &bsi);
+             create_edge (get_create (gimple_call_fndecl (gsi_stmt (bsi))),
+                          as_a <gcall *> (gsi_stmt (bsi)),
+                          callees->count, callees->frequency);
+           }
+
          if (restmp && !this_adjusting
              && (fixed_offset || virtual_offset))
            {
@@ -1766,6 +1782,7 @@ cgraph_node::expand_thunk (bool output_asm_thunks, bool force_gimple_thunk)
            ret = gimple_build_return (restmp);
          else
            ret = gimple_build_return (resdecl);
+         gimple_return_set_retbnd (ret, resbnd);
 
          gsi_insert_after (&bsi, ret, GSI_NEW_STMT);
        }
index 71e5690..46cd6db 100644 (file)
@@ -2492,14 +2492,11 @@ update_cfg_for_uncondjump (rtx_insn *insn)
     }
 }
 
-#ifndef HAVE_cc0
-/* Return whether INSN is a PARALLEL of exactly N register SETs followed
+/* Return whether PAT is a PARALLEL of exactly N register SETs followed
    by an arbitrary number of CLOBBERs.  */
 static bool
-is_parallel_of_n_reg_sets (rtx_insn *insn, int n)
+is_parallel_of_n_reg_sets (rtx pat, int n)
 {
-  rtx pat = PATTERN (insn);
-
   if (GET_CODE (pat) != PARALLEL)
     return false;
 
@@ -2519,6 +2516,7 @@ is_parallel_of_n_reg_sets (rtx_insn *insn, int n)
   return true;
 }
 
+#ifndef HAVE_cc0
 /* Return whether INSN, a PARALLEL of N register SETs (and maybe some
    CLOBBERs), can be split into individual SETs in that order, without
    changing semantics.  */
@@ -2907,7 +2905,7 @@ try_combine (rtx_insn *i3, rtx_insn *i2, rtx_insn *i1, rtx_insn *i0,
      decrement insn.  */
 
   if (i1 == 0
-      && is_parallel_of_n_reg_sets (i2, 2)
+      && is_parallel_of_n_reg_sets (PATTERN (i2), 2)
       && (GET_MODE_CLASS (GET_MODE (SET_DEST (XVECEXP (PATTERN (i2), 0, 0))))
          == MODE_CC)
       && GET_CODE (SET_SRC (XVECEXP (PATTERN (i2), 0, 0))) == COMPARE
@@ -2939,7 +2937,7 @@ try_combine (rtx_insn *i3, rtx_insn *i2, rtx_insn *i1, rtx_insn *i0,
      make those two SETs separate I1 and I2 insns, and make an I0 that is
      the original I1.  */
   if (i0 == 0
-      && is_parallel_of_n_reg_sets (i2, 2)
+      && is_parallel_of_n_reg_sets (PATTERN (i2), 2)
       && can_split_parallel_of_n_reg_sets (i2, 2)
       && !reg_used_between_p (SET_DEST (XVECEXP (PATTERN (i2), 0, 0)), i2, i3)
       && !reg_used_between_p (SET_DEST (XVECEXP (PATTERN (i2), 0, 1)), i2, i3))
@@ -3460,10 +3458,7 @@ try_combine (rtx_insn *i3, rtx_insn *i2, rtx_insn *i1, rtx_insn *i0,
      debug info less accurate.  */
 
   if (!(added_sets_2 && i1 == 0)
-      && GET_CODE (newpat) == PARALLEL
-      && XVECLEN (newpat, 0) == 2
-      && GET_CODE (XVECEXP (newpat, 0, 0)) == SET
-      && GET_CODE (XVECEXP (newpat, 0, 1)) == SET
+      && is_parallel_of_n_reg_sets (newpat, 2)
       && asm_noperands (newpat) < 0)
     {
       rtx set0 = XVECEXP (newpat, 0, 0);
index d8d9983..110ec4a 100644 (file)
@@ -5649,7 +5649,7 @@ ix86_handle_cconv_attribute (tree *node, tree name,
   else if (is_attribute_p ("thiscall", name))
     {
       if (TREE_CODE (*node) != METHOD_TYPE && pedantic)
-       warning (OPT_Wattributes, "%qE attribute is used for none class-method",
+       warning (OPT_Wattributes, "%qE attribute is used for non-class method",
                 name);
       if (lookup_attribute ("stdcall", TYPE_ATTRIBUTES (*node)))
        {
@@ -25624,8 +25624,19 @@ ix86_expand_call (rtx retval, rtx fnaddr, rtx callarg1,
        {
          rtx b0 = gen_rtx_REG (BND64mode, FIRST_BND_REG);
          rtx b1 = gen_rtx_REG (BND64mode, FIRST_BND_REG + 1);
-         retval = gen_rtx_PARALLEL (VOIDmode, gen_rtvec (3, retval, b0, b1));
-         chkp_put_regs_to_expr_list (retval);
+         if (GET_CODE (retval) == PARALLEL)
+           {
+             b0 = gen_rtx_EXPR_LIST (VOIDmode, b0, const0_rtx);
+             b1 = gen_rtx_EXPR_LIST (VOIDmode, b1, const0_rtx);
+             rtx par = gen_rtx_PARALLEL (VOIDmode, gen_rtvec (2, b0, b1));
+             retval = chkp_join_splitted_slot (retval, par);
+           }
+         else
+           {
+             retval = gen_rtx_PARALLEL (VOIDmode,
+                                        gen_rtvec (3, retval, b0, b1));
+             chkp_put_regs_to_expr_list (retval);
+           }
        }
 
       call = gen_rtx_SET (VOIDmode, retval, call);
@@ -35852,6 +35863,15 @@ safe_vector_operand (rtx x, machine_mode mode)
   return x;
 }
 
+/* Fixup modeless constants to fit required mode.  */
+static rtx
+fixup_modeless_constant (rtx x, machine_mode mode)
+{
+  if (GET_MODE (x) == VOIDmode)
+    x = convert_to_mode (mode, x, 1);
+  return x;
+}
+
 /* Subroutine of ix86_expand_builtin to take care of binop insns.  */
 
 static rtx
@@ -37498,6 +37518,8 @@ ix86_expand_args_builtin (const struct builtin_description *d,
          if (memory_operand (op, mode))
            num_memory++;
 
+         op = fixup_modeless_constant (op, mode);
+
          if (GET_MODE (op) == mode || GET_MODE (op) == VOIDmode)
            {
              if (optimize || !match || num_memory > 1)
@@ -37650,7 +37672,7 @@ ix86_expand_sse_comi_round (const struct builtin_description *d,
     }
   if (INTVAL (op2) < 0 || INTVAL (op2) >= 32)
     {
-      error ("incorect comparison mode");
+      error ("incorrect comparison mode");
       return const0_rtx;
     }
 
@@ -37871,6 +37893,8 @@ ix86_expand_round_builtin (const struct builtin_description *d,
          if (VECTOR_MODE_P (mode))
            op = safe_vector_operand (op, mode);
 
+         op = fixup_modeless_constant (op, mode);
+
          if (GET_MODE (op) == mode || GET_MODE (op) == VOIDmode)
            {
              if (optimize || !match)
@@ -38278,6 +38302,8 @@ ix86_expand_special_args_builtin (const struct builtin_description *d,
              if (VECTOR_MODE_P (mode))
                op = safe_vector_operand (op, mode);
 
+             op = fixup_modeless_constant (op, mode);
+
              if (GET_MODE (op) == mode || GET_MODE (op) == VOIDmode)
                op = copy_to_mode_reg (mode, op);
              else
@@ -39841,6 +39867,9 @@ addcarryx:
        op1 = copy_to_mode_reg (Pmode, op1);
       if (!insn_data[icode].operand[3].predicate (op2, mode2))
        op2 = copy_to_mode_reg (mode2, op2);
+
+      op3 = fixup_modeless_constant (op3, mode3);
+
       if (GET_MODE (op3) == mode3 || GET_MODE (op3) == VOIDmode)
        {
          if (!insn_data[icode].operand[4].predicate (op3, mode3))
@@ -39984,6 +40013,8 @@ addcarryx:
       if (!insn_data[icode].operand[0].predicate (op0, Pmode))
        op0 = copy_to_mode_reg (Pmode, op0);
 
+      op1 = fixup_modeless_constant (op1, mode1);
+
       if (GET_MODE (op1) == mode1 || GET_MODE (op1) == VOIDmode)
        {
          if (!insn_data[icode].operand[1].predicate (op1, mode1))
@@ -40030,6 +40061,8 @@ addcarryx:
       mode3 = insn_data[icode].operand[3].mode;
       mode4 = insn_data[icode].operand[4].mode;
 
+      op0 = fixup_modeless_constant (op0, mode0);
+
       if (GET_MODE (op0) == mode0
          || (GET_MODE (op0) == VOIDmode && op0 != constm1_rtx))
        {
index cf63afd..e1c82fe 100644 (file)
    (set (match_operand:SWI48 1 "register_operand" "=r")
        (umod:SWI48 (match_dup 2) (match_dup 3)))
    (clobber (reg:CC FLAGS_REG))]
-  "UINTVAL (operands[3]) - 2 < <MODE_SIZE> * BITS_PER_UNIT
+  "IN_RANGE (INTVAL (operands[3]), 2, HOST_WIDE_INT_UC (0x80000000))
    && (UINTVAL (operands[3]) & (UINTVAL (operands[3]) - 1)) == 0"
   "#"
   "&& 1"
index f93007c..e5e5c35 100644 (file)
@@ -350,14 +350,27 @@ generate_host_descr_file (const char *host_compiler)
           "#ifdef __cplusplus\n"
           "extern \"C\"\n"
           "#endif\n"
-          "void GOMP_offload_register (void *, int, void *);\n\n"
+          "void GOMP_offload_register (void *, int, void *);\n"
+          "#ifdef __cplusplus\n"
+          "extern \"C\"\n"
+          "#endif\n"
+          "void GOMP_offload_unregister (void *, int, void *);\n\n"
 
           "__attribute__((constructor))\n"
           "static void\n"
           "init (void)\n"
           "{\n"
           "  GOMP_offload_register (&__OFFLOAD_TABLE__, %d, __offload_target_data);\n"
+          "}\n\n", GOMP_DEVICE_INTEL_MIC);
+
+  fprintf (src_file,
+          "__attribute__((destructor))\n"
+          "static void\n"
+          "fini (void)\n"
+          "{\n"
+          "  GOMP_offload_unregister (&__OFFLOAD_TABLE__, %d, __offload_target_data);\n"
           "}\n", GOMP_DEVICE_INTEL_MIC);
+
   fclose (src_file);
 
   unsigned new_argc = 0;
index 490fd6b..6d3b54a 100644 (file)
        (vec_select:<ssehalfvecmode>
          (match_operand:VI8F_256 1 "register_operand" "v,v")
          (parallel [(const_int 2) (const_int 3)])))]
-  "TARGET_AVX"
+  "TARGET_AVX && <mask_avx512vl_condition> && <mask_avx512dq_condition>"
 {
-  if (TARGET_AVX512DQ && TARGET_AVX512VL)
-    return "vextract<shuffletype>64x2\t{$0x1, %1, %0<mask_operand2>|%0<mask_operand2>, %1, 0x1}";
+  if (TARGET_AVX512VL)
+  {
+    if (TARGET_AVX512DQ)
+      return "vextract<shuffletype>64x2\t{$0x1, %1, %0<mask_operand2>|%0<mask_operand2>, %1, 0x1}";
+    else
+      return "vextract<shuffletype>32x4\t{$0x1, %1, %0|%0, %1, 0x1}";
+  }
   else
     return "vextract<i128>\t{$0x1, %1, %0|%0, %1, 0x1}";
 }
index f5be8df..2952cbe 100644 (file)
@@ -2929,6 +2929,7 @@ cxx_eval_pointer_plus_expression (const constexpr_ctx *ctx, tree t,
                                  bool lval, bool *non_constant_p,
                                  bool *overflow_p)
 {
+  tree orig_type = TREE_TYPE (t);
   tree op00 = TREE_OPERAND (t, 0);
   tree op01 = TREE_OPERAND (t, 1);
   location_t loc = EXPR_LOCATION (t);
@@ -2945,7 +2946,9 @@ cxx_eval_pointer_plus_expression (const constexpr_ctx *ctx, tree t,
   /* &A[i] p+ j => &A[i + j] */
   if (TREE_CODE (op00) == ARRAY_REF
       && TREE_CODE (TREE_OPERAND (op00, 1)) == INTEGER_CST
-      && TREE_CODE (op01) == INTEGER_CST)
+      && TREE_CODE (op01) == INTEGER_CST
+      && TYPE_SIZE_UNIT (TREE_TYPE (op00))
+      && TREE_CODE (TYPE_SIZE_UNIT (TREE_TYPE (op00))) == INTEGER_CST)
     {
       tree type = TREE_TYPE (op00);
       t = fold_convert_loc (loc, ssizetype, TREE_OPERAND (op00, 1));
@@ -2953,15 +2956,21 @@ cxx_eval_pointer_plus_expression (const constexpr_ctx *ctx, tree t,
       /* Don't fold an out-of-bound access.  */
       if (!tree_int_cst_le (t, nelts))
        return NULL_TREE;
+      op01 = cp_fold_convert (ssizetype, op01);
+      /* Don't fold if op01 can't be divided exactly by TYPE_SIZE_UNIT.
+        constexpr int A[1]; ... (char *)&A[0] + 1 */
+      if (!integer_zerop (fold_build2_loc (loc, TRUNC_MOD_EXPR, sizetype,
+                                          op01, TYPE_SIZE_UNIT (type))))
+       return NULL_TREE;
       /* Make sure to treat the second operand of POINTER_PLUS_EXPR
         as signed.  */
-      op01 = fold_build2_loc (loc, EXACT_DIV_EXPR, ssizetype,
-                             cp_fold_convert (ssizetype, op01),
+      op01 = fold_build2_loc (loc, EXACT_DIV_EXPR, ssizetype, op01,
                              TYPE_SIZE_UNIT (type));
       t = size_binop_loc (loc, PLUS_EXPR, op01, t);
       t = build4_loc (loc, ARRAY_REF, type, TREE_OPERAND (op00, 0),
                      t, NULL_TREE, NULL_TREE);
       t = cp_build_addr_expr (t, tf_warning_or_error);
+      t = cp_fold_convert (orig_type, t);
       return cxx_eval_constant_expression (ctx, t, lval, non_constant_p,
                                           overflow_p);
     }
index b160c8c..dd1c2d4 100644 (file)
@@ -506,7 +506,7 @@ add_capture (tree lambda, tree id, tree orig_init, bool by_reference_p,
       if (by_reference_p)
        {
          type = build_reference_type (type);
-         if (!real_lvalue_p (initializer))
+         if (!dependent_type_p (type) && !real_lvalue_p (initializer))
            error ("cannot capture %qE by reference", initializer);
        }
       else
index 97bccc0..71c84ae 100644 (file)
@@ -880,12 +880,19 @@ build_cplus_array_type (tree elt_type, tree index_type)
        {
          t = build_min_array_type (elt_type, index_type);
          set_array_type_canon (t, elt_type, index_type);
+         if (!dependent)
+           {
+             layout_type (t);
+             /* Make sure sizes are shared with the main variant.
+                layout_type can't be called after setting TYPE_NEXT_VARIANT,
+                as it will overwrite alignment etc. of all variants.  */
+             TYPE_SIZE (t) = TYPE_SIZE (m);
+             TYPE_SIZE_UNIT (t) = TYPE_SIZE_UNIT (m);
+           }
 
          TYPE_MAIN_VARIANT (t) = m;
          TYPE_NEXT_VARIANT (t) = TYPE_NEXT_VARIANT (m);
          TYPE_NEXT_VARIANT (m) = t;
-         if (!dependent)
-           layout_type (t);
        }
     }
 
@@ -1072,6 +1079,8 @@ cp_build_qualified_type_real (tree type,
            {
              t = build_variant_type_copy (t);
              TYPE_NAME (t) = TYPE_NAME (type);
+             TYPE_ALIGN (t) = TYPE_ALIGN (type);
+             TYPE_USER_ALIGN (t) = TYPE_USER_ALIGN (type);
            }
        }
 
diff --git a/contrib/gcc-5.0/gcc/doc/avr-mmcu.texi b/contrib/gcc-5.0/gcc/doc/avr-mmcu.texi
deleted file mode 100644 (file)
index 1bda5c7..0000000
+++ /dev/null
@@ -1,79 +0,0 @@
-@c Copyright (C) 2012-2015 Free Software Foundation, Inc.
-@c This is part of the GCC manual.
-@c For copying conditions, see the file gcc/doc/include/fdl.texi.
-
-@c This file is generated automatically using
-@c gcc/config/avr/gen-avr-mmcu-texi.c from:
-@c    gcc/config/avr/avr-arch.h
-@c    gcc/config/avr/avr-devices.c
-@c    gcc/config/avr/avr-mcus.def
-
-@c Please do not edit manually.
-
-@table @code
-
-@item avr2
-``Classic'' devices with up to 8@tie{}KiB of program memory.
-@*@var{mcu}@tie{}= @code{attiny22}, @code{attiny26}, @code{at90c8534}, @code{at90s2313}, @code{at90s2323}, @code{at90s2333}, @code{at90s2343}, @code{at90s4414}, @code{at90s4433}, @code{at90s4434}, @code{at90s8515}, @code{at90s8535}.
-
-@item avr25
-``Classic'' devices with up to 8@tie{}KiB of program memory and with the @code{MOVW} instruction.
-@*@var{mcu}@tie{}= @code{ata5272}, @code{ata6616c}, @code{attiny13}, @code{attiny13a}, @code{attiny2313}, @code{attiny2313a}, @code{attiny24}, @code{attiny24a}, @code{attiny25}, @code{attiny261}, @code{attiny261a}, @code{attiny43u}, @code{attiny4313}, @code{attiny44}, @code{attiny44a}, @code{attiny441}, @code{attiny45}, @code{attiny461}, @code{attiny461a}, @code{attiny48}, @code{attiny828}, @code{attiny84}, @code{attiny84a}, @code{attiny841}, @code{attiny85}, @code{attiny861}, @code{attiny861a}, @code{attiny87}, @code{attiny88}, @code{at86rf401}.
-
-@item avr3
-``Classic'' devices with 16@tie{}KiB up to 64@tie{}KiB of  program memory.
-@*@var{mcu}@tie{}= @code{at43usb355}, @code{at76c711}.
-
-@item avr31
-``Classic'' devices with 128@tie{}KiB of program memory.
-@*@var{mcu}@tie{}= @code{atmega103}, @code{at43usb320}.
-
-@item avr35
-``Classic'' devices with 16@tie{}KiB up to 64@tie{}KiB of program memory and with the @code{MOVW} instruction.
-@*@var{mcu}@tie{}= @code{ata5505}, @code{ata6617c}, @code{ata664251}, @code{atmega16u2}, @code{atmega32u2}, @code{atmega8u2}, @code{attiny1634}, @code{attiny167}, @code{at90usb162}, @code{at90usb82}.
-
-@item avr4
-``Enhanced'' devices with up to 8@tie{}KiB of program memory.
-@*@var{mcu}@tie{}= @code{ata6285}, @code{ata6286}, @code{ata6289}, @code{ata6612c}, @code{atmega48}, @code{atmega48a}, @code{atmega48p}, @code{atmega48pa}, @code{atmega8}, @code{atmega8a}, @code{atmega8hva}, @code{atmega8515}, @code{atmega8535}, @code{atmega88}, @code{atmega88a}, @code{atmega88p}, @code{atmega88pa}, @code{at90pwm1}, @code{at90pwm2}, @code{at90pwm2b}, @code{at90pwm3}, @code{at90pwm3b}, @code{at90pwm81}.
-
-@item avr5
-``Enhanced'' devices with 16@tie{}KiB up to 64@tie{}KiB of program memory.
-@*@var{mcu}@tie{}= @code{ata5702m322}, @code{ata5782}, @code{ata5790}, @code{ata5790n}, @code{ata5795}, @code{ata5831}, @code{ata6613c}, @code{ata6614q}, @code{atmega16}, @code{atmega16a}, @code{atmega16hva}, @code{atmega16hva2}, @code{atmega16hvb}, @code{atmega16hvbrevb}, @code{atmega16m1}, @code{atmega16u4}, @code{atmega161}, @code{atmega162}, @code{atmega163}, @code{atmega164a}, @code{atmega164p}, @code{atmega164pa}, @code{atmega165}, @code{atmega165a}, @code{atmega165p}, @code{atmega165pa}, @code{atmega168}, @code{atmega168a}, @code{atmega168p}, @code{atmega168pa}, @code{atmega169}, @code{atmega169a}, @code{atmega169p}, @code{atmega169pa}, @code{atmega32}, @code{atmega32a}, @code{atmega32c1}, @code{atmega32hvb}, @code{atmega32hvbrevb}, @code{atmega32m1}, @code{atmega32u4}, @code{atmega32u6}, @code{atmega323}, @code{atmega324a}, @code{atmega324p}, @code{atmega324pa}, @code{atmega325}, @code{atmega325a}, @code{atmega325p}, @code{atmega325pa}, @code{atmega3250}, @code{atmega3250a}, @code{atmega3250p}, @code{atmega3250pa}, @code{atmega328}, @code{atmega328p}, @code{atmega329}, @code{atmega329a}, @code{atmega329p}, @code{atmega329pa}, @code{atmega3290}, @code{atmega3290a}, @code{atmega3290p}, @code{atmega3290pa}, @code{atmega406}, @code{atmega64}, @code{atmega64a}, @code{atmega64c1}, @code{atmega64hve}, @code{atmega64hve2}, @code{atmega64m1}, @code{atmega64rfr2}, @code{atmega640}, @code{atmega644}, @code{atmega644a}, @code{atmega644p}, @code{atmega644pa}, @code{atmega644rfr2}, @code{atmega645}, @code{atmega645a}, @code{atmega645p}, @code{atmega6450}, @code{atmega6450a}, @code{atmega6450p}, @code{atmega649}, @code{atmega649a}, @code{atmega649p}, @code{atmega6490}, @code{atmega6490a}, @code{atmega6490p}, @code{at90can32}, @code{at90can64}, @code{at90pwm161}, @code{at90pwm216}, @code{at90pwm316}, @code{at90scr100}, @code{at90usb646}, @code{at90usb647}, @code{at94k}, @code{m3000}.
-
-@item avr51
-``Enhanced'' devices with 128@tie{}KiB of program memory.
-@*@var{mcu}@tie{}= @code{atmega128}, @code{atmega128a}, @code{atmega128rfa1}, @code{atmega128rfr2}, @code{atmega1280}, @code{atmega1281}, @code{atmega1284}, @code{atmega1284p}, @code{atmega1284rfr2}, @code{at90can128}, @code{at90usb1286}, @code{at90usb1287}.
-
-@item avr6
-``Enhanced'' devices with 3-byte PC, i.e.@: with more than 128@tie{}KiB of program memory.
-@*@var{mcu}@tie{}= @code{atmega256rfr2}, @code{atmega2560}, @code{atmega2561}, @code{atmega2564rfr2}.
-
-@item avrxmega2
-``XMEGA'' devices with more than 8@tie{}KiB and up to 64@tie{}KiB of program memory.
-@*@var{mcu}@tie{}= @code{atxmega16a4}, @code{atxmega16a4u}, @code{atxmega16c4}, @code{atxmega16d4}, @code{atxmega16e5}, @code{atxmega32a4}, @code{atxmega32a4u}, @code{atxmega32c3}, @code{atxmega32c4}, @code{atxmega32d3}, @code{atxmega32d4}, @code{atxmega32e5}, @code{atxmega8e5}.
-
-@item avrxmega4
-``XMEGA'' devices with more than 64@tie{}KiB and up to 128@tie{}KiB of program memory.
-@*@var{mcu}@tie{}= @code{atxmega64a3}, @code{atxmega64a3u}, @code{atxmega64a4u}, @code{atxmega64b1}, @code{atxmega64b3}, @code{atxmega64c3}, @code{atxmega64d3}, @code{atxmega64d4}.
-
-@item avrxmega5
-``XMEGA'' devices with more than 64@tie{}KiB and up to 128@tie{}KiB of program memory and more than 64@tie{}KiB of RAM.
-@*@var{mcu}@tie{}= @code{atxmega64a1}, @code{atxmega64a1u}.
-
-@item avrxmega6
-``XMEGA'' devices with more than 128@tie{}KiB of program memory.
-@*@var{mcu}@tie{}= @code{atxmega128a3}, @code{atxmega128a3u}, @code{atxmega128b1}, @code{atxmega128b3}, @code{atxmega128c3}, @code{atxmega128d3}, @code{atxmega128d4}, @code{atxmega192a3}, @code{atxmega192a3u}, @code{atxmega192c3}, @code{atxmega192d3}, @code{atxmega256a3}, @code{atxmega256a3b}, @code{atxmega256a3bu}, @code{atxmega256a3u}, @code{atxmega256c3}, @code{atxmega256d3}, @code{atxmega384c3}, @code{atxmega384d3}.
-
-@item avrxmega7
-``XMEGA'' devices with more than 128@tie{}KiB of program memory and more than 64@tie{}KiB of RAM.
-@*@var{mcu}@tie{}= @code{atxmega128a1}, @code{atxmega128a1u}, @code{atxmega128a4u}.
-
-@item avrtiny
-``TINY'' Tiny core devices with 512@tie{}B up to 4@tie{}KiB of program memory.
-@*@var{mcu}@tie{}= @code{attiny10}, @code{attiny20}, @code{attiny4}, @code{attiny40}, @code{attiny5}, @code{attiny9}.
-
-@item avr1
-This ISA is implemented by the minimal AVR core and supported for assembler only.
-@*@var{mcu}@tie{}= @code{attiny11}, @code{attiny12}, @code{attiny15}, @code{attiny28}, @code{at90s1200}.
-
-@end table
diff --git a/contrib/gcc-5.0/gcc/doc/bugreport.texi b/contrib/gcc-5.0/gcc/doc/bugreport.texi
deleted file mode 100644 (file)
index 6e02534..0000000
+++ /dev/null
@@ -1,88 +0,0 @@
-@c Copyright (C) 1988-2015 Free Software Foundation, Inc.
-@c This is part of the GCC manual.
-@c For copying conditions, see the file gcc.texi.
-
-@node Bugs
-@chapter Reporting Bugs
-@cindex bugs
-@cindex reporting bugs
-
-Your bug reports play an essential role in making GCC reliable.
-
-When you encounter a problem, the first thing to do is to see if it is
-already known.  @xref{Trouble}.  If it isn't known, then you should
-report the problem.
-
-@menu
-* Criteria:  Bug Criteria.   Have you really found a bug?
-* Reporting: Bug Reporting.  How to report a bug effectively.
-@end menu
-
-@node Bug Criteria
-@section Have You Found a Bug?
-@cindex bug criteria
-
-If you are not sure whether you have found a bug, here are some guidelines:
-
-@itemize @bullet
-@cindex fatal signal
-@cindex core dump
-@item
-If the compiler gets a fatal signal, for any input whatever, that is a
-compiler bug.  Reliable compilers never crash.
-
-@cindex invalid assembly code
-@cindex assembly code, invalid
-@item
-If the compiler produces invalid assembly code, for any input whatever
-(except an @code{asm} statement), that is a compiler bug, unless the
-compiler reports errors (not just warnings) which would ordinarily
-prevent the assembler from being run.
-
-@cindex undefined behavior
-@cindex undefined function value
-@cindex increment operators
-@item
-If the compiler produces valid assembly code that does not correctly
-execute the input source code, that is a compiler bug.
-
-However, you must double-check to make sure, because you may have a
-program whose behavior is undefined, which happened by chance to give
-the desired results with another C or C++ compiler.
-
-For example, in many nonoptimizing compilers, you can write @samp{x;}
-at the end of a function instead of @samp{return x;}, with the same
-results.  But the value of the function is undefined if @code{return}
-is omitted; it is not a bug when GCC produces different results.
-
-Problems often result from expressions with two increment operators,
-as in @code{f (*p++, *p++)}.  Your previous compiler might have
-interpreted that expression the way you intended; GCC might
-interpret it another way.  Neither compiler is wrong.  The bug is
-in your code.
-
-After you have localized the error to a single source line, it should
-be easy to check for these things.  If your program is correct and
-well defined, you have found a compiler bug.
-
-@item
-If the compiler produces an error message for valid input, that is a
-compiler bug.
-
-@cindex invalid input
-@item
-If the compiler does not produce an error message for invalid input,
-that is a compiler bug.  However, you should note that your idea of
-``invalid input'' might be someone else's idea of ``an extension'' or
-``support for traditional practice''.
-
-@item
-If you are an experienced user of one of the languages GCC supports, your
-suggestions for improvement of GCC are welcome in any case.
-@end itemize
-
-@node Bug Reporting
-@section How and Where to Report Bugs
-@cindex compiler bugs, reporting
-
-Bugs should be reported to the bug database at @value{BUGURL}.
diff --git a/contrib/gcc-5.0/gcc/doc/cfg.texi b/contrib/gcc-5.0/gcc/doc/cfg.texi
deleted file mode 100644 (file)
index b77d9fa..0000000
+++ /dev/null
@@ -1,685 +0,0 @@
-@c -*-texinfo-*-
-@c Copyright (C) 2001-2015 Free Software Foundation, Inc.
-@c This is part of the GCC manual.
-@c For copying conditions, see the file gcc.texi.
-
-@c ---------------------------------------------------------------------
-@c Control Flow Graph
-@c ---------------------------------------------------------------------
-
-@node Control Flow
-@chapter Control Flow Graph
-@cindex CFG, Control Flow Graph
-@findex basic-block.h
-
-A control flow graph (CFG) is a data structure built on top of the
-intermediate code representation (the RTL or @code{GIMPLE} instruction
-stream) abstracting the control flow behavior of a function that is
-being compiled.  The CFG is a directed graph where the vertices
-represent basic blocks and edges represent possible transfer of
-control flow from one basic block to another.  The data structures
-used to represent the control flow graph are defined in
-@file{basic-block.h}.
-
-In GCC, the representation of control flow is maintained throughout
-the compilation process, from constructing the CFG early in 
-@code{pass_build_cfg} to @code{pass_free_cfg} (see @file{passes.def}).
-The CFG takes various different modes and may undergo extensive
-manipulations, but the graph is always valid between its construction
-and its release.  This way, transfer of information such as data flow,
-a measured profile, or the loop tree, can be propagated through the
-passes pipeline, and even from @code{GIMPLE} to @code{RTL}.
-
-Often the CFG may be better viewed as integral part of instruction
-chain, than structure built on the top of it.  Updating the compiler's
-intermediate representation for instructions can not be easily done
-without proper maintenance of the CFG simultaneously.
-
-@menu
-* Basic Blocks::           The definition and representation of basic blocks.
-* Edges::                  Types of edges and their representation.
-* Profile information::    Representation of frequencies and probabilities.
-* Maintaining the CFG::    Keeping the control flow graph and up to date.
-* Liveness information::   Using and maintaining liveness information.
-@end menu
-
-
-@node Basic Blocks
-@section Basic Blocks
-
-@cindex basic block
-@findex basic_block
-A basic block is a straight-line sequence of code with only one entry
-point and only one exit.  In GCC, basic blocks are represented using
-the @code{basic_block} data type.
-
-@findex ENTRY_BLOCK_PTR, EXIT_BLOCK_PTR
-Special basic blocks represent possible entry and exit points of a
-function.  These blocks are called @code{ENTRY_BLOCK_PTR} and
-@code{EXIT_BLOCK_PTR}.  These blocks do not contain any code.
-
-@findex BASIC_BLOCK
-The @code{BASIC_BLOCK} array contains all basic blocks in an
-unspecified order.  Each @code{basic_block} structure has a field
-that holds a unique integer identifier @code{index} that is the
-index of the block in the @code{BASIC_BLOCK} array.
-The total number of basic blocks in the function is
-@code{n_basic_blocks}.  Both the basic block indices and
-the total number of basic blocks may vary during the compilation
-process, as passes reorder, create, duplicate, and destroy basic
-blocks.  The index for any block should never be greater than
-@code{last_basic_block}.  The indices 0 and 1 are special codes
-reserved for @code{ENTRY_BLOCK} and @code{EXIT_BLOCK}, the
-indices of @code{ENTRY_BLOCK_PTR} and @code{EXIT_BLOCK_PTR}.
-
-@findex next_bb, prev_bb, FOR_EACH_BB, FOR_ALL_BB
-Two pointer members of the @code{basic_block} structure are the
-pointers @code{next_bb} and @code{prev_bb}.  These are used to keep
-doubly linked chain of basic blocks in the same order as the
-underlying instruction stream.  The chain of basic blocks is updated
-transparently by the provided API for manipulating the CFG@.  The macro
-@code{FOR_EACH_BB} can be used to visit all the basic blocks in
-lexicographical order, except @code{ENTRY_BLOCK} and @code{EXIT_BLOCK}.
-The macro @code{FOR_ALL_BB} also visits all basic blocks in
-lexicographical order, including @code{ENTRY_BLOCK} and @code{EXIT_BLOCK}.
-
-@findex post_order_compute, inverted_post_order_compute, walk_dominator_tree
-The functions @code{post_order_compute} and @code{inverted_post_order_compute}
-can be used to compute topological orders of the CFG.  The orders are
-stored as vectors of basic block indices.  The @code{BASIC_BLOCK} array
-can be used to iterate each basic block by index.
-Dominator traversals are also possible using
-@code{walk_dominator_tree}.  Given two basic blocks A and B, block A
-dominates block B if A is @emph{always} executed before B@.
-
-Each @code{basic_block} also contains pointers to the first
-instruction (the @dfn{head}) and the last instruction (the @dfn{tail})
-or @dfn{end} of the instruction stream contained in a basic block.  In
-fact, since the @code{basic_block} data type is used to represent
-blocks in both major intermediate representations of GCC (@code{GIMPLE}
-and RTL), there are pointers to the head and end of a basic block for
-both representations, stored in intermediate representation specific
-data in the @code{il} field of @code{struct basic_block_def}.
-
-@findex CODE_LABEL
-@findex NOTE_INSN_BASIC_BLOCK
-For RTL, these pointers are @code{BB_HEAD} and @code{BB_END}.
-
-@cindex insn notes, notes
-@findex NOTE_INSN_BASIC_BLOCK
-In the RTL representation of a function, the instruction stream
-contains not only the ``real'' instructions, but also @dfn{notes}
-or @dfn{insn notes} (to distinguish them from @dfn{reg notes}).
-Any function that moves or duplicates the basic blocks needs
-to take care of updating of these notes.  Many of these notes expect
-that the instruction stream consists of linear regions, so updating
-can sometimes be tedious.  All types of insn notes are defined
-in @file{insn-notes.def}.
-
-In the RTL function representation, the instructions contained in a
-basic block always follow a @code{NOTE_INSN_BASIC_BLOCK}, but zero
-or more @code{CODE_LABEL} nodes can precede the block note.
-A basic block ends with a control flow instruction or with the last
-instruction before the next @code{CODE_LABEL} or
-@code{NOTE_INSN_BASIC_BLOCK}.
-By definition, a @code{CODE_LABEL} cannot appear in the middle of
-the instruction stream of a basic block.
-
-@findex can_fallthru
-@cindex table jump
-In addition to notes, the jump table vectors are also represented as
-``pseudo-instructions'' inside the insn stream.  These vectors never
-appear in the basic block and should always be placed just after the
-table jump instructions referencing them.  After removing the
-table-jump it is often difficult to eliminate the code computing the
-address and referencing the vector, so cleaning up these vectors is
-postponed until after liveness analysis.   Thus the jump table vectors
-may appear in the insn stream unreferenced and without any purpose.
-Before any edge is made @dfn{fall-thru}, the existence of such
-construct in the way needs to be checked by calling
-@code{can_fallthru} function.
-
-@cindex GIMPLE statement iterators
-For the @code{GIMPLE} representation, the PHI nodes and statements
-contained in a basic block are in a @code{gimple_seq} pointed to by
-the basic block intermediate language specific pointers.
-Abstract containers and iterators are used to access the PHI nodes
-and statements in a basic blocks.  These iterators are called
-@dfn{GIMPLE statement iterators} (GSIs).  Grep for @code{^gsi}
-in the various @file{gimple-*} and @file{tree-*} files.
-There is a @code{gimple_stmt_iterator} type for iterating over
-all kinds of statement, and a @code{gphi_iterator} subclass for
-iterating over PHI nodes.
-The following snippet will pretty-print all PHI nodes the statements
-of the current function in the GIMPLE representation.
-
-@smallexample
-basic_block bb;
-
-FOR_EACH_BB (bb)
-  @{
-   gphi_iterator pi;
-   gimple_stmt_iterator si;
-
-   for (pi = gsi_start_phis (bb); !gsi_end_p (pi); gsi_next (&pi))
-     @{
-       gphi *phi = pi.phi ();
-       print_gimple_stmt (dump_file, phi, 0, TDF_SLIM);
-     @}
-   for (si = gsi_start_bb (bb); !gsi_end_p (si); gsi_next (&si))
-     @{
-       gimple stmt = gsi_stmt (si);
-       print_gimple_stmt (dump_file, stmt, 0, TDF_SLIM);
-     @}
-  @}
-@end smallexample
-
-
-@node Edges
-@section Edges
-
-@cindex edge in the flow graph
-@findex edge
-Edges represent possible control flow transfers from the end of some
-basic block A to the head of another basic block B@.  We say that A is
-a predecessor of B, and B is a successor of A@.  Edges are represented
-in GCC with the @code{edge} data type.  Each @code{edge} acts as a
-link between two basic blocks: The @code{src} member of an edge
-points to the predecessor basic block of the @code{dest} basic block.
-The members @code{preds} and @code{succs} of the @code{basic_block} data
-type point to type-safe vectors of edges to the predecessors and
-successors of the block.
-
-@cindex edge iterators
-When walking the edges in an edge vector, @dfn{edge iterators} should
-be used.  Edge iterators are constructed using the
-@code{edge_iterator} data structure and several methods are available
-to operate on them:
-
-@ftable @code
-@item ei_start
-This function initializes an @code{edge_iterator} that points to the
-first edge in a vector of edges.
-
-@item ei_last
-This function initializes an @code{edge_iterator} that points to the
-last edge in a vector of edges.
-
-@item ei_end_p
-This predicate is @code{true} if an @code{edge_iterator} represents
-the last edge in an edge vector.
-
-@item ei_one_before_end_p
-This predicate is @code{true} if an @code{edge_iterator} represents
-the second last edge in an edge vector.
-
-@item ei_next
-This function takes a pointer to an @code{edge_iterator} and makes it
-point to the next edge in the sequence.
-
-@item ei_prev
-This function takes a pointer to an @code{edge_iterator} and makes it
-point to the previous edge in the sequence.
-
-@item ei_edge
-This function returns the @code{edge} currently pointed to by an
-@code{edge_iterator}.
-
-@item ei_safe_safe
-This function returns the @code{edge} currently pointed to by an
-@code{edge_iterator}, but returns @code{NULL} if the iterator is
-pointing at the end of the sequence.  This function has been provided
-for existing code makes the assumption that a @code{NULL} edge
-indicates the end of the sequence.
-
-@end ftable
-
-The convenience macro @code{FOR_EACH_EDGE} can be used to visit all of
-the edges in a sequence of predecessor or successor edges.  It must
-not be used when an element might be removed during the traversal,
-otherwise elements will be missed.  Here is an example of how to use
-the macro:
-
-@smallexample
-edge e;
-edge_iterator ei;
-
-FOR_EACH_EDGE (e, ei, bb->succs)
-  @{
-     if (e->flags & EDGE_FALLTHRU)
-       break;
-  @}
-@end smallexample
-
-@findex fall-thru
-There are various reasons why control flow may transfer from one block
-to another.  One possibility is that some instruction, for example a
-@code{CODE_LABEL}, in a linearized instruction stream just always
-starts a new basic block.  In this case a @dfn{fall-thru} edge links
-the basic block to the first following basic block.  But there are
-several other reasons why edges may be created.  The @code{flags}
-field of the @code{edge} data type is used to store information
-about the type of edge we are dealing with.  Each edge is of one of
-the following types:
-
-@table @emph
-@item jump
-No type flags are set for edges corresponding to jump instructions.
-These edges are used for unconditional or conditional jumps and in
-RTL also for table jumps.  They are the easiest to manipulate as they
-may be freely redirected when the flow graph is not in SSA form.
-
-@item fall-thru
-@findex EDGE_FALLTHRU, force_nonfallthru
-Fall-thru edges are present in case where the basic block may continue
-execution to the following one without branching.  These edges have
-the @code{EDGE_FALLTHRU} flag set.  Unlike other types of edges, these
-edges must come into the basic block immediately following in the
-instruction stream.  The function @code{force_nonfallthru} is
-available to insert an unconditional jump in the case that redirection
-is needed.  Note that this may require creation of a new basic block.
-
-@item exception handling
-@cindex exception handling
-@findex EDGE_ABNORMAL, EDGE_EH
-Exception handling edges represent possible control transfers from a
-trapping instruction to an exception handler.  The definition of
-``trapping'' varies.  In C++, only function calls can throw, but for
-Java and Ada, exceptions like division by zero or segmentation fault are
-defined and thus each instruction possibly throwing this kind of
-exception needs to be handled as control flow instruction.  Exception
-edges have the @code{EDGE_ABNORMAL} and @code{EDGE_EH} flags set.
-
-@findex purge_dead_edges
-When updating the instruction stream it is easy to change possibly
-trapping instruction to non-trapping, by simply removing the exception
-edge.  The opposite conversion is difficult, but should not happen
-anyway.  The edges can be eliminated via @code{purge_dead_edges} call.
-
-@findex REG_EH_REGION, EDGE_ABNORMAL_CALL
-In the RTL representation, the destination of an exception edge is
-specified by @code{REG_EH_REGION} note attached to the insn.
-In case of a trapping call the @code{EDGE_ABNORMAL_CALL} flag is set
-too.  In the @code{GIMPLE} representation, this extra flag is not set.
-
-@findex may_trap_p, tree_could_trap_p
-In the RTL representation, the predicate @code{may_trap_p} may be used
-to check whether instruction still may trap or not.  For the tree
-representation, the @code{tree_could_trap_p} predicate is available,
-but this predicate only checks for possible memory traps, as in
-dereferencing an invalid pointer location.
-
-
-@item sibling calls
-@cindex sibling call
-@findex EDGE_ABNORMAL, EDGE_SIBCALL
-Sibling calls or tail calls terminate the function in a non-standard
-way and thus an edge to the exit must be present.
-@code{EDGE_SIBCALL} and @code{EDGE_ABNORMAL} are set in such case.
-These edges only exist in the RTL representation.
-
-@item computed jumps
-@cindex computed jump
-@findex EDGE_ABNORMAL
-Computed jumps contain edges to all labels in the function referenced
-from the code.  All those edges have @code{EDGE_ABNORMAL} flag set.
-The edges used to represent computed jumps often cause compile time
-performance problems, since functions consisting of many taken labels
-and many computed jumps may have @emph{very} dense flow graphs, so
-these edges need to be handled with special care.  During the earlier
-stages of the compilation process, GCC tries to avoid such dense flow
-graphs by factoring computed jumps.  For example, given the following
-series of jumps,
-
-@smallexample
-  goto *x;
-  [ @dots{} ]
-
-  goto *x;
-  [ @dots{} ]
-
-  goto *x;
-  [ @dots{} ]
-@end smallexample
-
-@noindent
-factoring the computed jumps results in the following code sequence
-which has a much simpler flow graph:
-
-@smallexample
-  goto y;
-  [ @dots{} ]
-
-  goto y;
-  [ @dots{} ]
-
-  goto y;
-  [ @dots{} ]
-
-y:
-  goto *x;
-@end smallexample
-
-@findex pass_duplicate_computed_gotos
-However, the classic problem with this transformation is that it has a
-runtime cost in there resulting code: An extra jump.  Therefore, the
-computed jumps are un-factored in the later passes of the compiler
-(in the pass called @code{pass_duplicate_computed_gotos}).
-Be aware of that when you work on passes in that area.  There have
-been numerous examples already where the compile time for code with
-unfactored computed jumps caused some serious headaches.
-
-@item nonlocal goto handlers
-@cindex nonlocal goto handler
-@findex EDGE_ABNORMAL, EDGE_ABNORMAL_CALL
-GCC allows nested functions to return into caller using a @code{goto}
-to a label passed to as an argument to the callee.  The labels passed
-to nested functions contain special code to cleanup after function
-call.  Such sections of code are referred to as ``nonlocal goto
-receivers''.  If a function contains such nonlocal goto receivers, an
-edge from the call to the label is created with the
-@code{EDGE_ABNORMAL} and @code{EDGE_ABNORMAL_CALL} flags set.
-
-@item function entry points
-@cindex function entry point, alternate function entry point
-@findex LABEL_ALTERNATE_NAME
-By definition, execution of function starts at basic block 0, so there
-is always an edge from the @code{ENTRY_BLOCK_PTR} to basic block 0.
-There is no @code{GIMPLE} representation for alternate entry points at
-this moment.  In RTL, alternate entry points are specified by
-@code{CODE_LABEL} with @code{LABEL_ALTERNATE_NAME} defined.  This
-feature is currently used for multiple entry point prologues and is
-limited to post-reload passes only.  This can be used by back-ends to
-emit alternate prologues for functions called from different contexts.
-In future full support for multiple entry functions defined by Fortran
-90 needs to be implemented.
-
-@item function exits
-In the pre-reload representation a function terminates after the last
-instruction in the insn chain and no explicit return instructions are
-used.  This corresponds to the fall-thru edge into exit block.  After
-reload, optimal RTL epilogues are used that use explicit (conditional)
-return instructions that are represented by edges with no flags set.
-
-@end table
-
-
-@node Profile information
-@section Profile information
-
-@cindex profile representation
-In many cases a compiler must make a choice whether to trade speed in
-one part of code for speed in another, or to trade code size for code
-speed.  In such cases it is useful to know information about how often
-some given block will be executed.  That is the purpose for
-maintaining profile within the flow graph.
-GCC can handle profile information obtained through @dfn{profile
-feedback}, but it can also estimate branch probabilities based on
-statics and heuristics.
-
-@cindex profile feedback
-The feedback based profile is produced by compiling the program with
-instrumentation, executing it on a train run and reading the numbers
-of executions of basic blocks and edges back to the compiler while
-re-compiling the program to produce the final executable.  This method
-provides very accurate information about where a program spends most
-of its time on the train run.  Whether it matches the average run of
-course depends on the choice of train data set, but several studies
-have shown that the behavior of a program usually changes just
-marginally over different data sets.
-
-@cindex Static profile estimation
-@cindex branch prediction
-@findex predict.def
-When profile feedback is not available, the compiler may be asked to
-attempt to predict the behavior of each branch in the program using a
-set of heuristics (see @file{predict.def} for details) and compute
-estimated frequencies of each basic block by propagating the
-probabilities over the graph.
-
-@findex frequency, count, BB_FREQ_BASE
-Each @code{basic_block} contains two integer fields to represent
-profile information: @code{frequency} and @code{count}.  The
-@code{frequency} is an estimation how often is basic block executed
-within a function.  It is represented as an integer scaled in the
-range from 0 to @code{BB_FREQ_BASE}.  The most frequently executed
-basic block in function is initially set to @code{BB_FREQ_BASE} and
-the rest of frequencies are scaled accordingly.  During optimization,
-the frequency of the most frequent basic block can both decrease (for
-instance by loop unrolling) or grow (for instance by cross-jumping
-optimization), so scaling sometimes has to be performed multiple
-times.
-
-@findex gcov_type
-The @code{count} contains hard-counted numbers of execution measured
-during training runs and is nonzero only when profile feedback is
-available.  This value is represented as the host's widest integer
-(typically a 64 bit integer) of the special type @code{gcov_type}.
-
-Most optimization passes can use only the frequency information of a
-basic block, but a few passes may want to know hard execution counts.
-The frequencies should always match the counts after scaling, however
-during updating of the profile information numerical error may
-accumulate into quite large errors.
-
-@findex REG_BR_PROB_BASE, EDGE_FREQUENCY
-Each edge also contains a branch probability field: an integer in the
-range from 0 to @code{REG_BR_PROB_BASE}.  It represents probability of
-passing control from the end of the @code{src} basic block to the
-@code{dest} basic block, i.e.@: the probability that control will flow
-along this edge.  The @code{EDGE_FREQUENCY} macro is available to
-compute how frequently a given edge is taken.  There is a @code{count}
-field for each edge as well, representing same information as for a
-basic block.
-
-The basic block frequencies are not represented in the instruction
-stream, but in the RTL representation the edge frequencies are
-represented for conditional jumps (via the @code{REG_BR_PROB}
-macro) since they are used when instructions are output to the
-assembly file and the flow graph is no longer maintained.
-
-@cindex reverse probability
-The probability that control flow arrives via a given edge to its
-destination basic block is called @dfn{reverse probability} and is not
-directly represented, but it may be easily computed from frequencies
-of basic blocks.
-
-@findex redirect_edge_and_branch
-Updating profile information is a delicate task that can unfortunately
-not be easily integrated with the CFG manipulation API@.  Many of the
-functions and hooks to modify the CFG, such as
-@code{redirect_edge_and_branch}, do not have enough information to
-easily update the profile, so updating it is in the majority of cases
-left up to the caller.  It is difficult to uncover bugs in the profile
-updating code, because they manifest themselves only by producing
-worse code, and checking profile consistency is not possible because
-of numeric error accumulation.  Hence special attention needs to be
-given to this issue in each pass that modifies the CFG@.
-
-@findex REG_BR_PROB_BASE, BB_FREQ_BASE, count
-It is important to point out that @code{REG_BR_PROB_BASE} and
-@code{BB_FREQ_BASE} are both set low enough to be possible to compute
-second power of any frequency or probability in the flow graph, it is
-not possible to even square the @code{count} field, as modern CPUs are
-fast enough to execute $2^32$ operations quickly.
-
-
-@node Maintaining the CFG
-@section Maintaining the CFG
-@findex cfghooks.h
-
-An important task of each compiler pass is to keep both the control
-flow graph and all profile information up-to-date.  Reconstruction of
-the control flow graph after each pass is not an option, since it may be
-very expensive and lost profile information cannot be reconstructed at
-all.
-
-GCC has two major intermediate representations, and both use the
-@code{basic_block} and @code{edge} data types to represent control
-flow.  Both representations share as much of the CFG maintenance code
-as possible.  For each representation, a set of @dfn{hooks} is defined
-so that each representation can provide its own implementation of CFG
-manipulation routines when necessary.  These hooks are defined in
-@file{cfghooks.h}.  There are hooks for almost all common CFG
-manipulations, including block splitting and merging, edge redirection
-and creating and deleting basic blocks.  These hooks should provide
-everything you need to maintain and manipulate the CFG in both the RTL
-and @code{GIMPLE} representation.
-
-At the moment, the basic block boundaries are maintained transparently
-when modifying instructions, so there rarely is a need to move them
-manually (such as in case someone wants to output instruction outside
-basic block explicitly).
-
-@findex BLOCK_FOR_INSN, gimple_bb
-In the RTL representation, each instruction has a
-@code{BLOCK_FOR_INSN} value that represents pointer to the basic block
-that contains the instruction.  In the @code{GIMPLE} representation, the
-function @code{gimple_bb} returns a pointer to the basic block
-containing the queried statement.
-
-@cindex GIMPLE statement iterators
-When changes need to be applied to a function in its @code{GIMPLE}
-representation, @dfn{GIMPLE statement iterators} should be used.  These
-iterators provide an integrated abstraction of the flow graph and the
-instruction stream.  Block statement iterators are constructed using
-the @code{gimple_stmt_iterator} data structure and several modifier are
-available, including the following:
-
-@ftable @code
-@item gsi_start
-This function initializes a @code{gimple_stmt_iterator} that points to
-the first non-empty statement in a basic block.
-
-@item gsi_last
-This function initializes a @code{gimple_stmt_iterator} that points to
-the last statement in a basic block.
-
-@item gsi_end_p
-This predicate is @code{true} if a @code{gimple_stmt_iterator}
-represents the end of a basic block.
-
-@item gsi_next
-This function takes a @code{gimple_stmt_iterator} and makes it point to
-its successor.
-
-@item gsi_prev
-This function takes a @code{gimple_stmt_iterator} and makes it point to
-its predecessor.
-
-@item gsi_insert_after
-This function inserts a statement after the @code{gimple_stmt_iterator}
-passed in.  The final parameter determines whether the statement
-iterator is updated to point to the newly inserted statement, or left
-pointing to the original statement.
-
-@item gsi_insert_before
-This function inserts a statement before the @code{gimple_stmt_iterator}
-passed in.  The final parameter determines whether the statement
-iterator is updated to point to the newly inserted statement, or left
-pointing to the original  statement.
-
-@item gsi_remove
-This function removes the @code{gimple_stmt_iterator} passed in and
-rechains the remaining statements in a basic block, if any.
-@end ftable
-
-@findex BB_HEAD, BB_END
-In the RTL representation, the macros @code{BB_HEAD} and @code{BB_END}
-may be used to get the head and end @code{rtx} of a basic block.  No
-abstract iterators are defined for traversing the insn chain, but you
-can just use @code{NEXT_INSN} and @code{PREV_INSN} instead.  @xref{Insns}.
-
-@findex purge_dead_edges
-Usually a code manipulating pass simplifies the instruction stream and
-the flow of control, possibly eliminating some edges.  This may for
-example happen when a conditional jump is replaced with an
-unconditional jump, but also when simplifying possibly trapping
-instruction to non-trapping while compiling Java.  Updating of edges
-is not transparent and each optimization pass is required to do so
-manually.  However only few cases occur in practice.  The pass may
-call @code{purge_dead_edges} on a given basic block to remove
-superfluous edges, if any.
-
-@findex redirect_edge_and_branch, redirect_jump
-Another common scenario is redirection of branch instructions, but
-this is best modeled as redirection of edges in the control flow graph
-and thus use of @code{redirect_edge_and_branch} is preferred over more
-low level functions, such as @code{redirect_jump} that operate on RTL
-chain only.  The CFG hooks defined in @file{cfghooks.h} should provide
-the complete API required for manipulating and maintaining the CFG@.
-
-@findex split_block
-It is also possible that a pass has to insert control flow instruction
-into the middle of a basic block, thus creating an entry point in the
-middle of the basic block, which is impossible by definition: The
-block must be split to make sure it only has one entry point, i.e.@: the
-head of the basic block.  The CFG hook @code{split_block} may be used
-when an instruction in the middle of a basic block has to become the
-target of a jump or branch instruction.
-
-@findex insert_insn_on_edge
-@findex commit_edge_insertions
-@findex gsi_insert_on_edge
-@findex gsi_commit_edge_inserts
-@cindex edge splitting
-For a global optimizer, a common operation is to split edges in the
-flow graph and insert instructions on them.  In the RTL
-representation, this can be easily done using the
-@code{insert_insn_on_edge} function that emits an instruction
-``on the edge'', caching it for a later @code{commit_edge_insertions}
-call that will take care of moving the inserted instructions off the
-edge into the instruction stream contained in a basic block.  This
-includes the creation of new basic blocks where needed.  In the
-@code{GIMPLE} representation, the equivalent functions are
-@code{gsi_insert_on_edge} which inserts a block statement
-iterator on an edge, and @code{gsi_commit_edge_inserts} which flushes
-the instruction to actual instruction stream.
-
-@findex verify_flow_info
-@cindex CFG verification
-While debugging the optimization pass, the @code{verify_flow_info}
-function may be useful to find bugs in the control flow graph updating
-code.
-
-
-@node Liveness information
-@section Liveness information
-@cindex Liveness representation
-Liveness information is useful to determine whether some register is
-``live'' at given point of program, i.e.@: that it contains a value that
-may be used at a later point in the program.  This information is
-used, for instance, during register allocation, as the pseudo
-registers only need to be assigned to a unique hard register or to a
-stack slot if they are live.  The hard registers and stack slots may
-be freely reused for other values when a register is dead.
-
-Liveness information is available in the back end starting with
-@code{pass_df_initialize} and ending with @code{pass_df_finish}.  Three
-flavors of live analysis are available: With @code{LR}, it is possible
-to determine at any point @code{P} in the function if the register may be
-used on some path from @code{P} to the end of the function.  With
-@code{UR}, it is possible to determine if there is a path from the
-beginning of the function to @code{P} that defines the variable.
-@code{LIVE} is the intersection of the @code{LR} and @code{UR} and a
-variable is live at @code{P} if there is both an assignment that reaches
-it from the beginning of the function and a use that can be reached on
-some path from @code{P} to the end of the function.
-
-In general @code{LIVE} is the most useful of the three.  The macros
-@code{DF_[LR,UR,LIVE]_[IN,OUT]} can be used to access this information.
-The macros take a basic block number and return a bitmap that is indexed
-by the register number.  This information is only guaranteed to be up to
-date after calls are made to @code{df_analyze}.  See the file
-@code{df-core.c} for details on using the dataflow.
-
-
-@findex REG_DEAD, REG_UNUSED
-The liveness information is stored partly in the RTL instruction stream
-and partly in the flow graph.  Local information is stored in the
-instruction stream: Each instruction may contain @code{REG_DEAD} notes
-representing that the value of a given register is no longer needed, or
-@code{REG_UNUSED} notes representing that the value computed by the
-instruction is never used.  The second is useful for instructions
-computing multiple values at once.
-
diff --git a/contrib/gcc-5.0/gcc/doc/collect2.texi b/contrib/gcc-5.0/gcc/doc/collect2.texi
deleted file mode 100644 (file)
index f3ebace..0000000
+++ /dev/null
@@ -1,89 +0,0 @@
-@c Copyright (C) 1988-2015 Free Software Foundation, Inc.
-@c This is part of the GCC manual.
-@c For copying conditions, see the file gcc.texi.
-
-@node Collect2
-@chapter @code{collect2}
-
-GCC uses a utility called @code{collect2} on nearly all systems to arrange
-to call various initialization functions at start time.
-
-The program @code{collect2} works by linking the program once and
-looking through the linker output file for symbols with particular names
-indicating they are constructor functions.  If it finds any, it
-creates a new temporary @samp{.c} file containing a table of them,
-compiles it, and links the program a second time including that file.
-
-@findex __main
-@cindex constructors, automatic calls
-The actual calls to the constructors are carried out by a subroutine
-called @code{__main}, which is called (automatically) at the beginning
-of the body of @code{main} (provided @code{main} was compiled with GNU
-CC)@.  Calling @code{__main} is necessary, even when compiling C code, to
-allow linking C and C++ object code together.  (If you use
-@option{-nostdlib}, you get an unresolved reference to @code{__main},
-since it's defined in the standard GCC library.  Include @option{-lgcc} at
-the end of your compiler command line to resolve this reference.)
-
-The program @code{collect2} is installed as @code{ld} in the directory
-where the passes of the compiler are installed.  When @code{collect2}
-needs to find the @emph{real} @code{ld}, it tries the following file
-names:
-
-@itemize @bullet
-@item
-a hard coded linker file name, if GCC was configured with the
-@option{--with-ld} option.
-
-@item
-@file{real-ld} in the directories listed in the compiler's search
-directories.
-
-@item
-@file{real-ld} in the directories listed in the environment variable
-@code{PATH}.
-
-@item
-The file specified in the @code{REAL_LD_FILE_NAME} configuration macro,
-if specified.
-
-@item
-@file{ld} in the compiler's search directories, except that
-@code{collect2} will not execute itself recursively.
-
-@item
-@file{ld} in @code{PATH}.
-@end itemize
-
-``The compiler's search directories'' means all the directories where
-@command{gcc} searches for passes of the compiler.  This includes
-directories that you specify with @option{-B}.
-
-Cross-compilers search a little differently:
-
-@itemize @bullet
-@item
-@file{real-ld} in the compiler's search directories.
-
-@item
-@file{@var{target}-real-ld} in @code{PATH}.
-
-@item
-The file specified in the @code{REAL_LD_FILE_NAME} configuration macro,
-if specified.
-
-@item
-@file{ld} in the compiler's search directories.
-
-@item
-@file{@var{target}-ld} in @code{PATH}.
-@end itemize
-
-@code{collect2} explicitly avoids running @code{ld} using the file name
-under which @code{collect2} itself was invoked.  In fact, it remembers
-up a list of such names---in case one copy of @code{collect2} finds
-another copy (or version) of @code{collect2} installed as @code{ld} in a
-second place in the search path.
-
-@code{collect2} searches for the utilities @code{nm} and @code{strip}
-using the same algorithm as above for @code{ld}.
diff --git a/contrib/gcc-5.0/gcc/doc/compat.texi b/contrib/gcc-5.0/gcc/doc/compat.texi
deleted file mode 100644 (file)
index c4c899a..0000000
+++ /dev/null
@@ -1,156 +0,0 @@
-@c Copyright (C) 2002-2015 Free Software Foundation, Inc.
-@c This is part of the GCC manual.
-@c For copying conditions, see the file gcc.texi.
-
-@node Compatibility
-@chapter Binary Compatibility
-@cindex binary compatibility
-@cindex ABI
-@cindex application binary interface
-
-Binary compatibility encompasses several related concepts:
-
-@table @dfn
-@item application binary interface (ABI)
-The set of runtime conventions followed by all of the tools that deal
-with binary representations of a program, including compilers, assemblers,
-linkers, and language runtime support.
-Some ABIs are formal with a written specification, possibly designed
-by multiple interested parties.  Others are simply the way things are
-actually done by a particular set of tools.
-
-@item ABI conformance
-A compiler conforms to an ABI if it generates code that follows all of
-the specifications enumerated by that ABI@.
-A library conforms to an ABI if it is implemented according to that ABI@.
-An application conforms to an ABI if it is built using tools that conform
-to that ABI and does not contain source code that specifically changes
-behavior specified by the ABI@.
-
-@item calling conventions
-Calling conventions are a subset of an ABI that specify of how arguments
-are passed and function results are returned.
-
-@item interoperability
-Different sets of tools are interoperable if they generate files that
-can be used in the same program.  The set of tools includes compilers,
-assemblers, linkers, libraries, header files, startup files, and debuggers.
-Binaries produced by different sets of tools are not interoperable unless
-they implement the same ABI@.  This applies to different versions of the
-same tools as well as tools from different vendors.
-
-@item intercallability
-Whether a function in a binary built by one set of tools can call a
-function in a binary built by a different set of tools is a subset
-of interoperability.
-
-@item implementation-defined features
-Language standards include lists of implementation-defined features whose
-behavior can vary from one implementation to another.  Some of these
-features are normally covered by a platform's ABI and others are not.
-The features that are not covered by an ABI generally affect how a
-program behaves, but not intercallability.
-
-@item compatibility
-Conformance to the same ABI and the same behavior of implementation-defined
-features are both relevant for compatibility.
-@end table
-
-The application binary interface implemented by a C or C++ compiler
-affects code generation and runtime support for:
-
-@itemize @bullet
-@item
-size and alignment of data types
-@item
-layout of structured types
-@item
-calling conventions
-@item
-register usage conventions
-@item
-interfaces for runtime arithmetic support
-@item
-object file formats
-@end itemize
-
-In addition, the application binary interface implemented by a C++ compiler
-affects code generation and runtime support for:
-@itemize @bullet
-@item
-name mangling
-@item
-exception handling
-@item
-invoking constructors and destructors
-@item
-layout, alignment, and padding of classes
-@item
-layout and alignment of virtual tables
-@end itemize
-
-Some GCC compilation options cause the compiler to generate code that
-does not conform to the platform's default ABI@.  Other options cause
-different program behavior for implementation-defined features that are
-not covered by an ABI@.  These options are provided for consistency with
-other compilers that do not follow the platform's default ABI or the
-usual behavior of implementation-defined features for the platform.
-Be very careful about using such options.
-
-Most platforms have a well-defined ABI that covers C code, but ABIs
-that cover C++ functionality are not yet common.
-
-Starting with GCC 3.2, GCC binary conventions for C++ are based on a
-written, vendor-neutral C++ ABI that was designed to be specific to
-64-bit Itanium but also includes generic specifications that apply to
-any platform.
-This C++ ABI is also implemented by other compiler vendors on some
-platforms, notably GNU/Linux and BSD systems.
-We have tried hard to provide a stable ABI that will be compatible with
-future GCC releases, but it is possible that we will encounter problems
-that make this difficult.  Such problems could include different
-interpretations of the C++ ABI by different vendors, bugs in the ABI, or
-bugs in the implementation of the ABI in different compilers.
-GCC's @option{-Wabi} switch warns when G++ generates code that is
-probably not compatible with the C++ ABI@.
-
-The C++ library used with a C++ compiler includes the Standard C++
-Library, with functionality defined in the C++ Standard, plus language
-runtime support.  The runtime support is included in a C++ ABI, but there
-is no formal ABI for the Standard C++ Library.  Two implementations
-of that library are interoperable if one follows the de-facto ABI of the
-other and if they are both built with the same compiler, or with compilers
-that conform to the same ABI for C++ compiler and runtime support.
-
-When G++ and another C++ compiler conform to the same C++ ABI, but the
-implementations of the Standard C++ Library that they normally use do not
-follow the same ABI for the Standard C++ Library, object files built with
-those compilers can be used in the same program only if they use the same
-C++ library.  This requires specifying the location of the C++ library
-header files when invoking the compiler whose usual library is not being
-used.  The location of GCC's C++ header files depends on how the GCC
-build was configured, but can be seen by using the G++ @option{-v} option.
-With default configuration options for G++ 3.3 the compile line for a
-different C++ compiler needs to include
-
-@smallexample
-    -I@var{gcc_install_directory}/include/c++/3.3
-@end smallexample
-
-Similarly, compiling code with G++ that must use a C++ library other
-than the GNU C++ library requires specifying the location of the header
-files for that other library.
-
-The most straightforward way to link a program to use a particular
-C++ library is to use a C++ driver that specifies that C++ library by
-default.  The @command{g++} driver, for example, tells the linker where
-to find GCC's C++ library (@file{libstdc++}) plus the other libraries
-and startup files it needs, in the proper order.
-
-If a program must use a different C++ library and it's not possible
-to do the final link using a C++ driver that uses that library by default,
-it is necessary to tell @command{g++} the location and name of that
-library.  It might also be necessary to specify different startup files
-and other runtime support libraries, and to suppress the use of GCC's
-support libraries with one or more of the options @option{-nostdlib},
-@option{-nostartfiles}, and @option{-nodefaultlibs}.
diff --git a/contrib/gcc-5.0/gcc/doc/configfiles.texi b/contrib/gcc-5.0/gcc/doc/configfiles.texi
deleted file mode 100644 (file)
index 4bfd5ec..0000000
+++ /dev/null
@@ -1,71 +0,0 @@
-@c Copyright (C) 1988-2015 Free Software Foundation, Inc.
-@c This is part of the GCC manual.
-@c For copying conditions, see the file gcc.texi.
-
-@node Configuration Files
-@subsubsection Files Created by @code{configure}
-
-Here we spell out what files will be set up by @file{configure} in the
-@file{gcc} directory.  Some other files are created as temporary files
-in the configuration process, and are not used in the subsequent
-build; these are not documented.
-
-@itemize @bullet
-@item
-@file{Makefile} is constructed from @file{Makefile.in}, together with
-the host and target fragments (@pxref{Fragments, , Makefile
-Fragments}) @file{t-@var{target}} and @file{x-@var{host}} from
-@file{config}, if any, and language Makefile fragments
-@file{@var{language}/Make-lang.in}.
-@item
-@file{auto-host.h} contains information about the host machine
-determined by @file{configure}.  If the host machine is different from
-the build machine, then @file{auto-build.h} is also created,
-containing such information about the build machine.
-@item
-@file{config.status} is a script that may be run to recreate the
-current configuration.
-@item
-@file{configargs.h} is a header containing details of the arguments
-passed to @file{configure} to configure GCC, and of the thread model
-used.
-@item
-@file{cstamp-h} is used as a timestamp.
-@item
-If a language @file{config-lang.in} file (@pxref{Front End Config, ,
-The Front End @file{config-lang.in} File}) sets @code{outputs}, then
-the files listed in @code{outputs} there are also generated.
-@end itemize
-
-The following configuration headers are created from the Makefile,
-using @file{mkconfig.sh}, rather than directly by @file{configure}.
-@file{config.h}, @file{bconfig.h} and @file{tconfig.h} all contain the
-@file{xm-@var{machine}.h} header, if any, appropriate to the host,
-build and target machines respectively, the configuration headers for
-the target, and some definitions; for the host and build machines,
-these include the autoconfigured headers generated by
-@file{configure}.  The other configuration headers are determined by
-@file{config.gcc}.  They also contain the typedefs for @code{rtx},
-@code{rtvec} and @code{tree}.
-
-@itemize @bullet
-@item
-@file{config.h}, for use in programs that run on the host machine.
-@item
-@file{bconfig.h}, for use in programs that run on the build machine.
-@item
-@file{tconfig.h}, for use in programs and libraries for the target
-machine.
-@item
-@file{tm_p.h}, which includes the header @file{@var{machine}-protos.h}
-that contains prototypes for functions in the target
-@file{@var{machine}.c} file.  The header @file{@var{machine}-protos.h}
-can include prototypes of functions that use rtl and tree data
-structures inside appropriate @code{#ifdef RTX_CODE} and @code{#ifdef
-TREE_CODE} conditional code segements.  The
-@file{@var{machine}-protos.h} is included after the @file{rtl.h}
-and/or @file{tree.h} would have been included.  The @file{tm_p.h} also
-includes the header @file{tm-preds.h} which is generated by
-@file{genpreds} program during the build to define the declarations
-and inline functions for the predicate functions.
-@end itemize
diff --git a/contrib/gcc-5.0/gcc/doc/configterms.texi b/contrib/gcc-5.0/gcc/doc/configterms.texi
deleted file mode 100644 (file)
index 6eb0c95..0000000
+++ /dev/null
@@ -1,61 +0,0 @@
-@c Copyright (C) 2001-2015 Free Software Foundation, Inc.
-@c This is part of the GCC manual.
-@c For copying conditions, see the file gcc.texi.
-
-@node Configure Terms
-@section Configure Terms and History
-@cindex configure terms
-@cindex canadian
-
-The configure and build process has a long and colorful history, and can
-be confusing to anyone who doesn't know why things are the way they are.
-While there are other documents which describe the configuration process
-in detail, here are a few things that everyone working on GCC should
-know.
-
-There are three system names that the build knows about: the machine you
-are building on (@dfn{build}), the machine that you are building for
-(@dfn{host}), and the machine that GCC will produce code for
-(@dfn{target}).  When you configure GCC, you specify these with
-@option{--build=}, @option{--host=}, and @option{--target=}.
-
-Specifying the host without specifying the build should be avoided, as
-@command{configure} may (and once did) assume that the host you specify
-is also the build, which may not be true.
-
-If build, host, and target are all the same, this is called a
-@dfn{native}.  If build and host are the same but target is different,
-this is called a @dfn{cross}.  If build, host, and target are all
-different this is called a @dfn{canadian} (for obscure reasons dealing
-with Canada's political party and the background of the person working
-on the build at that time).  If host and target are the same, but build
-is different, you are using a cross-compiler to build a native for a
-different system.  Some people call this a @dfn{host-x-host},
-@dfn{crossed native}, or @dfn{cross-built native}.  If build and target
-are the same, but host is different, you are using a cross compiler to
-build a cross compiler that produces code for the machine you're
-building on.  This is rare, so there is no common way of describing it.
-There is a proposal to call this a @dfn{crossback}.
-
-If build and host are the same, the GCC you are building will also be
-used to build the target libraries (like @code{libstdc++}).  If build and host
-are different, you must have already built and installed a cross
-compiler that will be used to build the target libraries (if you
-configured with @option{--target=foo-bar}, this compiler will be called
-@command{foo-bar-gcc}).
-
-In the case of target libraries, the machine you're building for is the
-machine you specified with @option{--target}.  So, build is the machine
-you're building on (no change there), host is the machine you're
-building for (the target libraries are built for the target, so host is
-the target you specified), and target doesn't apply (because you're not
-building a compiler, you're building libraries).  The configure/make
-process will adjust these variables as needed.  It also sets
-@code{$with_cross_host} to the original @option{--host} value in case you
-need it.
-
-The @code{libiberty} support library is built up to three times: once
-for the host, once for the target (even if they are the same), and once
-for the build if build and host are different.  This allows it to be
-used by all programs which are generated in the course of the build
-process.
diff --git a/contrib/gcc-5.0/gcc/doc/contrib.texi b/contrib/gcc-5.0/gcc/doc/contrib.texi
deleted file mode 100644 (file)
index 9935ac7..0000000
+++ /dev/null
@@ -1,1676 +0,0 @@
-@c Copyright (C) 1988-2015 Free Software Foundation, Inc.
-@c This is part of the GCC manual.
-@c For copying conditions, see the file gcc.texi.
-
-@node Contributors
-@unnumbered Contributors to GCC
-@cindex contributors
-
-The GCC project would like to thank its many contributors.  Without them the
-project would not have been nearly as successful as it has been.  Any omissions
-in this list are accidental.  Feel free to contact
-@email{law@@redhat.com} or @email{gerald@@pfeifer.com} if you have been left
-out or some of your contributions are not listed.  Please keep this list in
-alphabetical order.
-
-@itemize @bullet
-
-@item
-Analog Devices helped implement the support for complex data types
-and iterators.
-
-@item
-John David Anglin for threading-related fixes and improvements to
-libstdc++-v3, and the HP-UX port.
-
-@item
-James van Artsdalen wrote the code that makes efficient use of
-the Intel 80387 register stack.
-
-@item
-Abramo and Roberto Bagnara for the SysV68 Motorola 3300 Delta Series
-port.
-
-@item
-Alasdair Baird for various bug fixes.
-
-@item
-Giovanni Bajo for analyzing lots of complicated C++ problem reports.
-
-@item
-Peter Barada for his work to improve code generation for new
-ColdFire cores.
-
-@item
-Gerald Baumgartner added the signature extension to the C++ front end.
-
-@item
-Godmar Back for his Java improvements and encouragement.
-
-@item
-Scott Bambrough for help porting the Java compiler.
-
-@item
-Wolfgang Bangerth for processing tons of bug reports.
-
-@item
-Jon Beniston for his Microsoft Windows port of Java and port to Lattice Mico32.
-
-@item
-Daniel Berlin for better DWARF2 support, faster/better optimizations,
-improved alias analysis, plus migrating GCC to Bugzilla.
-
-@item
-Geoff Berry for his Java object serialization work and various patches.
-
-@item
-David Binderman tests weekly snapshots of GCC trunk against Fedora Rawhide
-for several architectures.
-
-@item
-Uros Bizjak for the implementation of x87 math built-in functions and
-for various middle end and i386 back end improvements and bug fixes.
-
-@item
-Eric Blake for helping to make GCJ and libgcj conform to the
-specifications.
-
-@item
-Janne Blomqvist for contributions to GNU Fortran.
-
-@item
-Segher Boessenkool for various fixes.
-
-@item
-Hans-J. Boehm for his @uref{http://www.hpl.hp.com/@/personal/@/Hans_Boehm/@/gc/,,
-garbage collector}, IA-64 libffi port, and other Java work.
-
-@item
-Neil Booth for work on cpplib, lang hooks, debug hooks and other
-miscellaneous clean-ups.
-
-@item
-Steven Bosscher for integrating the GNU Fortran front end into GCC and for
-contributing to the tree-ssa branch.
-
-@item
-Eric Botcazou for fixing middle- and backend bugs left and right.
-
-@item
-Per Bothner for his direction via the steering committee and various
-improvements to the infrastructure for supporting new languages.  Chill
-front end implementation.  Initial implementations of
-cpplib, fix-header, config.guess, libio, and past C++ library (libg++)
-maintainer.  Dreaming up, designing and implementing much of GCJ@.
-
-@item
-Devon Bowen helped port GCC to the Tahoe.
-
-@item
-Don Bowman for mips-vxworks contributions.
-
-@item
-Dave Brolley for work on cpplib and Chill.
-
-@item
-Paul Brook for work on the ARM architecture and maintaining GNU Fortran.
-
-@item
-Robert Brown implemented the support for Encore 32000 systems.
-
-@item
-Christian Bruel for improvements to local store elimination.
-
-@item
-Herman A.J. ten Brugge for various fixes.
-
-@item
-Joerg Brunsmann for Java compiler hacking and help with the GCJ FAQ@.
-
-@item
-Joe Buck for his direction via the steering committee.
-
-@item
-Craig Burley for leadership of the G77 Fortran effort.
-
-@item
-Stephan Buys for contributing Doxygen notes for libstdc++.
-
-@item
-Paolo Carlini for libstdc++ work: lots of efficiency improvements to
-the C++ strings, streambufs and formatted I/O, hard detective work on
-the frustrating localization issues, and keeping up with the problem reports.
-
-@item
-John Carr for his alias work, SPARC hacking, infrastructure improvements,
-previous contributions to the steering committee, loop optimizations, etc.
-
-@item
-Stephane Carrez for 68HC11 and 68HC12 ports.
-
-@item
-Steve Chamberlain for support for the Renesas SH and H8 processors
-and the PicoJava processor, and for GCJ config fixes.
-
-@item
-Glenn Chambers for help with the GCJ FAQ@.
-
-@item
-John-Marc Chandonia for various libgcj patches.
-
-@item
-Denis Chertykov for contributing and maintaining the AVR port, the first GCC port
-for an 8-bit architecture.
-
-@item
-Scott Christley for his Objective-C contributions.
-
-@item
-Eric Christopher for his Java porting help and clean-ups.
-
-@item
-Branko Cibej for more warning contributions.
-
-@item
-The @uref{http://www.gnu.org/software/classpath/,,GNU Classpath project}
-for all of their merged runtime code.
-
-@item
-Nick Clifton for arm, mcore, fr30, v850, m32r, msp430 rx work,
-@option{--help}, and other random hacking.
-
-@item
-Michael Cook for libstdc++ cleanup patches to reduce warnings.
-
-@item
-R. Kelley Cook for making GCC buildable from a read-only directory as
-well as other miscellaneous build process and documentation clean-ups.
-
-@item
-Ralf Corsepius for SH testing and minor bug fixing.
-
-@item
-Stan Cox for care and feeding of the x86 port and lots of behind
-the scenes hacking.
-
-@item
-Alex Crain provided changes for the 3b1.
-
-@item
-Ian Dall for major improvements to the NS32k port.
-
-@item
-Paul Dale for his work to add uClinux platform support to the
-m68k backend.
-
-@item
-Dario Dariol contributed the four varieties of sample programs
-that print a copy of their source.
-
-@item
-Russell Davidson for fstream and stringstream fixes in libstdc++.
-
-@item
-Bud Davis for work on the G77 and GNU Fortran compilers.
-
-@item
-Mo DeJong for GCJ and libgcj bug fixes.
-
-@item
-DJ Delorie for the DJGPP port, build and libiberty maintenance,
-various bug fixes, and the M32C, MeP, MSP430, and RL78 ports.
-
-@item
-Arnaud Desitter for helping to debug GNU Fortran.
-
-@item
-Gabriel Dos Reis for contributions to G++, contributions and
-maintenance of GCC diagnostics infrastructure, libstdc++-v3,
-including @code{valarray<>}, @code{complex<>}, maintaining the numerics library
-(including that pesky @code{<limits>} :-) and keeping up-to-date anything
-to do with numbers.
-
-@item
-Ulrich Drepper for his work on glibc, testing of GCC using glibc, ISO C99
-support, CFG dumping support, etc., plus support of the C++ runtime
-libraries including for all kinds of C interface issues, contributing and
-maintaining @code{complex<>}, sanity checking and disbursement, configuration
-architecture, libio maintenance, and early math work.
-
-@item
-Fran@,{c}ois Dumont for his work on libstdc++-v3, especially maintaining and
-improving @code{debug-mode} and associative and unordered containers.
-
-@item
-Zdenek Dvorak for a new loop unroller and various fixes.
-
-@item
-Michael Eager for his work on the Xilinx MicroBlaze port.
-
-@item
-Richard Earnshaw for his ongoing work with the ARM@.
-
-@item
-David Edelsohn for his direction via the steering committee, ongoing work
-with the RS6000/PowerPC port, help cleaning up Haifa loop changes,
-doing the entire AIX port of libstdc++ with his bare hands, and for
-ensuring GCC properly keeps working on AIX@.
-
-@item
-Kevin Ediger for the floating point formatting of num_put::do_put in
-libstdc++.
-
-@item
-Phil Edwards for libstdc++ work including configuration hackery,
-documentation maintainer, chief breaker of the web pages, the occasional
-iostream bug fix, and work on shared library symbol versioning.
-
-@item
-Paul Eggert for random hacking all over GCC@.
-
-@item
-Mark Elbrecht for various DJGPP improvements, and for libstdc++
-configuration support for locales and fstream-related fixes.
-
-@item
-Vadim Egorov for libstdc++ fixes in strings, streambufs, and iostreams.
-
-@item
-Christian Ehrhardt for dealing with bug reports.
-
-@item
-Ben Elliston for his work to move the Objective-C runtime into its
-own subdirectory and for his work on autoconf.
-
-@item
-Revital Eres for work on the PowerPC 750CL port.
-
-@item
-Marc Espie for OpenBSD support.
-
-@item
-Doug Evans for much of the global optimization framework, arc, m32r,
-and SPARC work.
-
-@item
-Christopher Faylor for his work on the Cygwin port and for caring and
-feeding the gcc.gnu.org box and saving its users tons of spam.
-
-@item
-Fred Fish for BeOS support and Ada fixes.
-
-@item
-Ivan Fontes Garcia for the Portuguese translation of the GCJ FAQ@.
-
-@item
-Peter Gerwinski for various bug fixes and the Pascal front end.
-
-@item
-Kaveh R.@: Ghazi for his direction via the steering committee, amazing
-work to make @samp{-W -Wall -W* -Werror} useful, and 
-testing GCC on a plethora of platforms.  Kaveh extends his gratitude to
-the CAIP Center at Rutgers University for providing him with computing
-resources to work on Free Software from the late 1980s to 2010.
-
-@item
-John Gilmore for a donation to the FSF earmarked improving GNU Java.
-
-@item
-Judy Goldberg for c++ contributions.
-
-@item
-Torbjorn Granlund for various fixes and the c-torture testsuite,
-multiply- and divide-by-constant optimization, improved long long
-support, improved leaf function register allocation, and his direction
-via the steering committee.
-
-@item
-Jonny Grant for improvements to @code{collect2's} @option{--help} documentation.
-
-@item
-Anthony Green for his @option{-Os} contributions, the moxie port, and
-Java front end work.
-
-@item
-Stu Grossman for gdb hacking, allowing GCJ developers to debug Java code.
-
-@item
-Michael K. Gschwind contributed the port to the PDP-11.
-
-@item
-Richard Biener for his ongoing middle-end contributions and bug fixes
-and for release management.
-
-@item
-Ron Guilmette implemented the @command{protoize} and @command{unprotoize}
-tools, the support for Dwarf symbolic debugging information, and much of
-the support for System V Release 4.  He has also worked heavily on the
-Intel 386 and 860 support.
-
-@item
-Sumanth Gundapaneni for contributing the CR16 port.
-
-@item
-Mostafa Hagog for Swing Modulo Scheduling (SMS) and post reload GCSE@.
-
-@item
-Bruno Haible for improvements in the runtime overhead for EH, new
-warnings and assorted bug fixes.
-
-@item
-Andrew Haley for his amazing Java compiler and library efforts.
-
-@item
-Chris Hanson assisted in making GCC work on HP-UX for the 9000 series 300.
-
-@item
-Michael Hayes for various thankless work he's done trying to get
-the c30/c40 ports functional.  Lots of loop and unroll improvements and
-fixes.
-
-@item
-Dara Hazeghi for wading through myriads of target-specific bug reports.
-
-@item
-Kate Hedstrom for staking the G77 folks with an initial testsuite.
-
-@item
-Richard Henderson for his ongoing SPARC, alpha, ia32, and ia64 work, loop
-opts, and generally fixing lots of old problems we've ignored for
-years, flow rewrite and lots of further stuff, including reviewing
-tons of patches.
-
-@item
-Aldy Hernandez for working on the PowerPC port, SIMD support, and
-various fixes.
-
-@item
-Nobuyuki Hikichi of Software Research Associates, Tokyo, contributed
-the support for the Sony NEWS machine.
-
-@item
-Kazu Hirata for caring and feeding the Renesas H8/300 port and various fixes.
-
-@item
-Katherine Holcomb for work on GNU Fortran.
-
-@item
-Manfred Hollstein for his ongoing work to keep the m88k alive, lots
-of testing and bug fixing, particularly of GCC configury code.
-
-@item
-Steve Holmgren for MachTen patches.
-
-@item
-Mat Hostetter for work on the TILE-Gx and TILEPro ports.
-
-@item
-Jan Hubicka for his x86 port improvements.
-
-@item
-Falk Hueffner for working on C and optimization bug reports.
-
-@item
-Bernardo Innocenti for his m68k work, including merging of
-ColdFire improvements and uClinux support.
-
-@item
-Christian Iseli for various bug fixes.
-
-@item
-Kamil Iskra for general m68k hacking.
-
-@item
-Lee Iverson for random fixes and MIPS testing.
-
-@item
-Balaji V. Iyer for Cilk+ development and merging.
-
-@item
-Andreas Jaeger for testing and benchmarking of GCC and various bug fixes.
-
-@item
-Jakub Jelinek for his SPARC work and sibling call optimizations as well
-as lots of bug fixes and test cases, and for improving the Java build
-system.
-
-@item
-Janis Johnson for ia64 testing and fixes, her quality improvement
-sidetracks, and web page maintenance.
-
-@item
-Kean Johnston for SCO OpenServer support and various fixes.
-
-@item
-Tim Josling for the sample language treelang based originally on Richard
-Kenner's ``toy'' language.
-
-@item
-Nicolai Josuttis for additional libstdc++ documentation.
-
-@item
-Klaus Kaempf for his ongoing work to make alpha-vms a viable target.
-
-@item
-Steven G. Kargl for work on GNU Fortran.
-
-@item
-David Kashtan of SRI adapted GCC to VMS@.
-
-@item
-Ryszard Kabatek for many, many libstdc++ bug fixes and optimizations of
-strings, especially member functions, and for auto_ptr fixes.
-
-@item
-Geoffrey Keating for his ongoing work to make the PPC work for GNU/Linux
-and his automatic regression tester.
-
-@item
-Brendan Kehoe for his ongoing work with G++ and for a lot of early work
-in just about every part of libstdc++.
-
-@item
-Oliver M. Kellogg of Deutsche Aerospace contributed the port to the
-MIL-STD-1750A@.
-
-@item
-Richard Kenner of the New York University Ultracomputer Research
-Laboratory wrote the machine descriptions for the AMD 29000, the DEC
-Alpha, the IBM RT PC, and the IBM RS/6000 as well as the support for
-instruction attributes.  He also made changes to better support RISC
-processors including changes to common subexpression elimination,
-strength reduction, function calling sequence handling, and condition
-code support, in addition to generalizing the code for frame pointer
-elimination and delay slot scheduling.  Richard Kenner was also the
-head maintainer of GCC for several years.
-
-@item
-Mumit Khan for various contributions to the Cygwin and Mingw32 ports and
-maintaining binary releases for Microsoft Windows hosts, and for massive libstdc++
-porting work to Cygwin/Mingw32.
-
-@item
-Robin Kirkham for cpu32 support.
-
-@item
-Mark Klein for PA improvements.
-
-@item
-Thomas Koenig for various bug fixes.
-
-@item
-Bruce Korb for the new and improved fixincludes code.
-
-@item
-Benjamin Kosnik for his G++ work and for leading the libstdc++-v3 effort.
-
-@item
-Charles LaBrec contributed the support for the Integrated Solutions
-68020 system.
-
-@item
-Asher Langton and Mike Kumbera for contributing Cray pointer support
-to GNU Fortran, and for other GNU Fortran improvements.
-
-@item
-Jeff Law for his direction via the steering committee, coordinating the
-entire egcs project and GCC 2.95, rolling out snapshots and releases,
-handling merges from GCC2, reviewing tons of patches that might have
-fallen through the cracks else, and random but extensive hacking.
-
-@item
-Walter Lee for work on the TILE-Gx and TILEPro ports.
-
-@item
-Marc Lehmann for his direction via the steering committee and helping
-with analysis and improvements of x86 performance.
-
-@item
-Victor Leikehman for work on GNU Fortran.
-
-@item
-Ted Lemon wrote parts of the RTL reader and printer.
-
-@item
-Kriang Lerdsuwanakij for C++ improvements including template as template
-parameter support, and many C++ fixes.
-
-@item
-Warren Levy for tremendous work on libgcj (Java Runtime Library) and
-random work on the Java front end.
-
-@item
-Alain Lichnewsky ported GCC to the MIPS CPU@.
-
-@item
-Oskar Liljeblad for hacking on AWT and his many Java bug reports and
-patches.
-
-@item
-Robert Lipe for OpenServer support, new testsuites, testing, etc.
-
-@item
-Chen Liqin for various S+core related fixes/improvement, and for
-maintaining the S+core port.
-
-@item
-Weiwen Liu for testing and various bug fixes.
-
-@item
-Manuel L@'opez-Ib@'a@~nez for improving @option{-Wconversion} and
-many other diagnostics fixes and improvements.
-
-@item
-Dave Love for his ongoing work with the Fortran front end and
-runtime libraries.
-
-@item
-Martin von L@"owis for internal consistency checking infrastructure,
-various C++ improvements including namespace support, and tons of
-assistance with libstdc++/compiler merges.
-
-@item
-H.J. Lu for his previous contributions to the steering committee, many x86
-bug reports, prototype patches, and keeping the GNU/Linux ports working.
-
-@item
-Greg McGary for random fixes and (someday) bounded pointers.
-
-@item
-Andrew MacLeod for his ongoing work in building a real EH system,
-various code generation improvements, work on the global optimizer, etc.
-
-@item
-Vladimir Makarov for hacking some ugly i960 problems, PowerPC hacking
-improvements to compile-time performance, overall knowledge and
-direction in the area of instruction scheduling, and design and
-implementation of the automaton based instruction scheduler.
-
-@item
-Bob Manson for his behind the scenes work on dejagnu.
-
-@item
-Philip Martin for lots of libstdc++ string and vector iterator fixes and
-improvements, and string clean up and testsuites.
-
-@item
-All of the Mauve project
-@uref{http://sourceware.org/cgi-bin/cvsweb.cgi/~checkout~/mauve/THANKS?rev=1.2&cvsroot=mauve&only_with_tag=HEAD,,contributors},
-for Java test code.
-
-@item
-Bryce McKinlay for numerous GCJ and libgcj fixes and improvements.
-
-@item
-Adam Megacz for his work on the Microsoft Windows port of GCJ@.
-
-@item
-Michael Meissner for LRS framework, ia32, m32r, v850, m88k, MIPS,
-powerpc, haifa, ECOFF debug support, and other assorted hacking.
-
-@item
-Jason Merrill for his direction via the steering committee and leading
-the G++ effort.
-
-@item
-Martin Michlmayr for testing GCC on several architectures using the
-entire Debian archive.
-
-@item
-David Miller for his direction via the steering committee, lots of
-SPARC work, improvements in jump.c and interfacing with the Linux kernel
-developers.
-
-@item
-Gary Miller ported GCC to Charles River Data Systems machines.
-
-@item
-Alfred Minarik for libstdc++ string and ios bug fixes, and turning the
-entire libstdc++ testsuite namespace-compatible.
-
-@item
-Mark Mitchell for his direction via the steering committee, mountains of
-C++ work, load/store hoisting out of loops, alias analysis improvements,
-ISO C @code{restrict} support, and serving as release manager from 2000
-to 2011.
-
-@item
-Alan Modra for various GNU/Linux bits and testing.
-
-@item
-Toon Moene for his direction via the steering committee, Fortran
-maintenance, and his ongoing work to make us make Fortran run fast.
-
-@item
-Jason Molenda for major help in the care and feeding of all the services
-on the gcc.gnu.org (formerly egcs.cygnus.com) machine---mail, web
-services, ftp services, etc etc.  Doing all this work on scrap paper and
-the backs of envelopes would have been@dots{} difficult.
-
-@item
-Catherine Moore for fixing various ugly problems we have sent her
-way, including the haifa bug which was killing the Alpha & PowerPC
-Linux kernels.
-
-@item
-Mike Moreton for his various Java patches.
-
-@item
-David Mosberger-Tang for various Alpha improvements, and for the initial
-IA-64 port.
-
-@item
-Stephen Moshier contributed the floating point emulator that assists in
-cross-compilation and permits support for floating point numbers wider
-than 64 bits and for ISO C99 support.
-
-@item
-Bill Moyer for his behind the scenes work on various issues.
-
-@item
-Philippe De Muyter for his work on the m68k port.
-
-@item
-Joseph S. Myers for his work on the PDP-11 port, format checking and ISO
-C99 support, and continuous emphasis on (and contributions to) documentation.
-
-@item
-Nathan Myers for his work on libstdc++-v3: architecture and authorship
-through the first three snapshots, including implementation of locale
-infrastructure, string, shadow C headers, and the initial project
-documentation (DESIGN, CHECKLIST, and so forth).  Later, more work on
-MT-safe string and shadow headers.
-
-@item
-Felix Natter for documentation on porting libstdc++.
-
-@item
-Nathanael Nerode for cleaning up the configuration/build process.
-
-@item
-NeXT, Inc.@: donated the front end that supports the Objective-C
-language.
-
-@item
-Hans-Peter Nilsson for the CRIS and MMIX ports, improvements to the search
-engine setup, various documentation fixes and other small fixes.
-
-@item
-Geoff Noer for his work on getting cygwin native builds working.
-
-@item
-Diego Novillo for his work on Tree SSA, OpenMP, SPEC performance
-tracking web pages, GIMPLE tuples, and assorted fixes.
-
-@item
-David O'Brien for the FreeBSD/alpha, FreeBSD/AMD x86-64, FreeBSD/ARM,
-FreeBSD/PowerPC, and FreeBSD/SPARC64 ports and related infrastructure
-improvements.
-
-@item
-Alexandre Oliva for various build infrastructure improvements, scripts and
-amazing testing work, including keeping libtool issues sane and happy.
-
-@item
-Stefan Olsson for work on mt_alloc.
-
-@item
-Melissa O'Neill for various NeXT fixes.
-
-@item
-Rainer Orth for random MIPS work, including improvements to GCC's o32
-ABI support, improvements to dejagnu's MIPS support, Java configuration
-clean-ups and porting work, and maintaining the IRIX, Solaris 2, and
-Tru64 UNIX ports.
-
-@item
-Hartmut Penner for work on the s390 port.
-
-@item
-Paul Petersen wrote the machine description for the Alliant FX/8.
-
-@item
-Alexandre Petit-Bianco for implementing much of the Java compiler and
-continued Java maintainership.
-
-@item
-Matthias Pfaller for major improvements to the NS32k port.
-
-@item
-Gerald Pfeifer for his direction via the steering committee, pointing
-out lots of problems we need to solve, maintenance of the web pages, and
-taking care of documentation maintenance in general.
-
-@item
-Andrew Pinski for processing bug reports by the dozen.
-
-@item
-Ovidiu Predescu for his work on the Objective-C front end and runtime
-libraries.
-
-@item
-Jerry Quinn for major performance improvements in C++ formatted I/O@.
-
-@item
-Ken Raeburn for various improvements to checker, MIPS ports and various
-cleanups in the compiler.
-
-@item
-Rolf W. Rasmussen for hacking on AWT@.
-
-@item
-David Reese of Sun Microsystems contributed to the Solaris on PowerPC
-port.
-
-@item
-Volker Reichelt for keeping up with the problem reports.
-
-@item
-Joern Rennecke for maintaining the sh port, loop, regmove & reload
-hacking and developing and maintaining the Epiphany port.
-
-@item
-Loren J. Rittle for improvements to libstdc++-v3 including the FreeBSD
-port, threading fixes, thread-related configury changes, critical
-threading documentation, and solutions to really tricky I/O problems,
-as well as keeping GCC properly working on FreeBSD and continuous testing.
-
-@item
-Craig Rodrigues for processing tons of bug reports.
-
-@item
-Ola R@"onnerup for work on mt_alloc.
-
-@item
-Gavin Romig-Koch for lots of behind the scenes MIPS work.
-
-@item
-David Ronis inspired and encouraged Craig to rewrite the G77
-documentation in texinfo format by contributing a first pass at a
-translation of the old @file{g77-0.5.16/f/DOC} file.
-
-@item
-Ken Rose for fixes to GCC's delay slot filling code.
-
-@item
-Paul Rubin wrote most of the preprocessor.
-
-@item
-P@'etur Run@'olfsson for major performance improvements in C++ formatted I/O and
-large file support in C++ filebuf.
-
-@item
-Chip Salzenberg for libstdc++ patches and improvements to locales, traits,
-Makefiles, libio, libtool hackery, and ``long long'' support.
-
-@item
-Juha Sarlin for improvements to the H8 code generator.
-
-@item
-Greg Satz assisted in making GCC work on HP-UX for the 9000 series 300.
-
-@item
-Roger Sayle for improvements to constant folding and GCC's RTL optimizers
-as well as for fixing numerous bugs.
-
-@item
-Bradley Schatz for his work on the GCJ FAQ@.
-
-@item
-Peter Schauer wrote the code to allow debugging to work on the Alpha.
-
-@item
-William Schelter did most of the work on the Intel 80386 support.
-
-@item
-Tobias Schl@"uter for work on GNU Fortran.
-
-@item
-Bernd Schmidt for various code generation improvements and major
-work in the reload pass, serving as release manager for
-GCC 2.95.3, and work on the Blackfin and C6X ports.
-
-@item
-Peter Schmid for constant testing of libstdc++---especially application
-testing, going above and beyond what was requested for the release
-criteria---and libstdc++ header file tweaks.
-
-@item
-Jason Schroeder for jcf-dump patches.
-
-@item
-Andreas Schwab for his work on the m68k port.
-
-@item
-Lars Segerlund for work on GNU Fortran.
-
-@item
-Dodji Seketeli for numerous C++ bug fixes and debug info improvements.
-
-@item
-Tim Shen for major work on @code{<regex>}.
-
-@item
-Joel Sherrill for his direction via the steering committee, RTEMS
-contributions and RTEMS testing.
-
-@item
-Nathan Sidwell for many C++ fixes/improvements.
-
-@item
-Jeffrey Siegal for helping RMS with the original design of GCC, some
-code which handles the parse tree and RTL data structures, constant
-folding and help with the original VAX & m68k ports.
-
-@item
-Kenny Simpson for prompting libstdc++ fixes due to defect reports from
-the LWG (thereby keeping GCC in line with updates from the ISO)@.
-
-@item
-Franz Sirl for his ongoing work with making the PPC port stable
-for GNU/Linux.
-
-@item
-Andrey Slepuhin for assorted AIX hacking.
-
-@item
-Trevor Smigiel for contributing the SPU port.
-
-@item
-Christopher Smith did the port for Convex machines.
-
-@item
-Danny Smith for his major efforts on the Mingw (and Cygwin) ports.
-Retired from GCC maintainership August 2010, having mentored two 
-new maintainers into the role.
-
-@item
-Randy Smith finished the Sun FPA support.
-
-@item
-Ed Smith-Rowland for his continuous work on libstdc++-v3, special functions,
-@code{<random>}, and various improvements to C++11 features.
-
-@item
-Scott Snyder for queue, iterator, istream, and string fixes and libstdc++
-testsuite entries.  Also for providing the patch to G77 to add
-rudimentary support for @code{INTEGER*1}, @code{INTEGER*2}, and
-@code{LOGICAL*1}.
-
-@item
-Zdenek Sojka for running automated regression testing of GCC and reporting
-numerous bugs.
-
-@item
-Jayant Sonar for contributing the CR16 port.
-
-@item
-Brad Spencer for contributions to the GLIBCPP_FORCE_NEW technique.
-
-@item
-Richard Stallman, for writing the original GCC and launching the GNU project.
-
-@item
-Jan Stein of the Chalmers Computer Society provided support for
-Genix, as well as part of the 32000 machine description.
-
-@item
-Nigel Stephens for various mips16 related fixes/improvements.
-
-@item
-Jonathan Stone wrote the machine description for the Pyramid computer.
-
-@item
-Graham Stott for various infrastructure improvements.
-
-@item
-John Stracke for his Java HTTP protocol fixes.
-
-@item
-Mike Stump for his Elxsi port, G++ contributions over the years and more
-recently his vxworks contributions
-
-@item
-Jeff Sturm for Java porting help, bug fixes, and encouragement.
-
-@item
-Shigeya Suzuki for this fixes for the bsdi platforms.
-
-@item
-Ian Lance Taylor for the Go frontend, the initial mips16 and mips64
-support, general configury hacking, fixincludes, etc.
-
-@item
-Holger Teutsch provided the support for the Clipper CPU@.
-
-@item
-Gary Thomas for his ongoing work to make the PPC work for GNU/Linux.
-
-@item
-Philipp Thomas for random bug fixes throughout the compiler
-
-@item
-Jason Thorpe for thread support in libstdc++ on NetBSD@.
-
-@item
-Kresten Krab Thorup wrote the run time support for the Objective-C
-language and the fantastic Java bytecode interpreter.
-
-@item
-Michael Tiemann for random bug fixes, the first instruction scheduler,
-initial C++ support, function integration, NS32k, SPARC and M88k
-machine description work, delay slot scheduling.
-
-@item
-Andreas Tobler for his work porting libgcj to Darwin.
-
-@item
-Teemu Torma for thread safe exception handling support.
-
-@item
-Leonard Tower wrote parts of the parser, RTL generator, and RTL
-definitions, and of the VAX machine description.
-
-@item
-Daniel Towner and Hariharan Sandanagobalane contributed and
-maintain the picoChip port.
-
-@item
-Tom Tromey for internationalization support and for his many Java
-contributions and libgcj maintainership.
-
-@item
-Lassi Tuura for improvements to config.guess to determine HP processor
-types.
-
-@item
-Petter Urkedal for libstdc++ CXXFLAGS, math, and algorithms fixes.
-
-@item
-Andy Vaught for the design and initial implementation of the GNU Fortran
-front end.
-
-@item
-Brent Verner for work with the libstdc++ cshadow files and their
-associated configure steps.
-
-@item
-Todd Vierling for contributions for NetBSD ports.
-
-@item
-Jonathan Wakely for contributing libstdc++ Doxygen notes and XHTML
-guidance.
-
-@item
-Dean Wakerley for converting the install documentation from HTML to texinfo
-in time for GCC 3.0.
-
-@item
-Krister Walfridsson for random bug fixes.
-
-@item
-Feng Wang for contributions to GNU Fortran.
-
-@item
-Stephen M. Webb for time and effort on making libstdc++ shadow files
-work with the tricky Solaris 8+ headers, and for pushing the build-time
-header tree. Also, for starting and driving the @code{<regex>} effort.
-
-@item
-John Wehle for various improvements for the x86 code generator,
-related infrastructure improvements to help x86 code generation,
-value range propagation and other work, WE32k port.
-
-@item
-Ulrich Weigand for work on the s390 port.
-
-@item
-Zack Weinberg for major work on cpplib and various other bug fixes.
-
-@item
-Matt Welsh for help with Linux Threads support in GCJ@.
-
-@item
-Urban Widmark for help fixing java.io.
-
-@item
-Mark Wielaard for new Java library code and his work integrating with
-Classpath.
-
-@item
-Dale Wiles helped port GCC to the Tahoe.
-
-@item
-Bob Wilson from Tensilica, Inc.@: for the Xtensa port.
-
-@item
-Jim Wilson for his direction via the steering committee, tackling hard
-problems in various places that nobody else wanted to work on, strength
-reduction and other loop optimizations.
-
-@item
-Paul Woegerer and Tal Agmon for the CRX port.
-
-@item
-Carlo Wood for various fixes.
-
-@item
-Tom Wood for work on the m88k port.
-
-@item
-Chung-Ju Wu for his work on the Andes NDS32 port.
-
-@item
-Canqun Yang for work on GNU Fortran.
-
-@item
-Masanobu Yuhara of Fujitsu Laboratories implemented the machine
-description for the Tron architecture (specifically, the Gmicro).
-
-@item
-Kevin Zachmann helped port GCC to the Tahoe.
-
-@item
-Ayal Zaks for Swing Modulo Scheduling (SMS).
-
-@item
-Xiaoqiang Zhang for work on GNU Fortran.
-
-@item
-Gilles Zunino for help porting Java to Irix.
-
-@end itemize
-
-The following people are recognized for their contributions to GNAT,
-the Ada front end of GCC:
-@itemize @bullet
-@item
-Bernard Banner
-
-@item
-Romain Berrendonner
-
-@item
-Geert Bosch
-
-@item
-Emmanuel Briot
-
-@item
-Joel Brobecker
-
-@item
-Ben Brosgol
-
-@item
-Vincent Celier
-
-@item
-Arnaud Charlet
-
-@item
-Chien Chieng
-
-@item
-Cyrille Comar
-
-@item
-Cyrille Crozes
-
-@item
-Robert Dewar
-
-@item
-Gary Dismukes
-
-@item
-Robert Duff
-
-@item
-Ed Falis
-
-@item
-Ramon Fernandez
-
-@item
-Sam Figueroa
-
-@item
-Vasiliy Fofanov
-
-@item
-Michael Friess
-
-@item
-Franco Gasperoni
-
-@item
-Ted Giering
-
-@item
-Matthew Gingell
-
-@item
-Laurent Guerby
-
-@item
-Jerome Guitton
-
-@item
-Olivier Hainque
-
-@item
-Jerome Hugues
-
-@item
-Hristian Kirtchev
-
-@item
-Jerome Lambourg
-
-@item
-Bruno Leclerc
-
-@item
-Albert Lee
-
-@item
-Sean McNeil
-
-@item
-Javier Miranda
-
-@item
-Laurent Nana
-
-@item
-Pascal Obry
-
-@item
-Dong-Ik Oh
-
-@item
-Laurent Pautet
-
-@item
-Brett Porter
-
-@item
-Thomas Quinot
-
-@item
-Nicolas Roche
-
-@item
-Pat Rogers
-
-@item
-Jose Ruiz
-
-@item
-Douglas Rupp
-
-@item
-Sergey Rybin
-
-@item
-Gail Schenker
-
-@item
-Ed Schonberg
-
-@item
-Nicolas Setton
-
-@item
-Samuel Tardieu
-
-@end itemize
-
-
-The following people are recognized for their contributions of new
-features, bug reports, testing and integration of classpath/libgcj for
-GCC version 4.1:
-@itemize @bullet
-@item
-Lillian Angel for @code{JTree} implementation and lots Free Swing
-additions and bug fixes.
-
-@item
-Wolfgang Baer for @code{GapContent} bug fixes.
-
-@item
-Anthony Balkissoon for @code{JList}, Free Swing 1.5 updates and mouse event
-fixes, lots of Free Swing work including @code{JTable} editing.
-
-@item
-Stuart Ballard for RMI constant fixes.
-
-@item
-Goffredo Baroncelli for @code{HTTPURLConnection} fixes.
-
-@item
-Gary Benson for @code{MessageFormat} fixes.
-
-@item
-Daniel Bonniot for @code{Serialization} fixes.
-
-@item
-Chris Burdess for lots of gnu.xml and http protocol fixes, @code{StAX}
-and @code{DOM xml:id} support.
-
-@item
-Ka-Hing Cheung for @code{TreePath} and @code{TreeSelection} fixes.
-
-@item
-Archie Cobbs for build fixes, VM interface updates,
-@code{URLClassLoader} updates.
-
-@item
-Kelley Cook for build fixes.
-
-@item
-Martin Cordova for Suggestions for better @code{SocketTimeoutException}.
-
-@item
-David Daney for @code{BitSet} bug fixes, @code{HttpURLConnection}
-rewrite and improvements.
-
-@item
-Thomas Fitzsimmons for lots of upgrades to the gtk+ AWT and Cairo 2D
-support. Lots of imageio framework additions, lots of AWT and Free
-Swing bug fixes.
-
-@item
-Jeroen Frijters for @code{ClassLoader} and nio cleanups, serialization fixes,
-better @code{Proxy} support, bug fixes and IKVM integration.
-
-@item
-Santiago Gala for @code{AccessControlContext} fixes.
-
-@item
-Nicolas Geoffray for @code{VMClassLoader} and @code{AccessController}
-improvements.
-
-@item
-David Gilbert for @code{basic} and @code{metal} icon and plaf support
-and lots of documenting, Lots of Free Swing and metal theme
-additions. @code{MetalIconFactory} implementation.
-
-@item
-Anthony Green for @code{MIDI} framework, @code{ALSA} and @code{DSSI}
-providers.
-
-@item
-Andrew Haley for @code{Serialization} and @code{URLClassLoader} fixes,
-gcj build speedups.
-
-@item
-Kim Ho for @code{JFileChooser} implementation.
-
-@item
-Andrew John Hughes for @code{Locale} and net fixes, URI RFC2986
-updates, @code{Serialization} fixes, @code{Properties} XML support and
-generic branch work, VMIntegration guide update.
-
-@item
-Bastiaan Huisman for @code{TimeZone} bug fixing.
-
-@item
-Andreas Jaeger for mprec updates.
-
-@item
-Paul Jenner for better @option{-Werror} support.
-
-@item
-Ito Kazumitsu for @code{NetworkInterface} implementation and updates.
-
-@item
-Roman Kennke for @code{BoxLayout}, @code{GrayFilter} and
-@code{SplitPane}, plus bug fixes all over. Lots of Free Swing work
-including styled text.
-
-@item
-Simon Kitching for @code{String} cleanups and optimization suggestions.
-
-@item
-Michael Koch for configuration fixes, @code{Locale} updates, bug and
-build fixes.
-
-@item
-Guilhem Lavaux for configuration, thread and channel fixes and Kaffe
-integration. JCL native @code{Pointer} updates. Logger bug fixes.
-
-@item
-David Lichteblau for JCL support library global/local reference
-cleanups.
-
-@item
-Aaron Luchko for JDWP updates and documentation fixes.
-
-@item
-Ziga Mahkovec for @code{Graphics2D} upgraded to Cairo 0.5 and new regex
-features.
-
-@item
-Sven de Marothy for BMP imageio support, CSS and @code{TextLayout}
-fixes. @code{GtkImage} rewrite, 2D, awt, free swing and date/time fixes and
-implementing the Qt4 peers.
-
-@item
-Casey Marshall for crypto algorithm fixes, @code{FileChannel} lock,
-@code{SystemLogger} and @code{FileHandler} rotate implementations, NIO
-@code{FileChannel.map} support, security and policy updates.
-
-@item
-Bryce McKinlay for RMI work.
-
-@item
-Audrius Meskauskas for lots of Free Corba, RMI and HTML work plus
-testing and documenting.
-
-@item
-Kalle Olavi Niemitalo for build fixes.
-
-@item
-Rainer Orth for build fixes.
-
-@item
-Andrew Overholt for @code{File} locking fixes.
-
-@item
-Ingo Proetel for @code{Image}, @code{Logger} and @code{URLClassLoader}
-updates.
-
-@item
-Olga Rodimina for @code{MenuSelectionManager} implementation.
-
-@item
-Jan Roehrich for @code{BasicTreeUI} and @code{JTree} fixes.
-
-@item
-Julian Scheid for documentation updates and gjdoc support.
-
-@item
-Christian Schlichtherle for zip fixes and cleanups.
-
-@item
-Robert Schuster for documentation updates and beans fixes,
-@code{TreeNode} enumerations and @code{ActionCommand} and various
-fixes, XML and URL, AWT and Free Swing bug fixes.
-
-@item
-Keith Seitz for lots of JDWP work.
-
-@item
-Christian Thalinger for 64-bit cleanups, Configuration and VM
-interface fixes and @code{CACAO} integration, @code{fdlibm} updates.
-
-@item
-Gael Thomas for @code{VMClassLoader} boot packages support suggestions.
-
-@item
-Andreas Tobler for Darwin and Solaris testing and fixing, @code{Qt4}
-support for Darwin/OS X, @code{Graphics2D} support, @code{gtk+}
-updates.
-
-@item
-Dalibor Topic for better @code{DEBUG} support, build cleanups and
-Kaffe integration. @code{Qt4} build infrastructure, @code{SHA1PRNG}
-and @code{GdkPixbugDecoder} updates.
-
-@item
-Tom Tromey for Eclipse integration, generics work, lots of bug fixes
-and gcj integration including coordinating The Big Merge.
-
-@item
-Mark Wielaard for bug fixes, packaging and release management,
-@code{Clipboard} implementation, system call interrupts and network
-timeouts and @code{GdkPixpufDecoder} fixes.
-
-@end itemize
-
-
-In addition to the above, all of which also contributed time and energy in
-testing GCC, we would like to thank the following for their contributions
-to testing:
-
-@itemize @bullet
-@item
-Michael Abd-El-Malek
-
-@item
-Thomas Arend
-
-@item
-Bonzo Armstrong
-
-@item
-Steven Ashe
-
-@item
-Chris Baldwin
-
-@item
-David Billinghurst
-
-@item
-Jim Blandy
-
-@item
-Stephane Bortzmeyer
-
-@item
-Horst von Brand
-
-@item
-Frank Braun
-
-@item
-Rodney Brown
-
-@item
-Sidney Cadot
-
-@item
-Bradford Castalia
-
-@item
-Robert Clark
-
-@item
-Jonathan Corbet
-
-@item
-Ralph Doncaster
-
-@item
-Richard Emberson
-
-@item
-Levente Farkas
-
-@item
-Graham Fawcett
-
-@item
-Mark Fernyhough
-
-@item
-Robert A. French
-
-@item
-J@"orgen Freyh
-
-@item
-Mark K. Gardner
-
-@item
-Charles-Antoine Gauthier
-
-@item
-Yung Shing Gene
-
-@item
-David Gilbert
-
-@item
-Simon Gornall
-
-@item
-Fred Gray
-
-@item
-John Griffin
-
-@item
-Patrik Hagglund
-
-@item
-Phil Hargett
-
-@item
-Amancio Hasty
-
-@item
-Takafumi Hayashi
-
-@item
-Bryan W. Headley
-
-@item
-Kevin B. Hendricks
-
-@item
-Joep Jansen
-
-@item
-Christian Joensson
-
-@item
-Michel Kern
-
-@item
-David Kidd
-
-@item
-Tobias Kuipers
-
-@item
-Anand Krishnaswamy
-
-@item
-A. O. V. Le Blanc
-
-@item
-llewelly
-
-@item
-Damon Love
-
-@item
-Brad Lucier
-
-@item
-Matthias Klose
-
-@item
-Martin Knoblauch
-
-@item
-Rick Lutowski
-
-@item
-Jesse Macnish
-
-@item
-Stefan Morrell
-
-@item
-Anon A. Mous
-
-@item
-Matthias Mueller
-
-@item
-Pekka Nikander
-
-@item
-Rick Niles
-
-@item
-Jon Olson
-
-@item
-Magnus Persson
-
-@item
-Chris Pollard
-
-@item
-Richard Polton
-
-@item
-Derk Reefman
-
-@item
-David Rees
-
-@item
-Paul Reilly
-
-@item
-Tom Reilly
-
-@item
-Torsten Rueger
-
-@item
-Danny Sadinoff
-
-@item
-Marc Schifer
-
-@item
-Erik Schnetter
-
-@item
-Wayne K. Schroll
-
-@item
-David Schuler
-
-@item
-Vin Shelton
-
-@item
-Tim Souder
-
-@item
-Adam Sulmicki
-
-@item
-Bill Thorson
-
-@item
-George Talbot
-
-@item
-Pedro A. M. Vazquez
-
-@item
-Gregory Warnes
-
-@item
-Ian Watson
-
-@item
-David E. Young
-
-@item
-And many others
-@end itemize
-
-And finally we'd like to thank everyone who uses the compiler, provides
-feedback and generally reminds us why we're doing this work in the first
-place.
diff --git a/contrib/gcc-5.0/gcc/doc/contribute.texi b/contrib/gcc-5.0/gcc/doc/contribute.texi
deleted file mode 100644 (file)
index 2f983d2..0000000
+++ /dev/null
@@ -1,24 +0,0 @@
-@c Copyright (C) 1988-2015 Free Software Foundation, Inc.
-@c This is part of the GCC manual.
-@c For copying conditions, see the file gcc.texi.
-
-@node Contributing
-@chapter Contributing to GCC Development
-
-If you would like to help pretest GCC releases to assure they work well,
-current development sources are available by SVN (see
-@uref{http://gcc.gnu.org/svn.html}).  Source and binary snapshots are
-also available for FTP; see @uref{http://gcc.gnu.org/snapshots.html}.
-
-If you would like to work on improvements to GCC, please read the
-advice at these URLs:
-
-@smallexample
-@uref{http://gcc.gnu.org/contribute.html}
-@uref{http://gcc.gnu.org/contributewhy.html}
-@end smallexample
-
-@noindent
-for information on how to make useful contributions and avoid
-duplication of effort.  Suggested projects are listed at
-@uref{http://gcc.gnu.org/projects/}.
diff --git a/contrib/gcc-5.0/gcc/doc/cpp.texi b/contrib/gcc-5.0/gcc/doc/cpp.texi
deleted file mode 100644 (file)
index 118ba7c..0000000
+++ /dev/null
@@ -1,4525 +0,0 @@
-\input texinfo
-@setfilename cpp.info
-@settitle The C Preprocessor
-@setchapternewpage off
-@c @smallbook
-@c @cropmarks
-@c @finalout
-
-@include gcc-common.texi
-
-@copying
-@c man begin COPYRIGHT
-Copyright @copyright{} 1987-2015 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.3 or
-any later version published by the Free Software Foundation.  A copy of
-the license is included in the
-@c man end
-section entitled ``GNU Free Documentation License''.
-@ignore
-@c man begin COPYRIGHT
-man page gfdl(7).
-@c man end
-@end ignore
-
-@c man begin COPYRIGHT
-This manual contains no Invariant Sections.  The Front-Cover Texts are
-(a) (see below), and the Back-Cover Texts are (b) (see below).
-
-(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.
-@c man end
-@end copying
-
-@c Create a separate index for command line options.
-@defcodeindex op
-@syncodeindex vr op
-
-@c Used in cppopts.texi and cppenv.texi.
-@set cppmanual
-
-@ifinfo
-@dircategory Software development
-@direntry
-* Cpp: (cpp).                  The GNU C preprocessor.
-@end direntry
-@end ifinfo
-
-@titlepage
-@title The C Preprocessor
-@versionsubtitle
-@author Richard M. Stallman, Zachary Weinberg
-@page
-@c There is a fill at the bottom of the page, so we need a filll to
-@c override it.
-@vskip 0pt plus 1filll
-@insertcopying
-@end titlepage
-@contents
-@page
-
-@ifnottex
-@node Top
-@top
-The C preprocessor implements the macro language used to transform C,
-C++, and Objective-C programs before they are compiled.  It can also be
-useful on its own.
-
-@menu
-* Overview::
-* Header Files::
-* Macros::
-* Conditionals::
-* Diagnostics::
-* Line Control::
-* Pragmas::
-* Other Directives::
-* Preprocessor Output::
-* Traditional Mode::
-* Implementation Details::
-* Invocation::
-* Environment Variables::
-* GNU Free Documentation License::
-* Index of Directives::
-* Option Index::
-* Concept Index::
-
-@detailmenu
- --- The Detailed Node Listing ---
-
-Overview
-
-* Character sets::
-* Initial processing::
-* Tokenization::
-* The preprocessing language::
-
-Header Files
-
-* Include Syntax::
-* Include Operation::
-* Search Path::
-* Once-Only Headers::
-* Alternatives to Wrapper #ifndef::
-* Computed Includes::
-* Wrapper Headers::
-* System Headers::
-
-Macros
-
-* Object-like Macros::
-* Function-like Macros::
-* Macro Arguments::
-* Stringification::
-* Concatenation::
-* Variadic Macros::
-* Predefined Macros::
-* Undefining and Redefining Macros::
-* Directives Within Macro Arguments::
-* Macro Pitfalls::
-
-Predefined Macros
-
-* Standard Predefined Macros::
-* Common Predefined Macros::
-* System-specific Predefined Macros::
-* C++ Named Operators::
-
-Macro Pitfalls
-
-* Misnesting::
-* Operator Precedence Problems::
-* Swallowing the Semicolon::
-* Duplication of Side Effects::
-* Self-Referential Macros::
-* Argument Prescan::
-* Newlines in Arguments::
-
-Conditionals
-
-* Conditional Uses::
-* Conditional Syntax::
-* Deleted Code::
-
-Conditional Syntax
-
-* Ifdef::
-* If::
-* Defined::
-* Else::
-* Elif::
-
-Implementation Details
-
-* Implementation-defined behavior::
-* Implementation limits::
-* Obsolete Features::
-* Differences from previous versions::
-
-Obsolete Features
-
-* Obsolete Features::
-
-@end detailmenu
-@end menu
-
-@insertcopying
-@end ifnottex
-
-@node Overview
-@chapter Overview
-@c man begin DESCRIPTION
-The C preprocessor, often known as @dfn{cpp}, is a @dfn{macro processor}
-that is used automatically by the C compiler to transform your program
-before compilation.  It is called a macro processor because it allows
-you to define @dfn{macros}, which are brief abbreviations for longer
-constructs.
-
-The C preprocessor is intended to be used only with C, C++, and
-Objective-C source code.  In the past, it has been abused as a general
-text processor.  It will choke on input which does not obey C's lexical
-rules.  For example, apostrophes will be interpreted as the beginning of
-character constants, and cause errors.  Also, you cannot rely on it
-preserving characteristics of the input which are not significant to
-C-family languages.  If a Makefile is preprocessed, all the hard tabs
-will be removed, and the Makefile will not work.
-
-Having said that, you can often get away with using cpp on things which
-are not C@.  Other Algol-ish programming languages are often safe
-(Pascal, Ada, etc.) So is assembly, with caution.  @option{-traditional-cpp}
-mode preserves more white space, and is otherwise more permissive.  Many
-of the problems can be avoided by writing C or C++ style comments
-instead of native language comments, and keeping macros simple.
-
-Wherever possible, you should use a preprocessor geared to the language
-you are writing in.  Modern versions of the GNU assembler have macro
-facilities.  Most high level programming languages have their own
-conditional compilation and inclusion mechanism.  If all else fails,
-try a true general text processor, such as GNU M4.
-
-C preprocessors vary in some details.  This manual discusses the GNU C
-preprocessor, which provides a small superset of the features of ISO
-Standard C@.  In its default mode, the GNU C preprocessor does not do a
-few things required by the standard.  These are features which are
-rarely, if ever, used, and may cause surprising changes to the meaning
-of a program which does not expect them.  To get strict ISO Standard C,
-you should use the @option{-std=c90}, @option{-std=c99} or
-@option{-std=c11} options, depending
-on which version of the standard you want.  To get all the mandatory
-diagnostics, you must also use @option{-pedantic}.  @xref{Invocation}.
-
-This manual describes the behavior of the ISO preprocessor.  To
-minimize gratuitous differences, where the ISO preprocessor's
-behavior does not conflict with traditional semantics, the
-traditional preprocessor should behave the same way.  The various
-differences that do exist are detailed in the section @ref{Traditional
-Mode}.
-
-For clarity, unless noted otherwise, references to @samp{CPP} in this
-manual refer to GNU CPP@.
-@c man end
-
-@menu
-* Character sets::
-* Initial processing::
-* Tokenization::
-* The preprocessing language::
-@end menu
-
-@node Character sets
-@section Character sets
-
-Source code character set processing in C and related languages is
-rather complicated.  The C standard discusses two character sets, but
-there are really at least four.
-
-The files input to CPP might be in any character set at all.  CPP's
-very first action, before it even looks for line boundaries, is to
-convert the file into the character set it uses for internal
-processing.  That set is what the C standard calls the @dfn{source}
-character set.  It must be isomorphic with ISO 10646, also known as
-Unicode.  CPP uses the UTF-8 encoding of Unicode.
-
-The character sets of the input files are specified using the
-@option{-finput-charset=} option.
-
-All preprocessing work (the subject of the rest of this manual) is
-carried out in the source character set.  If you request textual
-output from the preprocessor with the @option{-E} option, it will be
-in UTF-8.
-
-After preprocessing is complete, string and character constants are
-converted again, into the @dfn{execution} character set.  This
-character set is under control of the user; the default is UTF-8,
-matching the source character set.  Wide string and character
-constants have their own character set, which is not called out
-specifically in the standard.  Again, it is under control of the user.
-The default is UTF-16 or UTF-32, whichever fits in the target's
-@code{wchar_t} type, in the target machine's byte
-order.@footnote{UTF-16 does not meet the requirements of the C
-standard for a wide character set, but the choice of 16-bit
-@code{wchar_t} is enshrined in some system ABIs so we cannot fix
-this.}  Octal and hexadecimal escape sequences do not undergo
-conversion; @t{'\x12'} has the value 0x12 regardless of the currently
-selected execution character set.  All other escapes are replaced by
-the character in the source character set that they represent, then
-converted to the execution character set, just like unescaped
-characters.
-
-In identifiers, characters outside the ASCII range can only be
-specified with the @samp{\u} and @samp{\U} escapes, not used
-directly.  If strict ISO C90 conformance is specified with an option
-such as @option{-std=c90}, or @option{-fno-extended-identifiers} is
-used, then those escapes are not permitted in identifiers.
-
-@node Initial processing
-@section Initial processing
-
-The preprocessor performs a series of textual transformations on its
-input.  These happen before all other processing.  Conceptually, they
-happen in a rigid order, and the entire file is run through each
-transformation before the next one begins.  CPP actually does them
-all at once, for performance reasons.  These transformations correspond
-roughly to the first three ``phases of translation'' described in the C
-standard.
-
-@enumerate
-@item
-@cindex line endings
-The input file is read into memory and broken into lines.
-
-Different systems use different conventions to indicate the end of a
-line.  GCC accepts the ASCII control sequences @kbd{LF}, @kbd{@w{CR
-LF}} and @kbd{CR} as end-of-line markers.  These are the canonical
-sequences used by Unix, DOS and VMS, and the classic Mac OS (before
-OSX) respectively.  You may therefore safely copy source code written
-on any of those systems to a different one and use it without
-conversion.  (GCC may lose track of the current line number if a file
-doesn't consistently use one convention, as sometimes happens when it
-is edited on computers with different conventions that share a network
-file system.)
-
-If the last line of any input file lacks an end-of-line marker, the end
-of the file is considered to implicitly supply one.  The C standard says
-that this condition provokes undefined behavior, so GCC will emit a
-warning message.
-
-@item
-@cindex trigraphs
-@anchor{trigraphs}If trigraphs are enabled, they are replaced by their
-corresponding single characters.  By default GCC ignores trigraphs,
-but if you request a strictly conforming mode with the @option{-std}
-option, or you specify the @option{-trigraphs} option, then it
-converts them.
-
-These are nine three-character sequences, all starting with @samp{??},
-that are defined by ISO C to stand for single characters.  They permit
-obsolete systems that lack some of C's punctuation to use C@.  For
-example, @samp{??/} stands for @samp{\}, so @t{'??/n'} is a character
-constant for a newline.
-
-Trigraphs are not popular and many compilers implement them
-incorrectly.  Portable code should not rely on trigraphs being either
-converted or ignored.  With @option{-Wtrigraphs} GCC will warn you
-when a trigraph may change the meaning of your program if it were
-converted.  @xref{Wtrigraphs}.
-
-In a string constant, you can prevent a sequence of question marks
-from being confused with a trigraph by inserting a backslash between
-the question marks, or by separating the string literal at the
-trigraph and making use of string literal concatenation.  @t{"(??\?)"}
-is the string @samp{(???)}, not @samp{(?]}.  Traditional C compilers
-do not recognize these idioms.
-
-The nine trigraphs and their replacements are
-
-@smallexample
-Trigraph:       ??(  ??)  ??<  ??>  ??=  ??/  ??'  ??!  ??-
-Replacement:      [    ]    @{    @}    #    \    ^    |    ~
-@end smallexample
-
-@item
-@cindex continued lines
-@cindex backslash-newline
-Continued lines are merged into one long line.
-
-A continued line is a line which ends with a backslash, @samp{\}.  The
-backslash is removed and the following line is joined with the current
-one.  No space is inserted, so you may split a line anywhere, even in
-the middle of a word.  (It is generally more readable to split lines
-only at white space.)
-
-The trailing backslash on a continued line is commonly referred to as a
-@dfn{backslash-newline}.
-
-If there is white space between a backslash and the end of a line, that
-is still a continued line.  However, as this is usually the result of an
-editing mistake, and many compilers will not accept it as a continued
-line, GCC will warn you about it.
-
-@item
-@cindex comments
-@cindex line comments
-@cindex block comments
-All comments are replaced with single spaces.
-
-There are two kinds of comments.  @dfn{Block comments} begin with
-@samp{/*} and continue until the next @samp{*/}.  Block comments do not
-nest:
-
-@smallexample
-/* @r{this is} /* @r{one comment} */ @r{text outside comment}
-@end smallexample
-
-@dfn{Line comments} begin with @samp{//} and continue to the end of the
-current line.  Line comments do not nest either, but it does not matter,
-because they would end in the same place anyway.
-
-@smallexample
-// @r{this is} // @r{one comment}
-@r{text outside comment}
-@end smallexample
-@end enumerate
-
-It is safe to put line comments inside block comments, or vice versa.
-
-@smallexample
-@group
-/* @r{block comment}
-   // @r{contains line comment}
-   @r{yet more comment}
- */ @r{outside comment}
-
-// @r{line comment} /* @r{contains block comment} */
-@end group
-@end smallexample
-
-But beware of commenting out one end of a block comment with a line
-comment.
-
-@smallexample
-@group
- // @r{l.c.}  /* @r{block comment begins}
-    @r{oops! this isn't a comment anymore} */
-@end group
-@end smallexample
-
-Comments are not recognized within string literals.
-@t{@w{"/* blah */"}} is the string constant @samp{@w{/* blah */}}, not
-an empty string.
-
-Line comments are not in the 1989 edition of the C standard, but they
-are recognized by GCC as an extension.  In C++ and in the 1999 edition
-of the C standard, they are an official part of the language.
-
-Since these transformations happen before all other processing, you can
-split a line mechanically with backslash-newline anywhere.  You can
-comment out the end of a line.  You can continue a line comment onto the
-next line with backslash-newline.  You can even split @samp{/*},
-@samp{*/}, and @samp{//} onto multiple lines with backslash-newline.
-For example:
-
-@smallexample
-@group
-/\
-*
-*/ # /*
-*/ defi\
-ne FO\
-O 10\
-20
-@end group
-@end smallexample
-
-@noindent
-is equivalent to @code{@w{#define FOO 1020}}.  All these tricks are
-extremely confusing and should not be used in code intended to be
-readable.
-
-There is no way to prevent a backslash at the end of a line from being
-interpreted as a backslash-newline.  This cannot affect any correct
-program, however.
-
-@node Tokenization
-@section Tokenization
-
-@cindex tokens
-@cindex preprocessing tokens
-After the textual transformations are finished, the input file is
-converted into a sequence of @dfn{preprocessing tokens}.  These mostly
-correspond to the syntactic tokens used by the C compiler, but there are
-a few differences.  White space separates tokens; it is not itself a
-token of any kind.  Tokens do not have to be separated by white space,
-but it is often necessary to avoid ambiguities.
-
-When faced with a sequence of characters that has more than one possible
-tokenization, the preprocessor is greedy.  It always makes each token,
-starting from the left, as big as possible before moving on to the next
-token.  For instance, @code{a+++++b} is interpreted as
-@code{@w{a ++ ++ + b}}, not as @code{@w{a ++ + ++ b}}, even though the
-latter tokenization could be part of a valid C program and the former
-could not.
-
-Once the input file is broken into tokens, the token boundaries never
-change, except when the @samp{##} preprocessing operator is used to paste
-tokens together.  @xref{Concatenation}.  For example,
-
-@smallexample
-@group
-#define foo() bar
-foo()baz
-     @expansion{} bar baz
-@emph{not}
-     @expansion{} barbaz
-@end group
-@end smallexample
-
-The compiler does not re-tokenize the preprocessor's output.  Each
-preprocessing token becomes one compiler token.
-
-@cindex identifiers
-Preprocessing tokens fall into five broad classes: identifiers,
-preprocessing numbers, string literals, punctuators, and other.  An
-@dfn{identifier} is the same as an identifier in C: any sequence of
-letters, digits, or underscores, which begins with a letter or
-underscore.  Keywords of C have no significance to the preprocessor;
-they are ordinary identifiers.  You can define a macro whose name is a
-keyword, for instance.  The only identifier which can be considered a
-preprocessing keyword is @code{defined}.  @xref{Defined}.
-
-This is mostly true of other languages which use the C preprocessor.
-However, a few of the keywords of C++ are significant even in the
-preprocessor.  @xref{C++ Named Operators}.
-
-In the 1999 C standard, identifiers may contain letters which are not
-part of the ``basic source character set'', at the implementation's
-discretion (such as accented Latin letters, Greek letters, or Chinese
-ideograms).  This may be done with an extended character set, or the
-@samp{\u} and @samp{\U} escape sequences.  GCC only accepts such
-characters in the @samp{\u} and @samp{\U} forms.
-
-As an extension, GCC treats @samp{$} as a letter.  This is for
-compatibility with some systems, such as VMS, where @samp{$} is commonly
-used in system-defined function and object names.  @samp{$} is not a
-letter in strictly conforming mode, or if you specify the @option{-$}
-option.  @xref{Invocation}.
-
-@cindex numbers
-@cindex preprocessing numbers
-A @dfn{preprocessing number} has a rather bizarre definition.  The
-category includes all the normal integer and floating point constants
-one expects of C, but also a number of other things one might not
-initially recognize as a number.  Formally, preprocessing numbers begin
-with an optional period, a required decimal digit, and then continue
-with any sequence of letters, digits, underscores, periods, and
-exponents.  Exponents are the two-character sequences @samp{e+},
-@samp{e-}, @samp{E+}, @samp{E-}, @samp{p+}, @samp{p-}, @samp{P+}, and
-@samp{P-}.  (The exponents that begin with @samp{p} or @samp{P} are new
-to C99.  They are used for hexadecimal floating-point constants.)
-
-The purpose of this unusual definition is to isolate the preprocessor
-from the full complexity of numeric constants.  It does not have to
-distinguish between lexically valid and invalid floating-point numbers,
-which is complicated.  The definition also permits you to split an
-identifier at any position and get exactly two tokens, which can then be
-pasted back together with the @samp{##} operator.
-
-It's possible for preprocessing numbers to cause programs to be
-misinterpreted.  For example, @code{0xE+12} is a preprocessing number
-which does not translate to any valid numeric constant, therefore a
-syntax error.  It does not mean @code{@w{0xE + 12}}, which is what you
-might have intended.
-
-@cindex string literals
-@cindex string constants
-@cindex character constants
-@cindex header file names
-@c the @: prevents makeinfo from turning '' into ".
-@dfn{String literals} are string constants, character constants, and
-header file names (the argument of @samp{#include}).@footnote{The C
-standard uses the term @dfn{string literal} to refer only to what we are
-calling @dfn{string constants}.}  String constants and character
-constants are straightforward: @t{"@dots{}"} or @t{'@dots{}'}.  In
-either case embedded quotes should be escaped with a backslash:
-@t{'\'@:'} is the character constant for @samp{'}.  There is no limit on
-the length of a character constant, but the value of a character
-constant that contains more than one character is
-implementation-defined.  @xref{Implementation Details}.
-
-Header file names either look like string constants, @t{"@dots{}"}, or are
-written with angle brackets instead, @t{<@dots{}>}.  In either case,
-backslash is an ordinary character.  There is no way to escape the
-closing quote or angle bracket.  The preprocessor looks for the header
-file in different places depending on which form you use.  @xref{Include
-Operation}.
-
-No string literal may extend past the end of a line.  Older versions
-of GCC accepted multi-line string constants.  You may use continued
-lines instead, or string constant concatenation.  @xref{Differences
-from previous versions}.
-
-@cindex punctuators
-@cindex digraphs
-@cindex alternative tokens
-@dfn{Punctuators} are all the usual bits of punctuation which are
-meaningful to C and C++.  All but three of the punctuation characters in
-ASCII are C punctuators.  The exceptions are @samp{@@}, @samp{$}, and
-@samp{`}.  In addition, all the two- and three-character operators are
-punctuators.  There are also six @dfn{digraphs}, which the C++ standard
-calls @dfn{alternative tokens}, which are merely alternate ways to spell
-other punctuators.  This is a second attempt to work around missing
-punctuation in obsolete systems.  It has no negative side effects,
-unlike trigraphs, but does not cover as much ground.  The digraphs and
-their corresponding normal punctuators are:
-
-@smallexample
-Digraph:        <%  %>  <:  :>  %:  %:%:
-Punctuator:      @{   @}   [   ]   #    ##
-@end smallexample
-
-@cindex other tokens
-Any other single character is considered ``other''.  It is passed on to
-the preprocessor's output unmolested.  The C compiler will almost
-certainly reject source code containing ``other'' tokens.  In ASCII, the
-only other characters are @samp{@@}, @samp{$}, @samp{`}, and control
-characters other than NUL (all bits zero).  (Note that @samp{$} is
-normally considered a letter.)  All characters with the high bit set
-(numeric range 0x7F--0xFF) are also ``other'' in the present
-implementation.  This will change when proper support for international
-character sets is added to GCC@.
-
-NUL is a special case because of the high probability that its
-appearance is accidental, and because it may be invisible to the user
-(many terminals do not display NUL at all).  Within comments, NULs are
-silently ignored, just as any other character would be.  In running
-text, NUL is considered white space.  For example, these two directives
-have the same meaning.
-
-@smallexample
-#define X^@@1
-#define X 1
-@end smallexample
-
-@noindent
-(where @samp{^@@} is ASCII NUL)@.  Within string or character constants,
-NULs are preserved.  In the latter two cases the preprocessor emits a
-warning message.
-
-@node The preprocessing language
-@section The preprocessing language
-@cindex directives
-@cindex preprocessing directives
-@cindex directive line
-@cindex directive name
-
-After tokenization, the stream of tokens may simply be passed straight
-to the compiler's parser.  However, if it contains any operations in the
-@dfn{preprocessing language}, it will be transformed first.  This stage
-corresponds roughly to the standard's ``translation phase 4'' and is
-what most people think of as the preprocessor's job.
-
-The preprocessing language consists of @dfn{directives} to be executed
-and @dfn{macros} to be expanded.  Its primary capabilities are:
-
-@itemize @bullet
-@item
-Inclusion of header files.  These are files of declarations that can be
-substituted into your program.
-
-@item
-Macro expansion.  You can define @dfn{macros}, which are abbreviations
-for arbitrary fragments of C code.  The preprocessor will replace the
-macros with their definitions throughout the program.  Some macros are
-automatically defined for you.
-
-@item
-Conditional compilation.  You can include or exclude parts of the
-program according to various conditions.
-
-@item
-Line control.  If you use a program to combine or rearrange source files
-into an intermediate file which is then compiled, you can use line
-control to inform the compiler where each source line originally came
-from.
-
-@item
-Diagnostics.  You can detect problems at compile time and issue errors
-or warnings.
-@end itemize
-
-There are a few more, less useful, features.
-
-Except for expansion of predefined macros, all these operations are
-triggered with @dfn{preprocessing directives}.  Preprocessing directives
-are lines in your program that start with @samp{#}.  Whitespace is
-allowed before and after the @samp{#}.  The @samp{#} is followed by an
-identifier, the @dfn{directive name}.  It specifies the operation to
-perform.  Directives are commonly referred to as @samp{#@var{name}}
-where @var{name} is the directive name.  For example, @samp{#define} is
-the directive that defines a macro.
-
-The @samp{#} which begins a directive cannot come from a macro
-expansion.  Also, the directive name is not macro expanded.  Thus, if
-@code{foo} is defined as a macro expanding to @code{define}, that does
-not make @samp{#foo} a valid preprocessing directive.
-
-The set of valid directive names is fixed.  Programs cannot define new
-preprocessing directives.
-
-Some directives require arguments; these make up the rest of the
-directive line and must be separated from the directive name by
-whitespace.  For example, @samp{#define} must be followed by a macro
-name and the intended expansion of the macro.
-
-A preprocessing directive cannot cover more than one line.  The line
-may, however, be continued with backslash-newline, or by a block comment
-which extends past the end of the line.  In either case, when the
-directive is processed, the continuations have already been merged with
-the first line to make one long line.
-
-@node Header Files
-@chapter Header Files
-
-@cindex header file
-A header file is a file containing C declarations and macro definitions
-(@pxref{Macros}) to be shared between several source files.  You request
-the use of a header file in your program by @dfn{including} it, with the
-C preprocessing directive @samp{#include}.
-
-Header files serve two purposes.
-
-@itemize @bullet
-@item
-@cindex system header files
-System header files declare the interfaces to parts of the operating
-system.  You include them in your program to supply the definitions and
-declarations you need to invoke system calls and libraries.
-
-@item
-Your own header files contain declarations for interfaces between the
-source files of your program.  Each time you have a group of related
-declarations and macro definitions all or most of which are needed in
-several different source files, it is a good idea to create a header
-file for them.
-@end itemize
-
-Including a header file produces the same results as copying the header
-file into each source file that needs it.  Such copying would be
-time-consuming and error-prone.  With a header file, the related
-declarations appear in only one place.  If they need to be changed, they
-can be changed in one place, and programs that include the header file
-will automatically use the new version when next recompiled.  The header
-file eliminates the labor of finding and changing all the copies as well
-as the risk that a failure to find one copy will result in
-inconsistencies within a program.
-
-In C, the usual convention is to give header files names that end with
-@file{.h}.  It is most portable to use only letters, digits, dashes, and
-underscores in header file names, and at most one dot.
-
-@menu
-* Include Syntax::
-* Include Operation::
-* Search Path::
-* Once-Only Headers::
-* Alternatives to Wrapper #ifndef::
-* Computed Includes::
-* Wrapper Headers::
-* System Headers::
-@end menu
-
-@node Include Syntax
-@section Include Syntax
-
-@findex #include
-Both user and system header files are included using the preprocessing
-directive @samp{#include}.  It has two variants:
-
-@table @code
-@item #include <@var{file}>
-This variant is used for system header files.  It searches for a file
-named @var{file} in a standard list of system directories.  You can prepend
-directories to this list with the @option{-I} option (@pxref{Invocation}).
-
-@item #include "@var{file}"
-This variant is used for header files of your own program.  It
-searches for a file named @var{file} first in the directory containing
-the current file, then in the quote directories and then the same
-directories used for @code{<@var{file}>}.  You can prepend directories
-to the list of quote directories with the @option{-iquote} option.
-@end table
-
-The argument of @samp{#include}, whether delimited with quote marks or
-angle brackets, behaves like a string constant in that comments are not
-recognized, and macro names are not expanded.  Thus, @code{@w{#include
-<x/*y>}} specifies inclusion of a system header file named @file{x/*y}.
-
-However, if backslashes occur within @var{file}, they are considered
-ordinary text characters, not escape characters.  None of the character
-escape sequences appropriate to string constants in C are processed.
-Thus, @code{@w{#include "x\n\\y"}} specifies a filename containing three
-backslashes.  (Some systems interpret @samp{\} as a pathname separator.
-All of these also interpret @samp{/} the same way.  It is most portable
-to use only @samp{/}.)
-
-It is an error if there is anything (other than comments) on the line
-after the file name.
-
-@node Include Operation
-@section Include Operation
-
-The @samp{#include} directive works by directing the C preprocessor to
-scan the specified file as input before continuing with the rest of the
-current file.  The output from the preprocessor contains the output
-already generated, followed by the output resulting from the included
-file, followed by the output that comes from the text after the
-@samp{#include} directive.  For example, if you have a header file
-@file{header.h} as follows,
-
-@smallexample
-char *test (void);
-@end smallexample
-
-@noindent
-and a main program called @file{program.c} that uses the header file,
-like this,
-
-@smallexample
-int x;
-#include "header.h"
-
-int
-main (void)
-@{
-  puts (test ());
-@}
-@end smallexample
-
-@noindent
-the compiler will see the same token stream as it would if
-@file{program.c} read
-
-@smallexample
-int x;
-char *test (void);
-
-int
-main (void)
-@{
-  puts (test ());
-@}
-@end smallexample
-
-Included files are not limited to declarations and macro definitions;
-those are merely the typical uses.  Any fragment of a C program can be
-included from another file.  The include file could even contain the
-beginning of a statement that is concluded in the containing file, or
-the end of a statement that was started in the including file.  However,
-an included file must consist of complete tokens.  Comments and string
-literals which have not been closed by the end of an included file are
-invalid.  For error recovery, they are considered to end at the end of
-the file.
-
-To avoid confusion, it is best if header files contain only complete
-syntactic units---function declarations or definitions, type
-declarations, etc.
-
-The line following the @samp{#include} directive is always treated as a
-separate line by the C preprocessor, even if the included file lacks a
-final newline.
-
-@node Search Path
-@section Search Path
-
-GCC looks in several different places for headers.  On a normal Unix
-system, if you do not instruct it otherwise, it will look for headers
-requested with @code{@w{#include <@var{file}>}} in:
-
-@smallexample
-/usr/local/include
-@var{libdir}/gcc/@var{target}/@var{version}/include
-/usr/@var{target}/include
-/usr/include
-@end smallexample
-
-For C++ programs, it will also look in
-@file{@var{libdir}/../include/c++/@var{version}},
-first.  In the above, @var{target} is the canonical name of the system
-GCC was configured to compile code for; often but not always the same as
-the canonical name of the system it runs on.  @var{version} is the
-version of GCC in use.
-
-You can add to this list with the @option{-I@var{dir}} command-line
-option.  All the directories named by @option{-I} are searched, in
-left-to-right order, @emph{before} the default directories.  The only
-exception is when @file{dir} is already searched by default.  In
-this case, the option is ignored and the search order for system
-directories remains unchanged.
-
-Duplicate directories are removed from the quote and bracket search
-chains before the two chains are merged to make the final search chain.
-Thus, it is possible for a directory to occur twice in the final search
-chain if it was specified in both the quote and bracket chains.
-
-You can prevent GCC from searching any of the default directories with
-the @option{-nostdinc} option.  This is useful when you are compiling an
-operating system kernel or some other program that does not use the
-standard C library facilities, or the standard C library itself.
-@option{-I} options are not ignored as described above when
-@option{-nostdinc} is in effect.
-
-GCC looks for headers requested with @code{@w{#include "@var{file}"}}
-first in the directory containing the current file, then in the
-directories as specified by @option{-iquote} options, then in the same
-places it would have looked for a header requested with angle
-brackets.  For example, if @file{/usr/include/sys/stat.h} contains
-@code{@w{#include "types.h"}}, GCC looks for @file{types.h} first in
-@file{/usr/include/sys}, then in its usual search path.
-
-@samp{#line} (@pxref{Line Control}) does not change GCC's idea of the
-directory containing the current file.
-
-You may put @option{-I-} at any point in your list of @option{-I} options.
-This has two effects.  First, directories appearing before the
-@option{-I-} in the list are searched only for headers requested with
-quote marks.  Directories after @option{-I-} are searched for all
-headers.  Second, the directory containing the current file is not
-searched for anything, unless it happens to be one of the directories
-named by an @option{-I} switch.  @option{-I-} is deprecated, @option{-iquote}
-should be used instead.
-
-@option{-I. -I-} is not the same as no @option{-I} options at all, and does
-not cause the same behavior for @samp{<>} includes that @samp{""}
-includes get with no special options.  @option{-I.} searches the
-compiler's current working directory for header files.  That may or may
-not be the same as the directory containing the current file.
-
-If you need to look for headers in a directory named @file{-}, write
-@option{-I./-}.
-
-There are several more ways to adjust the header search path.  They are
-generally less useful.  @xref{Invocation}.
-
-@node Once-Only Headers
-@section Once-Only Headers
-@cindex repeated inclusion
-@cindex including just once
-@cindex wrapper @code{#ifndef}
-
-If a header file happens to be included twice, the compiler will process
-its contents twice.  This is very likely to cause an error, e.g.@: when the
-compiler sees the same structure definition twice.  Even if it does not,
-it will certainly waste time.
-
-The standard way to prevent this is to enclose the entire real contents
-of the file in a conditional, like this:
-
-@smallexample
-@group
-/* File foo.  */
-#ifndef FILE_FOO_SEEN
-#define FILE_FOO_SEEN
-
-@var{the entire file}
-
-#endif /* !FILE_FOO_SEEN */
-@end group
-@end smallexample
-
-This construct is commonly known as a @dfn{wrapper #ifndef}.
-When the header is included again, the conditional will be false,
-because @code{FILE_FOO_SEEN} is defined.  The preprocessor will skip
-over the entire contents of the file, and the compiler will not see it
-twice.
-
-CPP optimizes even further.  It remembers when a header file has a
-wrapper @samp{#ifndef}.  If a subsequent @samp{#include} specifies that
-header, and the macro in the @samp{#ifndef} is still defined, it does
-not bother to rescan the file at all.
-
-You can put comments outside the wrapper.  They will not interfere with
-this optimization.
-
-@cindex controlling macro
-@cindex guard macro
-The macro @code{FILE_FOO_SEEN} is called the @dfn{controlling macro} or
-@dfn{guard macro}.  In a user header file, the macro name should not
-begin with @samp{_}.  In a system header file, it should begin with
-@samp{__} to avoid conflicts with user programs.  In any kind of header
-file, the macro name should contain the name of the file and some
-additional text, to avoid conflicts with other header files.
-
-@node Alternatives to Wrapper #ifndef
-@section Alternatives to Wrapper #ifndef
-
-CPP supports two more ways of indicating that a header file should be
-read only once.  Neither one is as portable as a wrapper @samp{#ifndef}
-and we recommend you do not use them in new programs, with the caveat
-that @samp{#import} is standard practice in Objective-C.
-
-@findex #import
-CPP supports a variant of @samp{#include} called @samp{#import} which
-includes a file, but does so at most once.  If you use @samp{#import}
-instead of @samp{#include}, then you don't need the conditionals
-inside the header file to prevent multiple inclusion of the contents.
-@samp{#import} is standard in Objective-C, but is considered a
-deprecated extension in C and C++.
-
-@samp{#import} is not a well designed feature.  It requires the users of
-a header file to know that it should only be included once.  It is much
-better for the header file's implementor to write the file so that users
-don't need to know this.  Using a wrapper @samp{#ifndef} accomplishes
-this goal.
-
-In the present implementation, a single use of @samp{#import} will
-prevent the file from ever being read again, by either @samp{#import} or
-@samp{#include}.  You should not rely on this; do not use both
-@samp{#import} and @samp{#include} to refer to the same header file.
-
-Another way to prevent a header file from being included more than once
-is with the @samp{#pragma once} directive.  If @samp{#pragma once} is
-seen when scanning a header file, that file will never be read again, no
-matter what.
-
-@samp{#pragma once} does not have the problems that @samp{#import} does,
-but it is not recognized by all preprocessors, so you cannot rely on it
-in a portable program.
-
-@node Computed Includes
-@section Computed Includes
-@cindex computed includes
-@cindex macros in include
-
-Sometimes it is necessary to select one of several different header
-files to be included into your program.  They might specify
-configuration parameters to be used on different sorts of operating
-systems, for instance.  You could do this with a series of conditionals,
-
-@smallexample
-#if SYSTEM_1
-# include "system_1.h"
-#elif SYSTEM_2
-# include "system_2.h"
-#elif SYSTEM_3
-@dots{}
-#endif
-@end smallexample
-
-That rapidly becomes tedious.  Instead, the preprocessor offers the
-ability to use a macro for the header name.  This is called a
-@dfn{computed include}.  Instead of writing a header name as the direct
-argument of @samp{#include}, you simply put a macro name there instead:
-
-@smallexample
-#define SYSTEM_H "system_1.h"
-@dots{}
-#include SYSTEM_H
-@end smallexample
-
-@noindent
-@code{SYSTEM_H} will be expanded, and the preprocessor will look for
-@file{system_1.h} as if the @samp{#include} had been written that way
-originally.  @code{SYSTEM_H} could be defined by your Makefile with a
-@option{-D} option.
-
-You must be careful when you define the macro.  @samp{#define} saves
-tokens, not text.  The preprocessor has no way of knowing that the macro
-will be used as the argument of @samp{#include}, so it generates
-ordinary tokens, not a header name.  This is unlikely to cause problems
-if you use double-quote includes, which are close enough to string
-constants.  If you use angle brackets, however, you may have trouble.
-
-The syntax of a computed include is actually a bit more general than the
-above.  If the first non-whitespace character after @samp{#include} is
-not @samp{"} or @samp{<}, then the entire line is macro-expanded
-like running text would be.
-
-If the line expands to a single string constant, the contents of that
-string constant are the file to be included.  CPP does not re-examine the
-string for embedded quotes, but neither does it process backslash
-escapes in the string.  Therefore
-
-@smallexample
-#define HEADER "a\"b"
-#include HEADER
-@end smallexample
-
-@noindent
-looks for a file named @file{a\"b}.  CPP searches for the file according
-to the rules for double-quoted includes.
-
-If the line expands to a token stream beginning with a @samp{<} token
-and including a @samp{>} token, then the tokens between the @samp{<} and
-the first @samp{>} are combined to form the filename to be included.
-Any whitespace between tokens is reduced to a single space; then any
-space after the initial @samp{<} is retained, but a trailing space
-before the closing @samp{>} is ignored.  CPP searches for the file
-according to the rules for angle-bracket includes.
-
-In either case, if there are any tokens on the line after the file name,
-an error occurs and the directive is not processed.  It is also an error
-if the result of expansion does not match either of the two expected
-forms.
-
-These rules are implementation-defined behavior according to the C
-standard.  To minimize the risk of different compilers interpreting your
-computed includes differently, we recommend you use only a single
-object-like macro which expands to a string constant.  This will also
-minimize confusion for people reading your program.
-
-@node Wrapper Headers
-@section Wrapper Headers
-@cindex wrapper headers
-@cindex overriding a header file
-@findex #include_next
-
-Sometimes it is necessary to adjust the contents of a system-provided
-header file without editing it directly.  GCC's @command{fixincludes}
-operation does this, for example.  One way to do that would be to create
-a new header file with the same name and insert it in the search path
-before the original header.  That works fine as long as you're willing
-to replace the old header entirely.  But what if you want to refer to
-the old header from the new one?
-
-You cannot simply include the old header with @samp{#include}.  That
-will start from the beginning, and find your new header again.  If your
-header is not protected from multiple inclusion (@pxref{Once-Only
-Headers}), it will recurse infinitely and cause a fatal error.
-
-You could include the old header with an absolute pathname:
-@smallexample
-#include "/usr/include/old-header.h"
-@end smallexample
-@noindent
-This works, but is not clean; should the system headers ever move, you
-would have to edit the new headers to match.
-
-There is no way to solve this problem within the C standard, but you can
-use the GNU extension @samp{#include_next}.  It means, ``Include the
-@emph{next} file with this name''.  This directive works like
-@samp{#include} except in searching for the specified file: it starts
-searching the list of header file directories @emph{after} the directory
-in which the current file was found.
-
-Suppose you specify @option{-I /usr/local/include}, and the list of
-directories to search also includes @file{/usr/include}; and suppose
-both directories contain @file{signal.h}.  Ordinary @code{@w{#include
-<signal.h>}} finds the file under @file{/usr/local/include}.  If that
-file contains @code{@w{#include_next <signal.h>}}, it starts searching
-after that directory, and finds the file in @file{/usr/include}.
-
-@samp{#include_next} does not distinguish between @code{<@var{file}>}
-and @code{"@var{file}"} inclusion, nor does it check that the file you
-specify has the same name as the current file.  It simply looks for the
-file named, starting with the directory in the search path after the one
-where the current file was found.
-
-The use of @samp{#include_next} can lead to great confusion.  We
-recommend it be used only when there is no other alternative.  In
-particular, it should not be used in the headers belonging to a specific
-program; it should be used only to make global corrections along the
-lines of @command{fixincludes}.
-
-@node System Headers
-@section System Headers
-@cindex system header files
-
-The header files declaring interfaces to the operating system and
-runtime libraries often cannot be written in strictly conforming C@.
-Therefore, GCC gives code found in @dfn{system headers} special
-treatment.  All warnings, other than those generated by @samp{#warning}
-(@pxref{Diagnostics}), are suppressed while GCC is processing a system
-header.  Macros defined in a system header are immune to a few warnings
-wherever they are expanded.  This immunity is granted on an ad-hoc
-basis, when we find that a warning generates lots of false positives
-because of code in macros defined in system headers.
-
-Normally, only the headers found in specific directories are considered
-system headers.  These directories are determined when GCC is compiled.
-There are, however, two ways to make normal headers into system headers.
-
-The @option{-isystem} command-line option adds its argument to the list of
-directories to search for headers, just like @option{-I}.  Any headers
-found in that directory will be considered system headers.
-
-All directories named by @option{-isystem} are searched @emph{after} all
-directories named by @option{-I}, no matter what their order was on the
-command line.  If the same directory is named by both @option{-I} and
-@option{-isystem}, the @option{-I} option is ignored.  GCC provides an
-informative message when this occurs if @option{-v} is used.
-
-@findex #pragma GCC system_header
-There is also a directive, @code{@w{#pragma GCC system_header}}, which
-tells GCC to consider the rest of the current include file a system
-header, no matter where it was found.  Code that comes before the
-@samp{#pragma} in the file will not be affected.  @code{@w{#pragma GCC
-system_header}} has no effect in the primary source file.
-
-On very old systems, some of the pre-defined system header directories
-get even more special treatment.  GNU C++ considers code in headers
-found in those directories to be surrounded by an @code{@w{extern "C"}}
-block.  There is no way to request this behavior with a @samp{#pragma},
-or from the command line.
-
-@node Macros
-@chapter Macros
-
-A @dfn{macro} is a fragment of code which has been given a name.
-Whenever the name is used, it is replaced by the contents of the macro.
-There are two kinds of macros.  They differ mostly in what they look
-like when they are used.  @dfn{Object-like} macros resemble data objects
-when used, @dfn{function-like} macros resemble function calls.
-
-You may define any valid identifier as a macro, even if it is a C
-keyword.  The preprocessor does not know anything about keywords.  This
-can be useful if you wish to hide a keyword such as @code{const} from an
-older compiler that does not understand it.  However, the preprocessor
-operator @code{defined} (@pxref{Defined}) can never be defined as a
-macro, and C++'s named operators (@pxref{C++ Named Operators}) cannot be
-macros when you are compiling C++.
-
-@menu
-* Object-like Macros::
-* Function-like Macros::
-* Macro Arguments::
-* Stringification::
-* Concatenation::
-* Variadic Macros::
-* Predefined Macros::
-* Undefining and Redefining Macros::
-* Directives Within Macro Arguments::
-* Macro Pitfalls::
-@end menu
-
-@node Object-like Macros
-@section Object-like Macros
-@cindex object-like macro
-@cindex symbolic constants
-@cindex manifest constants
-
-An @dfn{object-like macro} is a simple identifier which will be replaced
-by a code fragment.  It is called object-like because it looks like a
-data object in code that uses it.  They are most commonly used to give
-symbolic names to numeric constants.
-
-@findex #define
-You create macros with the @samp{#define} directive.  @samp{#define} is
-followed by the name of the macro and then the token sequence it should
-be an abbreviation for, which is variously referred to as the macro's
-@dfn{body}, @dfn{expansion} or @dfn{replacement list}.  For example,
-
-@smallexample
-#define BUFFER_SIZE 1024
-@end smallexample
-
-@noindent
-defines a macro named @code{BUFFER_SIZE} as an abbreviation for the
-token @code{1024}.  If somewhere after this @samp{#define} directive
-there comes a C statement of the form
-
-@smallexample
-foo = (char *) malloc (BUFFER_SIZE);
-@end smallexample
-
-@noindent
-then the C preprocessor will recognize and @dfn{expand} the macro
-@code{BUFFER_SIZE}.  The C compiler will see the same tokens as it would
-if you had written
-
-@smallexample
-foo = (char *) malloc (1024);
-@end smallexample
-
-By convention, macro names are written in uppercase.  Programs are
-easier to read when it is possible to tell at a glance which names are
-macros.
-
-The macro's body ends at the end of the @samp{#define} line.  You may
-continue the definition onto multiple lines, if necessary, using
-backslash-newline.  When the macro is expanded, however, it will all
-come out on one line.  For example,
-
-@smallexample
-#define NUMBERS 1, \
-                2, \
-                3
-int x[] = @{ NUMBERS @};
-     @expansion{} int x[] = @{ 1, 2, 3 @};
-@end smallexample
-
-@noindent
-The most common visible consequence of this is surprising line numbers
-in error messages.
-
-There is no restriction on what can go in a macro body provided it
-decomposes into valid preprocessing tokens.  Parentheses need not
-balance, and the body need not resemble valid C code.  (If it does not,
-you may get error messages from the C compiler when you use the macro.)
-
-The C preprocessor scans your program sequentially.  Macro definitions
-take effect at the place you write them.  Therefore, the following input
-to the C preprocessor
-
-@smallexample
-foo = X;
-#define X 4
-bar = X;
-@end smallexample
-
-@noindent
-produces
-
-@smallexample
-foo = X;
-bar = 4;
-@end smallexample
-
-When the preprocessor expands a macro name, the macro's expansion
-replaces the macro invocation, then the expansion is examined for more
-macros to expand.  For example,
-
-@smallexample
-@group
-#define TABLESIZE BUFSIZE
-#define BUFSIZE 1024
-TABLESIZE
-     @expansion{} BUFSIZE
-     @expansion{} 1024
-@end group
-@end smallexample
-
-@noindent
-@code{TABLESIZE} is expanded first to produce @code{BUFSIZE}, then that
-macro is expanded to produce the final result, @code{1024}.
-
-Notice that @code{BUFSIZE} was not defined when @code{TABLESIZE} was
-defined.  The @samp{#define} for @code{TABLESIZE} uses exactly the
-expansion you specify---in this case, @code{BUFSIZE}---and does not
-check to see whether it too contains macro names.  Only when you
-@emph{use} @code{TABLESIZE} is the result of its expansion scanned for
-more macro names.
-
-This makes a difference if you change the definition of @code{BUFSIZE}
-at some point in the source file.  @code{TABLESIZE}, defined as shown,
-will always expand using the definition of @code{BUFSIZE} that is
-currently in effect:
-
-@smallexample
-#define BUFSIZE 1020
-#define TABLESIZE BUFSIZE
-#undef BUFSIZE
-#define BUFSIZE 37
-@end smallexample
-
-@noindent
-Now @code{TABLESIZE} expands (in two stages) to @code{37}.
-
-If the expansion of a macro contains its own name, either directly or
-via intermediate macros, it is not expanded again when the expansion is
-examined for more macros.  This prevents infinite recursion.
-@xref{Self-Referential Macros}, for the precise details.
-
-@node Function-like Macros
-@section Function-like Macros
-@cindex function-like macros
-
-You can also define macros whose use looks like a function call.  These
-are called @dfn{function-like macros}.  To define a function-like macro,
-you use the same @samp{#define} directive, but you put a pair of
-parentheses immediately after the macro name.  For example,
-
-@smallexample
-#define lang_init()  c_init()
-lang_init()
-     @expansion{} c_init()
-@end smallexample
-
-A function-like macro is only expanded if its name appears with a pair
-of parentheses after it.  If you write just the name, it is left alone.
-This can be useful when you have a function and a macro of the same
-name, and you wish to use the function sometimes.
-
-@smallexample
-extern void foo(void);
-#define foo() /* @r{optimized inline version} */
-@dots{}
-  foo();
-  funcptr = foo;
-@end smallexample
-
-Here the call to @code{foo()} will use the macro, but the function
-pointer will get the address of the real function.  If the macro were to
-be expanded, it would cause a syntax error.
-
-If you put spaces between the macro name and the parentheses in the
-macro definition, that does not define a function-like macro, it defines
-an object-like macro whose expansion happens to begin with a pair of
-parentheses.
-
-@smallexample
-#define lang_init ()    c_init()
-lang_init()
-     @expansion{} () c_init()()
-@end smallexample
-
-The first two pairs of parentheses in this expansion come from the
-macro.  The third is the pair that was originally after the macro
-invocation.  Since @code{lang_init} is an object-like macro, it does not
-consume those parentheses.
-
-@node Macro Arguments
-@section Macro Arguments
-@cindex arguments
-@cindex macros with arguments
-@cindex arguments in macro definitions
-
-Function-like macros can take @dfn{arguments}, just like true functions.
-To define a macro that uses arguments, you insert @dfn{parameters}
-between the pair of parentheses in the macro definition that make the
-macro function-like.  The parameters must be valid C identifiers,
-separated by commas and optionally whitespace.
-
-To invoke a macro that takes arguments, you write the name of the macro
-followed by a list of @dfn{actual arguments} in parentheses, separated
-by commas.  The invocation of the macro need not be restricted to a
-single logical line---it can cross as many lines in the source file as
-you wish.  The number of arguments you give must match the number of
-parameters in the macro definition.  When the macro is expanded, each
-use of a parameter in its body is replaced by the tokens of the
-corresponding argument.  (You need not use all of the parameters in the
-macro body.)
-
-As an example, here is a macro that computes the minimum of two numeric
-values, as it is defined in many C programs, and some uses.
-
-@smallexample
-#define min(X, Y)  ((X) < (Y) ? (X) : (Y))
-  x = min(a, b);          @expansion{}  x = ((a) < (b) ? (a) : (b));
-  y = min(1, 2);          @expansion{}  y = ((1) < (2) ? (1) : (2));
-  z = min(a + 28, *p);    @expansion{}  z = ((a + 28) < (*p) ? (a + 28) : (*p));
-@end smallexample
-
-@noindent
-(In this small example you can already see several of the dangers of
-macro arguments.  @xref{Macro Pitfalls}, for detailed explanations.)
-
-Leading and trailing whitespace in each argument is dropped, and all
-whitespace between the tokens of an argument is reduced to a single
-space.  Parentheses within each argument must balance; a comma within
-such parentheses does not end the argument.  However, there is no
-requirement for square brackets or braces to balance, and they do not
-prevent a comma from separating arguments.  Thus,
-
-@smallexample
-macro (array[x = y, x + 1])
-@end smallexample
-
-@noindent
-passes two arguments to @code{macro}: @code{array[x = y} and @code{x +
-1]}.  If you want to supply @code{array[x = y, x + 1]} as an argument,
-you can write it as @code{array[(x = y, x + 1)]}, which is equivalent C
-code.
-
-All arguments to a macro are completely macro-expanded before they are
-substituted into the macro body.  After substitution, the complete text
-is scanned again for macros to expand, including the arguments.  This rule
-may seem strange, but it is carefully designed so you need not worry
-about whether any function call is actually a macro invocation.  You can
-run into trouble if you try to be too clever, though.  @xref{Argument
-Prescan}, for detailed discussion.
-
-For example, @code{min (min (a, b), c)} is first expanded to
-
-@smallexample
-  min (((a) < (b) ? (a) : (b)), (c))
-@end smallexample
-
-@noindent
-and then to
-
-@smallexample
-@group
-((((a) < (b) ? (a) : (b))) < (c)
- ? (((a) < (b) ? (a) : (b)))
- : (c))
-@end group
-@end smallexample
-
-@noindent
-(Line breaks shown here for clarity would not actually be generated.)
-
-@cindex empty macro arguments
-You can leave macro arguments empty; this is not an error to the
-preprocessor (but many macros will then expand to invalid code).
-You cannot leave out arguments entirely; if a macro takes two arguments,
-there must be exactly one comma at the top level of its argument list.
-Here are some silly examples using @code{min}:
-
-@smallexample
-min(, b)        @expansion{} ((   ) < (b) ? (   ) : (b))
-min(a, )        @expansion{} ((a  ) < ( ) ? (a  ) : ( ))
-min(,)          @expansion{} ((   ) < ( ) ? (   ) : ( ))
-min((,),)       @expansion{} (((,)) < ( ) ? ((,)) : ( ))
-
-min()      @error{} macro "min" requires 2 arguments, but only 1 given
-min(,,)    @error{} macro "min" passed 3 arguments, but takes just 2
-@end smallexample
-
-Whitespace is not a preprocessing token, so if a macro @code{foo} takes
-one argument, @code{@w{foo ()}} and @code{@w{foo ( )}} both supply it an
-empty argument.  Previous GNU preprocessor implementations and
-documentation were incorrect on this point, insisting that a
-function-like macro that takes a single argument be passed a space if an
-empty argument was required.
-
-Macro parameters appearing inside string literals are not replaced by
-their corresponding actual arguments.
-
-@smallexample
-#define foo(x) x, "x"
-foo(bar)        @expansion{} bar, "x"
-@end smallexample
-
-@node Stringification
-@section Stringification
-@cindex stringification
-@cindex @samp{#} operator
-
-Sometimes you may want to convert a macro argument into a string
-constant.  Parameters are not replaced inside string constants, but you
-can use the @samp{#} preprocessing operator instead.  When a macro
-parameter is used with a leading @samp{#}, the preprocessor replaces it
-with the literal text of the actual argument, converted to a string
-constant.  Unlike normal parameter replacement, the argument is not
-macro-expanded first.  This is called @dfn{stringification}.
-
-There is no way to combine an argument with surrounding text and
-stringify it all together.  Instead, you can write a series of adjacent
-string constants and stringified arguments.  The preprocessor will
-replace the stringified arguments with string constants.  The C
-compiler will then combine all the adjacent string constants into one
-long string.
-
-Here is an example of a macro definition that uses stringification:
-
-@smallexample
-@group
-#define WARN_IF(EXP) \
-do @{ if (EXP) \
-        fprintf (stderr, "Warning: " #EXP "\n"); @} \
-while (0)
-WARN_IF (x == 0);
-     @expansion{} do @{ if (x == 0)
-           fprintf (stderr, "Warning: " "x == 0" "\n"); @} while (0);
-@end group
-@end smallexample
-
-@noindent
-The argument for @code{EXP} is substituted once, as-is, into the
-@code{if} statement, and once, stringified, into the argument to
-@code{fprintf}.  If @code{x} were a macro, it would be expanded in the
-@code{if} statement, but not in the string.
-
-The @code{do} and @code{while (0)} are a kludge to make it possible to
-write @code{WARN_IF (@var{arg});}, which the resemblance of
-@code{WARN_IF} to a function would make C programmers want to do; see
-@ref{Swallowing the Semicolon}.
-
-Stringification in C involves more than putting double-quote characters
-around the fragment.  The preprocessor backslash-escapes the quotes
-surrounding embedded string constants, and all backslashes within string and
-character constants, in order to get a valid C string constant with the
-proper contents.  Thus, stringifying @code{@w{p = "foo\n";}} results in
-@t{@w{"p = \"foo\\n\";"}}.  However, backslashes that are not inside string
-or character constants are not duplicated: @samp{\n} by itself
-stringifies to @t{"\n"}.
-
-All leading and trailing whitespace in text being stringified is
-ignored.  Any sequence of whitespace in the middle of the text is
-converted to a single space in the stringified result.  Comments are
-replaced by whitespace long before stringification happens, so they
-never appear in stringified text.
-
-There is no way to convert a macro argument into a character constant.
-
-If you want to stringify the result of expansion of a macro argument,
-you have to use two levels of macros.
-
-@smallexample
-#define xstr(s) str(s)
-#define str(s) #s
-#define foo 4
-str (foo)
-     @expansion{} "foo"
-xstr (foo)
-     @expansion{} xstr (4)
-     @expansion{} str (4)
-     @expansion{} "4"
-@end smallexample
-
-@code{s} is stringified when it is used in @code{str}, so it is not
-macro-expanded first.  But @code{s} is an ordinary argument to
-@code{xstr}, so it is completely macro-expanded before @code{xstr}
-itself is expanded (@pxref{Argument Prescan}).  Therefore, by the time
-@code{str} gets to its argument, it has already been macro-expanded.
-
-@node Concatenation
-@section Concatenation
-@cindex concatenation
-@cindex token pasting
-@cindex token concatenation
-@cindex @samp{##} operator
-
-It is often useful to merge two tokens into one while expanding macros.
-This is called @dfn{token pasting} or @dfn{token concatenation}.  The
-@samp{##} preprocessing operator performs token pasting.  When a macro
-is expanded, the two tokens on either side of each @samp{##} operator
-are combined into a single token, which then replaces the @samp{##} and
-the two original tokens in the macro expansion.  Usually both will be
-identifiers, or one will be an identifier and the other a preprocessing
-number.  When pasted, they make a longer identifier.  This isn't the
-only valid case.  It is also possible to concatenate two numbers (or a
-number and a name, such as @code{1.5} and @code{e3}) into a number.
-Also, multi-character operators such as @code{+=} can be formed by
-token pasting.
-
-However, two tokens that don't together form a valid token cannot be
-pasted together.  For example, you cannot concatenate @code{x} with
-@code{+} in either order.  If you try, the preprocessor issues a warning
-and emits the two tokens.  Whether it puts white space between the
-tokens is undefined.  It is common to find unnecessary uses of @samp{##}
-in complex macros.  If you get this warning, it is likely that you can
-simply remove the @samp{##}.
-
-Both the tokens combined by @samp{##} could come from the macro body,
-but you could just as well write them as one token in the first place.
-Token pasting is most useful when one or both of the tokens comes from a
-macro argument.  If either of the tokens next to an @samp{##} is a
-parameter name, it is replaced by its actual argument before @samp{##}
-executes.  As with stringification, the actual argument is not
-macro-expanded first.  If the argument is empty, that @samp{##} has no
-effect.
-
-Keep in mind that the C preprocessor converts comments to whitespace
-before macros are even considered.  Therefore, you cannot create a
-comment by concatenating @samp{/} and @samp{*}.  You can put as much
-whitespace between @samp{##} and its operands as you like, including
-comments, and you can put comments in arguments that will be
-concatenated.  However, it is an error if @samp{##} appears at either
-end of a macro body.
-
-Consider a C program that interprets named commands.  There probably
-needs to be a table of commands, perhaps an array of structures declared
-as follows:
-
-@smallexample
-@group
-struct command
-@{
-  char *name;
-  void (*function) (void);
-@};
-@end group
-
-@group
-struct command commands[] =
-@{
-  @{ "quit", quit_command @},
-  @{ "help", help_command @},
-  @dots{}
-@};
-@end group
-@end smallexample
-
-It would be cleaner not to have to give each command name twice, once in
-the string constant and once in the function name.  A macro which takes the
-name of a command as an argument can make this unnecessary.  The string
-constant can be created with stringification, and the function name by
-concatenating the argument with @samp{_command}.  Here is how it is done:
-
-@smallexample
-#define COMMAND(NAME)  @{ #NAME, NAME ## _command @}
-
-struct command commands[] =
-@{
-  COMMAND (quit),
-  COMMAND (help),
-  @dots{}
-@};
-@end smallexample
-
-@node Variadic Macros
-@section Variadic Macros
-@cindex variable number of arguments
-@cindex macros with variable arguments
-@cindex variadic macros
-
-A macro can be declared to accept a variable number of arguments much as
-a function can.  The syntax for defining the macro is similar to that of
-a function.  Here is an example:
-
-@smallexample
-#define eprintf(@dots{}) fprintf (stderr, __VA_ARGS__)
-@end smallexample
-
-This kind of macro is called @dfn{variadic}.  When the macro is invoked,
-all the tokens in its argument list after the last named argument (this
-macro has none), including any commas, become the @dfn{variable
-argument}.  This sequence of tokens replaces the identifier
-@code{@w{__VA_ARGS__}} in the macro body wherever it appears.  Thus, we
-have this expansion:
-
-@smallexample
-eprintf ("%s:%d: ", input_file, lineno)
-     @expansion{}  fprintf (stderr, "%s:%d: ", input_file, lineno)
-@end smallexample
-
-The variable argument is completely macro-expanded before it is inserted
-into the macro expansion, just like an ordinary argument.  You may use
-the @samp{#} and @samp{##} operators to stringify the variable argument
-or to paste its leading or trailing token with another token.  (But see
-below for an important special case for @samp{##}.)
-
-If your macro is complicated, you may want a more descriptive name for
-the variable argument than @code{@w{__VA_ARGS__}}.  CPP permits
-this, as an extension.  You may write an argument name immediately
-before the @samp{@dots{}}; that name is used for the variable argument.
-The @code{eprintf} macro above could be written
-
-@smallexample
-#define eprintf(args@dots{}) fprintf (stderr, args)
-@end smallexample
-
-@noindent
-using this extension.  You cannot use @code{@w{__VA_ARGS__}} and this
-extension in the same macro.
-
-You can have named arguments as well as variable arguments in a variadic
-macro.  We could define @code{eprintf} like this, instead:
-
-@smallexample
-#define eprintf(format, @dots{}) fprintf (stderr, format, __VA_ARGS__)
-@end smallexample
-
-@noindent
-This formulation looks more descriptive, but unfortunately it is less
-flexible: you must now supply at least one argument after the format
-string.  In standard C, you cannot omit the comma separating the named
-argument from the variable arguments.  Furthermore, if you leave the
-variable argument empty, you will get a syntax error, because
-there will be an extra comma after the format string.
-
-@smallexample
-eprintf("success!\n", );
-     @expansion{} fprintf(stderr, "success!\n", );
-@end smallexample
-
-GNU CPP has a pair of extensions which deal with this problem.  First,
-you are allowed to leave the variable argument out entirely:
-
-@smallexample
-eprintf ("success!\n")
-     @expansion{} fprintf(stderr, "success!\n", );
-@end smallexample
-
-@noindent
-Second, the @samp{##} token paste operator has a special meaning when
-placed between a comma and a variable argument.  If you write
-
-@smallexample
-#define eprintf(format, @dots{}) fprintf (stderr, format, ##__VA_ARGS__)
-@end smallexample
-
-@noindent
-and the variable argument is left out when the @code{eprintf} macro is
-used, then the comma before the @samp{##} will be deleted.  This does
-@emph{not} happen if you pass an empty argument, nor does it happen if
-the token preceding @samp{##} is anything other than a comma.
-
-@smallexample
-eprintf ("success!\n")
-     @expansion{} fprintf(stderr, "success!\n");
-@end smallexample
-
-@noindent
-The above explanation is ambiguous about the case where the only macro
-parameter is a variable arguments parameter, as it is meaningless to
-try to distinguish whether no argument at all is an empty argument or
-a missing argument.  In this case the C99 standard is clear that the
-comma must remain, however the existing GCC extension used to swallow
-the comma.  So CPP retains the comma when conforming to a specific C
-standard, and drops it otherwise.
-
-C99 mandates that the only place the identifier @code{@w{__VA_ARGS__}}
-can appear is in the replacement list of a variadic macro.  It may not
-be used as a macro name, macro argument name, or within a different type
-of macro.  It may also be forbidden in open text; the standard is
-ambiguous.  We recommend you avoid using it except for its defined
-purpose.
-
-Variadic macros are a new feature in C99.  GNU CPP has supported them
-for a long time, but only with a named variable argument
-(@samp{args@dots{}}, not @samp{@dots{}} and @code{@w{__VA_ARGS__}}).  If you are
-concerned with portability to previous versions of GCC, you should use
-only named variable arguments.  On the other hand, if you are concerned
-with portability to other conforming implementations of C99, you should
-use only @code{@w{__VA_ARGS__}}.
-
-Previous versions of CPP implemented the comma-deletion extension
-much more generally.  We have restricted it in this release to minimize
-the differences from C99.  To get the same effect with both this and
-previous versions of GCC, the token preceding the special @samp{##} must
-be a comma, and there must be white space between that comma and
-whatever comes immediately before it:
-
-@smallexample
-#define eprintf(format, args@dots{}) fprintf (stderr, format , ##args)
-@end smallexample
-
-@noindent
-@xref{Differences from previous versions}, for the gory details.
-
-@node Predefined Macros
-@section Predefined Macros
-
-@cindex predefined macros
-Several object-like macros are predefined; you use them without
-supplying their definitions.  They fall into three classes: standard,
-common, and system-specific.
-
-In C++, there is a fourth category, the named operators.  They act like
-predefined macros, but you cannot undefine them.
-
-@menu
-* Standard Predefined Macros::
-* Common Predefined Macros::
-* System-specific Predefined Macros::
-* C++ Named Operators::
-@end menu
-
-@node Standard Predefined Macros
-@subsection Standard Predefined Macros
-@cindex standard predefined macros.
-
-The standard predefined macros are specified by the relevant
-language standards, so they are available with all compilers that
-implement those standards.  Older compilers may not provide all of
-them.  Their names all start with double underscores.
-
-@table @code
-@item __FILE__
-This macro expands to the name of the current input file, in the form of
-a C string constant.  This is the path by which the preprocessor opened
-the file, not the short name specified in @samp{#include} or as the
-input file name argument.  For example,
-@code{"/usr/local/include/myheader.h"} is a possible expansion of this
-macro.
-
-@item __LINE__
-This macro expands to the current input line number, in the form of a
-decimal integer constant.  While we call it a predefined macro, it's
-a pretty strange macro, since its ``definition'' changes with each
-new line of source code.
-@end table
-
-@code{__FILE__} and @code{__LINE__} are useful in generating an error
-message to report an inconsistency detected by the program; the message
-can state the source line at which the inconsistency was detected.  For
-example,
-
-@smallexample
-fprintf (stderr, "Internal error: "
-                 "negative string length "
-                 "%d at %s, line %d.",
-         length, __FILE__, __LINE__);
-@end smallexample
-
-An @samp{#include} directive changes the expansions of @code{__FILE__}
-and @code{__LINE__} to correspond to the included file.  At the end of
-that file, when processing resumes on the input file that contained
-the @samp{#include} directive, the expansions of @code{__FILE__} and
-@code{__LINE__} revert to the values they had before the
-@samp{#include} (but @code{__LINE__} is then incremented by one as
-processing moves to the line after the @samp{#include}).
-
-A @samp{#line} directive changes @code{__LINE__}, and may change
-@code{__FILE__} as well.  @xref{Line Control}.
-
-C99 introduces @code{__func__}, and GCC has provided @code{__FUNCTION__}
-for a long time.  Both of these are strings containing the name of the
-current function (there are slight semantic differences; see the GCC
-manual).  Neither of them is a macro; the preprocessor does not know the
-name of the current function.  They tend to be useful in conjunction
-with @code{__FILE__} and @code{__LINE__}, though.
-
-@table @code
-
-@item __DATE__
-This macro expands to a string constant that describes the date on which
-the preprocessor is being run.  The string constant contains eleven
-characters and looks like @code{@w{"Feb 12 1996"}}.  If the day of the
-month is less than 10, it is padded with a space on the left.
-
-If GCC cannot determine the current date, it will emit a warning message
-(once per compilation) and @code{__DATE__} will expand to
-@code{@w{"??? ?? ????"}}.
-
-@item __TIME__
-This macro expands to a string constant that describes the time at
-which the preprocessor is being run.  The string constant contains
-eight characters and looks like @code{"23:59:01"}.
-
-If GCC cannot determine the current time, it will emit a warning message
-(once per compilation) and @code{__TIME__} will expand to
-@code{"??:??:??"}.
-
-@item __STDC__
-In normal operation, this macro expands to the constant 1, to signify
-that this compiler conforms to ISO Standard C@.  If GNU CPP is used with
-a compiler other than GCC, this is not necessarily true; however, the
-preprocessor always conforms to the standard unless the
-@option{-traditional-cpp} option is used.
-
-This macro is not defined if the @option{-traditional-cpp} option is used.
-
-On some hosts, the system compiler uses a different convention, where
-@code{__STDC__} is normally 0, but is 1 if the user specifies strict
-conformance to the C Standard.  CPP follows the host convention when
-processing system header files, but when processing user files
-@code{__STDC__} is always 1.  This has been reported to cause problems;
-for instance, some versions of Solaris provide X Windows headers that
-expect @code{__STDC__} to be either undefined or 1.  @xref{Invocation}.
-
-@item __STDC_VERSION__
-This macro expands to the C Standard's version number, a long integer
-constant of the form @code{@var{yyyy}@var{mm}L} where @var{yyyy} and
-@var{mm} are the year and month of the Standard version.  This signifies
-which version of the C Standard the compiler conforms to.  Like
-@code{__STDC__}, this is not necessarily accurate for the entire
-implementation, unless GNU CPP is being used with GCC@.
-
-The value @code{199409L} signifies the 1989 C standard as amended in
-1994, which is the current default; the value @code{199901L} signifies
-the 1999 revision of the C standard.  Support for the 1999 revision is
-not yet complete.
-
-This macro is not defined if the @option{-traditional-cpp} option is
-used, nor when compiling C++ or Objective-C@.
-
-@item __STDC_HOSTED__
-This macro is defined, with value 1, if the compiler's target is a
-@dfn{hosted environment}.  A hosted environment has the complete
-facilities of the standard C library available.
-
-@item __cplusplus
-This macro is defined when the C++ compiler is in use.  You can use
-@code{__cplusplus} to test whether a header is compiled by a C compiler
-or a C++ compiler.  This macro is similar to @code{__STDC_VERSION__}, in
-that it expands to a version number.  Depending on the language standard
-selected, the value of the macro is @code{199711L}, as mandated by the
-1998 C++ standard; @code{201103L}, per the 2011 C++ standard; an
-unspecified value strictly larger than @code{201103L} for the experimental 
-languages enabled by @option{-std=c++1y} and @option{-std=gnu++1y}.
-
-@item __OBJC__
-This macro is defined, with value 1, when the Objective-C compiler is in
-use.  You can use @code{__OBJC__} to test whether a header is compiled
-by a C compiler or an Objective-C compiler.
-
-@item __ASSEMBLER__
-This macro is defined with value 1 when preprocessing assembly
-language.
-
-@end table
-
-@node Common Predefined Macros
-@subsection Common Predefined Macros
-@cindex common predefined macros
-
-The common predefined macros are GNU C extensions.  They are available
-with the same meanings regardless of the machine or operating system on
-which you are using GNU C or GNU Fortran.  Their names all start with
-double underscores.
-
-@table @code
-
-@item __COUNTER__
-This macro expands to sequential integral values starting from 0.  In
-conjunction with the @code{##} operator, this provides a convenient means to
-generate unique identifiers.  Care must be taken to ensure that
-@code{__COUNTER__} is not expanded prior to inclusion of precompiled headers
-which use it.  Otherwise, the precompiled headers will not be used.
-
-@item __GFORTRAN__
-The GNU Fortran compiler defines this.
-
-@item __GNUC__
-@itemx __GNUC_MINOR__
-@itemx __GNUC_PATCHLEVEL__
-These macros are defined by all GNU compilers that use the C
-preprocessor: C, C++, Objective-C and Fortran.  Their values are the major
-version, minor version, and patch level of the compiler, as integer
-constants.  For example, GCC 3.2.1 will define @code{__GNUC__} to 3,
-@code{__GNUC_MINOR__} to 2, and @code{__GNUC_PATCHLEVEL__} to 1.  These
-macros are also defined if you invoke the preprocessor directly.
-
-@code{__GNUC_PATCHLEVEL__} is new to GCC 3.0; it is also present in the
-widely-used development snapshots leading up to 3.0 (which identify
-themselves as GCC 2.96 or 2.97, depending on which snapshot you have).
-
-If all you need to know is whether or not your program is being compiled
-by GCC, or a non-GCC compiler that claims to accept the GNU C dialects,
-you can simply test @code{__GNUC__}.  If you need to write code
-which depends on a specific version, you must be more careful.  Each
-time the minor version is increased, the patch level is reset to zero;
-each time the major version is increased (which happens rarely), the
-minor version and patch level are reset.  If you wish to use the
-predefined macros directly in the conditional, you will need to write it
-like this:
-
-@smallexample
-/* @r{Test for GCC > 3.2.0} */
-#if __GNUC__ > 3 || \
-    (__GNUC__ == 3 && (__GNUC_MINOR__ > 2 || \
-                       (__GNUC_MINOR__ == 2 && \
-                        __GNUC_PATCHLEVEL__ > 0))
-@end smallexample
-
-@noindent
-Another approach is to use the predefined macros to
-calculate a single number, then compare that against a threshold:
-
-@smallexample
-#define GCC_VERSION (__GNUC__ * 10000 \
-                     + __GNUC_MINOR__ * 100 \
-                     + __GNUC_PATCHLEVEL__)
-@dots{}
-/* @r{Test for GCC > 3.2.0} */
-#if GCC_VERSION > 30200
-@end smallexample
-
-@noindent
-Many people find this form easier to understand.
-
-@item __GNUG__
-The GNU C++ compiler defines this.  Testing it is equivalent to
-testing @code{@w{(__GNUC__ && __cplusplus)}}.
-
-@item __STRICT_ANSI__
-GCC defines this macro if and only if the @option{-ansi} switch, or a
-@option{-std} switch specifying strict conformance to some version of ISO C
-or ISO C++, was specified when GCC was invoked.  It is defined to @samp{1}.
-This macro exists primarily to direct GNU libc's header files to
-restrict their definitions to the minimal set found in the 1989 C
-standard.
-
-@item __BASE_FILE__
-This macro expands to the name of the main input file, in the form
-of a C string constant.  This is the source file that was specified
-on the command line of the preprocessor or C compiler.
-
-@item __INCLUDE_LEVEL__
-This macro expands to a decimal integer constant that represents the
-depth of nesting in include files.  The value of this macro is
-incremented on every @samp{#include} directive and decremented at the
-end of every included file.  It starts out at 0, its value within the
-base file specified on the command line.
-
-@item __ELF__
-This macro is defined if the target uses the ELF object format.
-
-@item __VERSION__
-This macro expands to a string constant which describes the version of
-the compiler in use.  You should not rely on its contents having any
-particular form, but it can be counted on to contain at least the
-release number.
-
-@item __OPTIMIZE__
-@itemx __OPTIMIZE_SIZE__
-@itemx __NO_INLINE__
-These macros describe the compilation mode.  @code{__OPTIMIZE__} is
-defined in all optimizing compilations.  @code{__OPTIMIZE_SIZE__} is
-defined if the compiler is optimizing for size, not speed.
-@code{__NO_INLINE__} is defined if no functions will be inlined into
-their callers (when not optimizing, or when inlining has been
-specifically disabled by @option{-fno-inline}).
-
-These macros cause certain GNU header files to provide optimized
-definitions, using macros or inline functions, of system library
-functions.  You should not use these macros in any way unless you make
-sure that programs will execute with the same effect whether or not they
-are defined.  If they are defined, their value is 1.
-
-@item __GNUC_GNU_INLINE__
-GCC defines this macro if functions declared @code{inline} will be
-handled in GCC's traditional gnu90 mode.  Object files will contain
-externally visible definitions of all functions declared @code{inline}
-without @code{extern} or @code{static}.  They will not contain any
-definitions of any functions declared @code{extern inline}.
-
-@item __GNUC_STDC_INLINE__
-GCC defines this macro if functions declared @code{inline} will be
-handled according to the ISO C99 standard.  Object files will contain
-externally visible definitions of all functions declared @code{extern
-inline}.  They will not contain definitions of any functions declared
-@code{inline} without @code{extern}.
-
-If this macro is defined, GCC supports the @code{gnu_inline} function
-attribute as a way to always get the gnu90 behavior.  Support for
-this and @code{__GNUC_GNU_INLINE__} was added in GCC 4.1.3.  If
-neither macro is defined, an older version of GCC is being used:
-@code{inline} functions will be compiled in gnu90 mode, and the
-@code{gnu_inline} function attribute will not be recognized.
-
-@item __CHAR_UNSIGNED__
-GCC defines this macro if and only if the data type @code{char} is
-unsigned on the target machine.  It exists to cause the standard header
-file @file{limits.h} to work correctly.  You should not use this macro
-yourself; instead, refer to the standard macros defined in @file{limits.h}.
-
-@item __WCHAR_UNSIGNED__
-Like @code{__CHAR_UNSIGNED__}, this macro is defined if and only if the
-data type @code{wchar_t} is unsigned and the front-end is in C++ mode.
-
-@item __REGISTER_PREFIX__
-This macro expands to a single token (not a string constant) which is
-the prefix applied to CPU register names in assembly language for this
-target.  You can use it to write assembly that is usable in multiple
-environments.  For example, in the @code{m68k-aout} environment it
-expands to nothing, but in the @code{m68k-coff} environment it expands
-to a single @samp{%}.
-
-@item __USER_LABEL_PREFIX__
-This macro expands to a single token which is the prefix applied to
-user labels (symbols visible to C code) in assembly.  For example, in
-the @code{m68k-aout} environment it expands to an @samp{_}, but in the
-@code{m68k-coff} environment it expands to nothing.
-
-This macro will have the correct definition even if
-@option{-f(no-)underscores} is in use, but it will not be correct if
-target-specific options that adjust this prefix are used (e.g.@: the
-OSF/rose @option{-mno-underscores} option).
-
-@item __SIZE_TYPE__
-@itemx __PTRDIFF_TYPE__
-@itemx __WCHAR_TYPE__
-@itemx __WINT_TYPE__
-@itemx __INTMAX_TYPE__
-@itemx __UINTMAX_TYPE__
-@itemx __SIG_ATOMIC_TYPE__
-@itemx __INT8_TYPE__
-@itemx __INT16_TYPE__
-@itemx __INT32_TYPE__
-@itemx __INT64_TYPE__
-@itemx __UINT8_TYPE__
-@itemx __UINT16_TYPE__
-@itemx __UINT32_TYPE__
-@itemx __UINT64_TYPE__
-@itemx __INT_LEAST8_TYPE__
-@itemx __INT_LEAST16_TYPE__
-@itemx __INT_LEAST32_TYPE__
-@itemx __INT_LEAST64_TYPE__
-@itemx __UINT_LEAST8_TYPE__
-@itemx __UINT_LEAST16_TYPE__
-@itemx __UINT_LEAST32_TYPE__
-@itemx __UINT_LEAST64_TYPE__
-@itemx __INT_FAST8_TYPE__
-@itemx __INT_FAST16_TYPE__
-@itemx __INT_FAST32_TYPE__
-@itemx __INT_FAST64_TYPE__
-@itemx __UINT_FAST8_TYPE__
-@itemx __UINT_FAST16_TYPE__
-@itemx __UINT_FAST32_TYPE__
-@itemx __UINT_FAST64_TYPE__
-@itemx __INTPTR_TYPE__
-@itemx __UINTPTR_TYPE__
-These macros are defined to the correct underlying types for the
-@code{size_t}, @code{ptrdiff_t}, @code{wchar_t}, @code{wint_t},
-@code{intmax_t}, @code{uintmax_t}, @code{sig_atomic_t}, @code{int8_t},
-@code{int16_t}, @code{int32_t}, @code{int64_t}, @code{uint8_t},
-@code{uint16_t}, @code{uint32_t}, @code{uint64_t},
-@code{int_least8_t}, @code{int_least16_t}, @code{int_least32_t},
-@code{int_least64_t}, @code{uint_least8_t}, @code{uint_least16_t},
-@code{uint_least32_t}, @code{uint_least64_t}, @code{int_fast8_t},
-@code{int_fast16_t}, @code{int_fast32_t}, @code{int_fast64_t},
-@code{uint_fast8_t}, @code{uint_fast16_t}, @code{uint_fast32_t},
-@code{uint_fast64_t}, @code{intptr_t}, and @code{uintptr_t} typedefs,
-respectively.  They exist to make the standard header files
-@file{stddef.h}, @file{stdint.h}, and @file{wchar.h} work correctly.
-You should not use these macros directly; instead, include the
-appropriate headers and use the typedefs.  Some of these macros may
-not be defined on particular systems if GCC does not provide a
-@file{stdint.h} header on those systems.
-
-@item __CHAR_BIT__
-Defined to the number of bits used in the representation of the
-@code{char} data type.  It exists to make the standard header given
-numerical limits work correctly.  You should not use
-this macro directly; instead, include the appropriate headers.
-
-@item __SCHAR_MAX__
-@itemx __WCHAR_MAX__
-@itemx __SHRT_MAX__
-@itemx __INT_MAX__
-@itemx __LONG_MAX__
-@itemx __LONG_LONG_MAX__
-@itemx __WINT_MAX__
-@itemx __SIZE_MAX__
-@itemx __PTRDIFF_MAX__
-@itemx __INTMAX_MAX__
-@itemx __UINTMAX_MAX__
-@itemx __SIG_ATOMIC_MAX__
-@itemx __INT8_MAX__
-@itemx __INT16_MAX__
-@itemx __INT32_MAX__
-@itemx __INT64_MAX__
-@itemx __UINT8_MAX__
-@itemx __UINT16_MAX__
-@itemx __UINT32_MAX__
-@itemx __UINT64_MAX__
-@itemx __INT_LEAST8_MAX__
-@itemx __INT_LEAST16_MAX__
-@itemx __INT_LEAST32_MAX__
-@itemx __INT_LEAST64_MAX__
-@itemx __UINT_LEAST8_MAX__
-@itemx __UINT_LEAST16_MAX__
-@itemx __UINT_LEAST32_MAX__
-@itemx __UINT_LEAST64_MAX__
-@itemx __INT_FAST8_MAX__
-@itemx __INT_FAST16_MAX__
-@itemx __INT_FAST32_MAX__
-@itemx __INT_FAST64_MAX__
-@itemx __UINT_FAST8_MAX__
-@itemx __UINT_FAST16_MAX__
-@itemx __UINT_FAST32_MAX__
-@itemx __UINT_FAST64_MAX__
-@itemx __INTPTR_MAX__
-@itemx __UINTPTR_MAX__
-@itemx __WCHAR_MIN__
-@itemx __WINT_MIN__
-@itemx __SIG_ATOMIC_MIN__
-Defined to the maximum value of the @code{signed char}, @code{wchar_t},
-@code{signed short},
-@code{signed int}, @code{signed long}, @code{signed long long},
-@code{wint_t}, @code{size_t}, @code{ptrdiff_t},
-@code{intmax_t}, @code{uintmax_t}, @code{sig_atomic_t}, @code{int8_t},
-@code{int16_t}, @code{int32_t}, @code{int64_t}, @code{uint8_t},
-@code{uint16_t}, @code{uint32_t}, @code{uint64_t},
-@code{int_least8_t}, @code{int_least16_t}, @code{int_least32_t},
-@code{int_least64_t}, @code{uint_least8_t}, @code{uint_least16_t},
-@code{uint_least32_t}, @code{uint_least64_t}, @code{int_fast8_t},
-@code{int_fast16_t}, @code{int_fast32_t}, @code{int_fast64_t},
-@code{uint_fast8_t}, @code{uint_fast16_t}, @code{uint_fast32_t},
-@code{uint_fast64_t}, @code{intptr_t}, and @code{uintptr_t} types and
-to the minimum value of the @code{wchar_t}, @code{wint_t}, and
-@code{sig_atomic_t} types respectively.  They exist to make the
-standard header given numerical limits work correctly.  You should not
-use these macros directly; instead, include the appropriate headers.
-Some of these macros may not be defined on particular systems if GCC
-does not provide a @file{stdint.h} header on those systems.
-
-@item __INT8_C
-@itemx __INT16_C
-@itemx __INT32_C
-@itemx __INT64_C
-@itemx __UINT8_C
-@itemx __UINT16_C
-@itemx __UINT32_C
-@itemx __UINT64_C
-@itemx __INTMAX_C
-@itemx __UINTMAX_C
-Defined to implementations of the standard @file{stdint.h} macros with
-the same names without the leading @code{__}.  They exist the make the
-implementation of that header work correctly.  You should not use
-these macros directly; instead, include the appropriate headers.  Some
-of these macros may not be defined on particular systems if GCC does
-not provide a @file{stdint.h} header on those systems.
-
-@item __SIZEOF_INT__
-@itemx __SIZEOF_LONG__
-@itemx __SIZEOF_LONG_LONG__
-@itemx __SIZEOF_SHORT__
-@itemx __SIZEOF_POINTER__
-@itemx __SIZEOF_FLOAT__
-@itemx __SIZEOF_DOUBLE__
-@itemx __SIZEOF_LONG_DOUBLE__
-@itemx __SIZEOF_SIZE_T__
-@itemx __SIZEOF_WCHAR_T__
-@itemx __SIZEOF_WINT_T__
-@itemx __SIZEOF_PTRDIFF_T__
-Defined to the number of bytes of the C standard data types: @code{int},
-@code{long}, @code{long long}, @code{short}, @code{void *}, @code{float},
-@code{double}, @code{long double}, @code{size_t}, @code{wchar_t}, @code{wint_t}
-and @code{ptrdiff_t}.
-
-@item __BYTE_ORDER__
-@itemx __ORDER_LITTLE_ENDIAN__
-@itemx __ORDER_BIG_ENDIAN__
-@itemx __ORDER_PDP_ENDIAN__
-@code{__BYTE_ORDER__} is defined to one of the values
-@code{__ORDER_LITTLE_ENDIAN__}, @code{__ORDER_BIG_ENDIAN__}, or
-@code{__ORDER_PDP_ENDIAN__} to reflect the layout of multi-byte and
-multi-word quantities in memory.  If @code{__BYTE_ORDER__} is equal to
-@code{__ORDER_LITTLE_ENDIAN__} or @code{__ORDER_BIG_ENDIAN__}, then
-multi-byte and multi-word quantities are laid out identically: the
-byte (word) at the lowest address is the least significant or most
-significant byte (word) of the quantity, respectively.  If
-@code{__BYTE_ORDER__} is equal to @code{__ORDER_PDP_ENDIAN__}, then
-bytes in 16-bit words are laid out in a little-endian fashion, whereas
-the 16-bit subwords of a 32-bit quantity are laid out in big-endian
-fashion.
-
-You should use these macros for testing like this:
-
-@smallexample
-/* @r{Test for a little-endian machine} */
-#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
-@end smallexample
-
-@item __FLOAT_WORD_ORDER__
-@code{__FLOAT_WORD_ORDER__} is defined to one of the values
-@code{__ORDER_LITTLE_ENDIAN__} or @code{__ORDER_BIG_ENDIAN__} to reflect
-the layout of the words of multi-word floating-point quantities.
-
-@item __DEPRECATED
-This macro is defined, with value 1, when compiling a C++ source file
-with warnings about deprecated constructs enabled.  These warnings are
-enabled by default, but can be disabled with @option{-Wno-deprecated}.
-
-@item __EXCEPTIONS
-This macro is defined, with value 1, when compiling a C++ source file
-with exceptions enabled.  If @option{-fno-exceptions} is used when
-compiling the file, then this macro is not defined.
-
-@item __GXX_RTTI
-This macro is defined, with value 1, when compiling a C++ source file
-with runtime type identification enabled.  If @option{-fno-rtti} is
-used when compiling the file, then this macro is not defined.
-
-@item __USING_SJLJ_EXCEPTIONS__
-This macro is defined, with value 1, if the compiler uses the old
-mechanism based on @code{setjmp} and @code{longjmp} for exception
-handling.
-
-@item __GXX_EXPERIMENTAL_CXX0X__
-This macro is defined when compiling a C++ source file with the option
-@option{-std=c++0x} or @option{-std=gnu++0x}. It indicates that some
-features likely to be included in C++0x are available. Note that these
-features are experimental, and may change or be removed in future
-versions of GCC.
-
-@item __GXX_WEAK__
-This macro is defined when compiling a C++ source file.  It has the
-value 1 if the compiler will use weak symbols, COMDAT sections, or
-other similar techniques to collapse symbols with ``vague linkage''
-that are defined in multiple translation units.  If the compiler will
-not collapse such symbols, this macro is defined with value 0.  In
-general, user code should not need to make use of this macro; the
-purpose of this macro is to ease implementation of the C++ runtime
-library provided with G++.
-
-@item __NEXT_RUNTIME__
-This macro is defined, with value 1, if (and only if) the NeXT runtime
-(as in @option{-fnext-runtime}) is in use for Objective-C@.  If the GNU
-runtime is used, this macro is not defined, so that you can use this
-macro to determine which runtime (NeXT or GNU) is being used.
-
-@item __LP64__
-@itemx _LP64
-These macros are defined, with value 1, if (and only if) the compilation
-is for a target where @code{long int} and pointer both use 64-bits and
-@code{int} uses 32-bit.
-
-@item __SSP__
-This macro is defined, with value 1, when @option{-fstack-protector} is in
-use.
-
-@item __SSP_ALL__
-This macro is defined, with value 2, when @option{-fstack-protector-all} is
-in use.
-
-@item __SSP_STRONG__
-This macro is defined, with value 3, when @option{-fstack-protector-strong} is
-in use.
-
-@item __SSP_EXPLICIT__
-This macro is defined, with value 4, when @option{-fstack-protector-explicit} is
-in use.
-
-@item __SANITIZE_ADDRESS__
-This macro is defined, with value 1, when @option{-fsanitize=address}
-or @option{-fsanitize=kernel-address} are in use.
-
-@item __TIMESTAMP__
-This macro expands to a string constant that describes the date and time
-of the last modification of the current source file. The string constant
-contains abbreviated day of the week, month, day of the month, time in
-hh:mm:ss form, year and looks like @code{@w{"Sun Sep 16 01:03:52 1973"}}.
-If the day of the month is less than 10, it is padded with a space on the left.
-
-If GCC cannot determine the current date, it will emit a warning message
-(once per compilation) and @code{__TIMESTAMP__} will expand to
-@code{@w{"??? ??? ?? ??:??:?? ????"}}.
-
-@item __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1
-@itemx __GCC_HAVE_SYNC_COMPARE_AND_SWAP_2
-@itemx __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4
-@itemx __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8
-@itemx __GCC_HAVE_SYNC_COMPARE_AND_SWAP_16
-These macros are defined when the target processor supports atomic compare
-and swap operations on operands 1, 2, 4, 8 or 16 bytes in length, respectively.
-
-@item __GCC_HAVE_DWARF2_CFI_ASM
-This macro is defined when the compiler is emitting Dwarf2 CFI directives
-to the assembler.  When this is defined, it is possible to emit those same
-directives in inline assembly.
-
-@item __FP_FAST_FMA
-@itemx __FP_FAST_FMAF
-@itemx __FP_FAST_FMAL
-These macros are defined with value 1 if the backend supports the
-@code{fma}, @code{fmaf}, and @code{fmal} builtin functions, so that
-the include file @file{math.h} can define the macros
-@code{FP_FAST_FMA}, @code{FP_FAST_FMAF}, and @code{FP_FAST_FMAL}
-for compatibility with the 1999 C standard.
-
-@item __GCC_IEC_559
-This macro is defined to indicate the intended level of support for
-IEEE 754 (IEC 60559) floating-point arithmetic.  It expands to a
-nonnegative integer value.  If 0, it indicates that the combination of
-the compiler configuration and the command-line options is not
-intended to support IEEE 754 arithmetic for @code{float} and
-@code{double} as defined in C99 and C11 Annex F (for example, that the
-standard rounding modes and exceptions are not supported, or that
-optimizations are enabled that conflict with IEEE 754 semantics).  If
-1, it indicates that IEEE 754 arithmetic is intended to be supported;
-this does not mean that all relevant language features are supported
-by GCC.  If 2 or more, it additionally indicates support for IEEE
-754-2008 (in particular, that the binary encodings for quiet and
-signaling NaNs are as specified in IEEE 754-2008).
-
-This macro does not indicate the default state of command-line options
-that control optimizations that C99 and C11 permit to be controlled by
-standard pragmas, where those standards do not require a particular
-default state.  It does not indicate whether optimizations respect
-signaling NaN semantics (the macro for that is
-@code{__SUPPORT_SNAN__}).  It does not indicate support for decimal
-floating point or the IEEE 754 binary16 and binary128 types.
-
-@item __GCC_IEC_559_COMPLEX
-This macro is defined to indicate the intended level of support for
-IEEE 754 (IEC 60559) floating-point arithmetic for complex numbers, as
-defined in C99 and C11 Annex G.  It expands to a nonnegative integer
-value.  If 0, it indicates that the combination of the compiler
-configuration and the command-line options is not intended to support
-Annex G requirements (for example, because @option{-fcx-limited-range}
-was used).  If 1 or more, it indicates that it is intended to support
-those requirements; this does not mean that all relevant language
-features are supported by GCC.
-
-@item __NO_MATH_ERRNO__
-This macro is defined if @option{-fno-math-errno} is used, or enabled
-by another option such as @option{-ffast-math} or by default.
-@end table
-
-@node System-specific Predefined Macros
-@subsection System-specific Predefined Macros
-
-@cindex system-specific predefined macros
-@cindex predefined macros, system-specific
-@cindex reserved namespace
-
-The C preprocessor normally predefines several macros that indicate what
-type of system and machine is in use.  They are obviously different on
-each target supported by GCC@.  This manual, being for all systems and
-machines, cannot tell you what their names are, but you can use
-@command{cpp -dM} to see them all.  @xref{Invocation}.  All system-specific
-predefined macros expand to a constant value, so you can test them with
-either @samp{#ifdef} or @samp{#if}.
-
-The C standard requires that all system-specific macros be part of the
-@dfn{reserved namespace}.  All names which begin with two underscores,
-or an underscore and a capital letter, are reserved for the compiler and
-library to use as they wish.  However, historically system-specific
-macros have had names with no special prefix; for instance, it is common
-to find @code{unix} defined on Unix systems.  For all such macros, GCC
-provides a parallel macro with two underscores added at the beginning
-and the end.  If @code{unix} is defined, @code{__unix__} will be defined
-too.  There will never be more than two underscores; the parallel of
-@code{_mips} is @code{__mips__}.
-
-When the @option{-ansi} option, or any @option{-std} option that
-requests strict conformance, is given to the compiler, all the
-system-specific predefined macros outside the reserved namespace are
-suppressed.  The parallel macros, inside the reserved namespace, remain
-defined.
-
-We are slowly phasing out all predefined macros which are outside the
-reserved namespace.  You should never use them in new programs, and we
-encourage you to correct older code to use the parallel macros whenever
-you find it.  We don't recommend you use the system-specific macros that
-are in the reserved namespace, either.  It is better in the long run to
-check specifically for features you need, using a tool such as
-@command{autoconf}.
-
-@node C++ Named Operators
-@subsection C++ Named Operators
-@cindex named operators
-@cindex C++ named operators
-@cindex @file{iso646.h}
-
-In C++, there are eleven keywords which are simply alternate spellings
-of operators normally written with punctuation.  These keywords are
-treated as such even in the preprocessor.  They function as operators in
-@samp{#if}, and they cannot be defined as macros or poisoned.  In C, you
-can request that those keywords take their C++ meaning by including
-@file{iso646.h}.  That header defines each one as a normal object-like
-macro expanding to the appropriate punctuator.
-
-These are the named operators and their corresponding punctuators:
-
-@multitable {Named Operator} {Punctuator}
-@item Named Operator @tab Punctuator
-@item @code{and}    @tab @code{&&}
-@item @code{and_eq} @tab @code{&=}
-@item @code{bitand} @tab @code{&}
-@item @code{bitor}  @tab @code{|}
-@item @code{compl}  @tab @code{~}
-@item @code{not}    @tab @code{!}
-@item @code{not_eq} @tab @code{!=}
-@item @code{or}     @tab @code{||}
-@item @code{or_eq}  @tab @code{|=}
-@item @code{xor}    @tab @code{^}
-@item @code{xor_eq} @tab @code{^=}
-@end multitable
-
-@node Undefining and Redefining Macros
-@section Undefining and Redefining Macros
-@cindex undefining macros
-@cindex redefining macros
-@findex #undef
-
-If a macro ceases to be useful, it may be @dfn{undefined} with the
-@samp{#undef} directive.  @samp{#undef} takes a single argument, the
-name of the macro to undefine.  You use the bare macro name, even if the
-macro is function-like.  It is an error if anything appears on the line
-after the macro name.  @samp{#undef} has no effect if the name is not a
-macro.
-
-@smallexample
-#define FOO 4
-x = FOO;        @expansion{} x = 4;
-#undef FOO
-x = FOO;        @expansion{} x = FOO;
-@end smallexample
-
-Once a macro has been undefined, that identifier may be @dfn{redefined}
-as a macro by a subsequent @samp{#define} directive.  The new definition
-need not have any resemblance to the old definition.
-
-However, if an identifier which is currently a macro is redefined, then
-the new definition must be @dfn{effectively the same} as the old one.
-Two macro definitions are effectively the same if:
-@itemize @bullet
-@item Both are the same type of macro (object- or function-like).
-@item All the tokens of the replacement list are the same.
-@item If there are any parameters, they are the same.
-@item Whitespace appears in the same places in both.  It need not be
-exactly the same amount of whitespace, though.  Remember that comments
-count as whitespace.
-@end itemize
-
-@noindent
-These definitions are effectively the same:
-@smallexample
-#define FOUR (2 + 2)
-#define FOUR         (2    +    2)
-#define FOUR (2 /* @r{two} */ + 2)
-@end smallexample
-@noindent
-but these are not:
-@smallexample
-#define FOUR (2 + 2)
-#define FOUR ( 2+2 )
-#define FOUR (2 * 2)
-#define FOUR(score,and,seven,years,ago) (2 + 2)
-@end smallexample
-
-If a macro is redefined with a definition that is not effectively the
-same as the old one, the preprocessor issues a warning and changes the
-macro to use the new definition.  If the new definition is effectively
-the same, the redefinition is silently ignored.  This allows, for
-instance, two different headers to define a common macro.  The
-preprocessor will only complain if the definitions do not match.
-
-@node Directives Within Macro Arguments
-@section Directives Within Macro Arguments
-@cindex macro arguments and directives
-
-Occasionally it is convenient to use preprocessor directives within
-the arguments of a macro.  The C and C++ standards declare that
-behavior in these cases is undefined.
-
-Versions of CPP prior to 3.2 would reject such constructs with an
-error message.  This was the only syntactic difference between normal
-functions and function-like macros, so it seemed attractive to remove
-this limitation, and people would often be surprised that they could
-not use macros in this way.  Moreover, sometimes people would use
-conditional compilation in the argument list to a normal library
-function like @samp{printf}, only to find that after a library upgrade
-@samp{printf} had changed to be a function-like macro, and their code
-would no longer compile.  So from version 3.2 we changed CPP to
-successfully process arbitrary directives within macro arguments in
-exactly the same way as it would have processed the directive were the
-function-like macro invocation not present.
-
-If, within a macro invocation, that macro is redefined, then the new
-definition takes effect in time for argument pre-expansion, but the
-original definition is still used for argument replacement.  Here is a
-pathological example:
-
-@smallexample
-#define f(x) x x
-f (1
-#undef f
-#define f 2
-f)
-@end smallexample
-
-@noindent
-which expands to
-
-@smallexample
-1 2 1 2
-@end smallexample
-
-@noindent
-with the semantics described above.
-
-@node Macro Pitfalls
-@section Macro Pitfalls
-@cindex problems with macros
-@cindex pitfalls of macros
-
-In this section we describe some special rules that apply to macros and
-macro expansion, and point out certain cases in which the rules have
-counter-intuitive consequences that you must watch out for.
-
-@menu
-* Misnesting::
-* Operator Precedence Problems::
-* Swallowing the Semicolon::
-* Duplication of Side Effects::
-* Self-Referential Macros::
-* Argument Prescan::
-* Newlines in Arguments::
-@end menu
-
-@node Misnesting
-@subsection Misnesting
-
-When a macro is called with arguments, the arguments are substituted
-into the macro body and the result is checked, together with the rest of
-the input file, for more macro calls.  It is possible to piece together
-a macro call coming partially from the macro body and partially from the
-arguments.  For example,
-
-@smallexample
-#define twice(x) (2*(x))
-#define call_with_1(x) x(1)
-call_with_1 (twice)
-     @expansion{} twice(1)
-     @expansion{} (2*(1))
-@end smallexample
-
-Macro definitions do not have to have balanced parentheses.  By writing
-an unbalanced open parenthesis in a macro body, it is possible to create
-a macro call that begins inside the macro body but ends outside of it.
-For example,
-
-@smallexample
-#define strange(file) fprintf (file, "%s %d",
-@dots{}
-strange(stderr) p, 35)
-     @expansion{} fprintf (stderr, "%s %d", p, 35)
-@end smallexample
-
-The ability to piece together a macro call can be useful, but the use of
-unbalanced open parentheses in a macro body is just confusing, and
-should be avoided.
-
-@node Operator Precedence Problems
-@subsection Operator Precedence Problems
-@cindex parentheses in macro bodies
-
-You may have noticed that in most of the macro definition examples shown
-above, each occurrence of a macro argument name had parentheses around
-it.  In addition, another pair of parentheses usually surround the
-entire macro definition.  Here is why it is best to write macros that
-way.
-
-Suppose you define a macro as follows,
-
-@smallexample
-#define ceil_div(x, y) (x + y - 1) / y
-@end smallexample
-
-@noindent
-whose purpose is to divide, rounding up.  (One use for this operation is
-to compute how many @code{int} objects are needed to hold a certain
-number of @code{char} objects.)  Then suppose it is used as follows:
-
-@smallexample
-a = ceil_div (b & c, sizeof (int));
-     @expansion{} a = (b & c + sizeof (int) - 1) / sizeof (int);
-@end smallexample
-
-@noindent
-This does not do what is intended.  The operator-precedence rules of
-C make it equivalent to this:
-
-@smallexample
-a = (b & (c + sizeof (int) - 1)) / sizeof (int);
-@end smallexample
-
-@noindent
-What we want is this:
-
-@smallexample
-a = ((b & c) + sizeof (int) - 1)) / sizeof (int);
-@end smallexample
-
-@noindent
-Defining the macro as
-
-@smallexample
-#define ceil_div(x, y) ((x) + (y) - 1) / (y)
-@end smallexample
-
-@noindent
-provides the desired result.
-
-Unintended grouping can result in another way.  Consider @code{sizeof
-ceil_div(1, 2)}.  That has the appearance of a C expression that would
-compute the size of the type of @code{ceil_div (1, 2)}, but in fact it
-means something very different.  Here is what it expands to:
-
-@smallexample
-sizeof ((1) + (2) - 1) / (2)
-@end smallexample
-
-@noindent
-This would take the size of an integer and divide it by two.  The
-precedence rules have put the division outside the @code{sizeof} when it
-was intended to be inside.
-
-Parentheses around the entire macro definition prevent such problems.
-Here, then, is the recommended way to define @code{ceil_div}:
-
-@smallexample
-#define ceil_div(x, y) (((x) + (y) - 1) / (y))
-@end smallexample
-
-@node Swallowing the Semicolon
-@subsection Swallowing the Semicolon
-@cindex semicolons (after macro calls)
-
-Often it is desirable to define a macro that expands into a compound
-statement.  Consider, for example, the following macro, that advances a
-pointer (the argument @code{p} says where to find it) across whitespace
-characters:
-
-@smallexample
-#define SKIP_SPACES(p, limit)  \
-@{ char *lim = (limit);         \
-  while (p < lim) @{            \
-    if (*p++ != ' ') @{         \
-      p--; break; @}@}@}
-@end smallexample
-
-@noindent
-Here backslash-newline is used to split the macro definition, which must
-be a single logical line, so that it resembles the way such code would
-be laid out if not part of a macro definition.
-
-A call to this macro might be @code{SKIP_SPACES (p, lim)}.  Strictly
-speaking, the call expands to a compound statement, which is a complete
-statement with no need for a semicolon to end it.  However, since it
-looks like a function call, it minimizes confusion if you can use it
-like a function call, writing a semicolon afterward, as in
-@code{SKIP_SPACES (p, lim);}
-
-This can cause trouble before @code{else} statements, because the
-semicolon is actually a null statement.  Suppose you write
-
-@smallexample
-if (*p != 0)
-  SKIP_SPACES (p, lim);
-else @dots{}
-@end smallexample
-
-@noindent
-The presence of two statements---the compound statement and a null
-statement---in between the @code{if} condition and the @code{else}
-makes invalid C code.
-
-The definition of the macro @code{SKIP_SPACES} can be altered to solve
-this problem, using a @code{do @dots{} while} statement.  Here is how:
-
-@smallexample
-#define SKIP_SPACES(p, limit)     \
-do @{ char *lim = (limit);         \
-     while (p < lim) @{            \
-       if (*p++ != ' ') @{         \
-         p--; break; @}@}@}          \
-while (0)
-@end smallexample
-
-Now @code{SKIP_SPACES (p, lim);} expands into
-
-@smallexample
-do @{@dots{}@} while (0);
-@end smallexample
-
-@noindent
-which is one statement.  The loop executes exactly once; most compilers
-generate no extra code for it.
-
-@node Duplication of Side Effects
-@subsection Duplication of Side Effects
-
-@cindex side effects (in macro arguments)
-@cindex unsafe macros
-Many C programs define a macro @code{min}, for ``minimum'', like this:
-
-@smallexample
-#define min(X, Y)  ((X) < (Y) ? (X) : (Y))
-@end smallexample
-
-When you use this macro with an argument containing a side effect,
-as shown here,
-
-@smallexample
-next = min (x + y, foo (z));
-@end smallexample
-
-@noindent
-it expands as follows:
-
-@smallexample
-next = ((x + y) < (foo (z)) ? (x + y) : (foo (z)));
-@end smallexample
-
-@noindent
-where @code{x + y} has been substituted for @code{X} and @code{foo (z)}
-for @code{Y}.
-
-The function @code{foo} is used only once in the statement as it appears
-in the program, but the expression @code{foo (z)} has been substituted
-twice into the macro expansion.  As a result, @code{foo} might be called
-two times when the statement is executed.  If it has side effects or if
-it takes a long time to compute, the results might not be what you
-intended.  We say that @code{min} is an @dfn{unsafe} macro.
-
-The best solution to this problem is to define @code{min} in a way that
-computes the value of @code{foo (z)} only once.  The C language offers
-no standard way to do this, but it can be done with GNU extensions as
-follows:
-
-@smallexample
-#define min(X, Y)                \
-(@{ typeof (X) x_ = (X);          \
-   typeof (Y) y_ = (Y);          \
-   (x_ < y_) ? x_ : y_; @})
-@end smallexample
-
-The @samp{(@{ @dots{} @})} notation produces a compound statement that
-acts as an expression.  Its value is the value of its last statement.
-This permits us to define local variables and assign each argument to
-one.  The local variables have underscores after their names to reduce
-the risk of conflict with an identifier of wider scope (it is impossible
-to avoid this entirely).  Now each argument is evaluated exactly once.
-
-If you do not wish to use GNU C extensions, the only solution is to be
-careful when @emph{using} the macro @code{min}.  For example, you can
-calculate the value of @code{foo (z)}, save it in a variable, and use
-that variable in @code{min}:
-
-@smallexample
-@group
-#define min(X, Y)  ((X) < (Y) ? (X) : (Y))
-@dots{}
-@{
-  int tem = foo (z);
-  next = min (x + y, tem);
-@}
-@end group
-@end smallexample
-
-@noindent
-(where we assume that @code{foo} returns type @code{int}).
-
-@node Self-Referential Macros
-@subsection Self-Referential Macros
-@cindex self-reference
-
-A @dfn{self-referential} macro is one whose name appears in its
-definition.  Recall that all macro definitions are rescanned for more
-macros to replace.  If the self-reference were considered a use of the
-macro, it would produce an infinitely large expansion.  To prevent this,
-the self-reference is not considered a macro call.  It is passed into
-the preprocessor output unchanged.  Consider an example:
-
-@smallexample
-#define foo (4 + foo)
-@end smallexample
-
-@noindent
-where @code{foo} is also a variable in your program.
-
-Following the ordinary rules, each reference to @code{foo} will expand
-into @code{(4 + foo)}; then this will be rescanned and will expand into
-@code{(4 + (4 + foo))}; and so on until the computer runs out of memory.
-
-The self-reference rule cuts this process short after one step, at
-@code{(4 + foo)}.  Therefore, this macro definition has the possibly
-useful effect of causing the program to add 4 to the value of @code{foo}
-wherever @code{foo} is referred to.
-
-In most cases, it is a bad idea to take advantage of this feature.  A
-person reading the program who sees that @code{foo} is a variable will
-not expect that it is a macro as well.  The reader will come across the
-identifier @code{foo} in the program and think its value should be that
-of the variable @code{foo}, whereas in fact the value is four greater.
-
-One common, useful use of self-reference is to create a macro which
-expands to itself.  If you write
-
-@smallexample
-#define EPERM EPERM
-@end smallexample
-
-@noindent
-then the macro @code{EPERM} expands to @code{EPERM}.  Effectively, it is
-left alone by the preprocessor whenever it's used in running text.  You
-can tell that it's a macro with @samp{#ifdef}.  You might do this if you
-want to define numeric constants with an @code{enum}, but have
-@samp{#ifdef} be true for each constant.
-
-If a macro @code{x} expands to use a macro @code{y}, and the expansion of
-@code{y} refers to the macro @code{x}, that is an @dfn{indirect
-self-reference} of @code{x}.  @code{x} is not expanded in this case
-either.  Thus, if we have
-
-@smallexample
-#define x (4 + y)
-#define y (2 * x)
-@end smallexample
-
-@noindent
-then @code{x} and @code{y} expand as follows:
-
-@smallexample
-@group
-x    @expansion{} (4 + y)
-     @expansion{} (4 + (2 * x))
-
-y    @expansion{} (2 * x)
-     @expansion{} (2 * (4 + y))
-@end group
-@end smallexample
-
-@noindent
-Each macro is expanded when it appears in the definition of the other
-macro, but not when it indirectly appears in its own definition.
-
-@node Argument Prescan
-@subsection Argument Prescan
-@cindex expansion of arguments
-@cindex macro argument expansion
-@cindex prescan of macro arguments
-
-Macro arguments are completely macro-expanded before they are
-substituted into a macro body, unless they are stringified or pasted
-with other tokens.  After substitution, the entire macro body, including
-the substituted arguments, is scanned again for macros to be expanded.
-The result is that the arguments are scanned @emph{twice} to expand
-macro calls in them.
-
-Most of the time, this has no effect.  If the argument contained any
-macro calls, they are expanded during the first scan.  The result
-therefore contains no macro calls, so the second scan does not change
-it.  If the argument were substituted as given, with no prescan, the
-single remaining scan would find the same macro calls and produce the
-same results.
-
-You might expect the double scan to change the results when a
-self-referential macro is used in an argument of another macro
-(@pxref{Self-Referential Macros}): the self-referential macro would be
-expanded once in the first scan, and a second time in the second scan.
-However, this is not what happens.  The self-references that do not
-expand in the first scan are marked so that they will not expand in the
-second scan either.
-
-You might wonder, ``Why mention the prescan, if it makes no difference?
-And why not skip it and make the preprocessor faster?''  The answer is
-that the prescan does make a difference in three special cases:
-
-@itemize @bullet
-@item
-Nested calls to a macro.
-
-We say that @dfn{nested} calls to a macro occur when a macro's argument
-contains a call to that very macro.  For example, if @code{f} is a macro
-that expects one argument, @code{f (f (1))} is a nested pair of calls to
-@code{f}.  The desired expansion is made by expanding @code{f (1)} and
-substituting that into the definition of @code{f}.  The prescan causes
-the expected result to happen.  Without the prescan, @code{f (1)} itself
-would be substituted as an argument, and the inner use of @code{f} would
-appear during the main scan as an indirect self-reference and would not
-be expanded.
-
-@item
-Macros that call other macros that stringify or concatenate.
-
-If an argument is stringified or concatenated, the prescan does not
-occur.  If you @emph{want} to expand a macro, then stringify or
-concatenate its expansion, you can do that by causing one macro to call
-another macro that does the stringification or concatenation.  For
-instance, if you have
-
-@smallexample
-#define AFTERX(x) X_ ## x
-#define XAFTERX(x) AFTERX(x)
-#define TABLESIZE 1024
-#define BUFSIZE TABLESIZE
-@end smallexample
-
-then @code{AFTERX(BUFSIZE)} expands to @code{X_BUFSIZE}, and
-@code{XAFTERX(BUFSIZE)} expands to @code{X_1024}.  (Not to
-@code{X_TABLESIZE}.  Prescan always does a complete expansion.)
-
-@item
-Macros used in arguments, whose expansions contain unshielded commas.
-
-This can cause a macro expanded on the second scan to be called with the
-wrong number of arguments.  Here is an example:
-
-@smallexample
-#define foo  a,b
-#define bar(x) lose(x)
-#define lose(x) (1 + (x))
-@end smallexample
-
-We would like @code{bar(foo)} to turn into @code{(1 + (foo))}, which
-would then turn into @code{(1 + (a,b))}.  Instead, @code{bar(foo)}
-expands into @code{lose(a,b)}, and you get an error because @code{lose}
-requires a single argument.  In this case, the problem is easily solved
-by the same parentheses that ought to be used to prevent misnesting of
-arithmetic operations:
-
-@smallexample
-#define foo (a,b)
-@exdent or
-#define bar(x) lose((x))
-@end smallexample
-
-The extra pair of parentheses prevents the comma in @code{foo}'s
-definition from being interpreted as an argument separator.
-
-@end itemize
-
-@node Newlines in Arguments
-@subsection Newlines in Arguments
-@cindex newlines in macro arguments
-
-The invocation of a function-like macro can extend over many logical
-lines.  However, in the present implementation, the entire expansion
-comes out on one line.  Thus line numbers emitted by the compiler or
-debugger refer to the line the invocation started on, which might be
-different to the line containing the argument causing the problem.
-
-Here is an example illustrating this:
-
-@smallexample
-#define ignore_second_arg(a,b,c) a; c
-
-ignore_second_arg (foo (),
-                   ignored (),
-                   syntax error);
-@end smallexample
-
-@noindent
-The syntax error triggered by the tokens @code{syntax error} results in
-an error message citing line three---the line of ignore_second_arg---
-even though the problematic code comes from line five.
-
-We consider this a bug, and intend to fix it in the near future.
-
-@node Conditionals
-@chapter Conditionals
-@cindex conditionals
-
-A @dfn{conditional} is a directive that instructs the preprocessor to
-select whether or not to include a chunk of code in the final token
-stream passed to the compiler.  Preprocessor conditionals can test
-arithmetic expressions, or whether a name is defined as a macro, or both
-simultaneously using the special @code{defined} operator.
-
-A conditional in the C preprocessor resembles in some ways an @code{if}
-statement in C, but it is important to understand the difference between
-them.  The condition in an @code{if} statement is tested during the
-execution of your program.  Its purpose is to allow your program to
-behave differently from run to run, depending on the data it is
-operating on.  The condition in a preprocessing conditional directive is
-tested when your program is compiled.  Its purpose is to allow different
-code to be included in the program depending on the situation at the
-time of compilation.
-
-However, the distinction is becoming less clear.  Modern compilers often
-do test @code{if} statements when a program is compiled, if their
-conditions are known not to vary at run time, and eliminate code which
-can never be executed.  If you can count on your compiler to do this,
-you may find that your program is more readable if you use @code{if}
-statements with constant conditions (perhaps determined by macros).  Of
-course, you can only use this to exclude code, not type definitions or
-other preprocessing directives, and you can only do it if the code
-remains syntactically valid when it is not to be used.
-
-GCC version 3 eliminates this kind of never-executed code even when
-not optimizing.  Older versions did it only when optimizing.
-
-@menu
-* Conditional Uses::
-* Conditional Syntax::
-* Deleted Code::
-@end menu
-
-@node Conditional Uses
-@section Conditional Uses
-
-There are three general reasons to use a conditional.
-
-@itemize @bullet
-@item
-A program may need to use different code depending on the machine or
-operating system it is to run on.  In some cases the code for one
-operating system may be erroneous on another operating system; for
-example, it might refer to data types or constants that do not exist on
-the other system.  When this happens, it is not enough to avoid
-executing the invalid code.  Its mere presence will cause the compiler
-to reject the program.  With a preprocessing conditional, the offending
-code can be effectively excised from the program when it is not valid.
-
-@item
-You may want to be able to compile the same source file into two
-different programs.  One version might make frequent time-consuming
-consistency checks on its intermediate data, or print the values of
-those data for debugging, and the other not.
-
-@item
-A conditional whose condition is always false is one way to exclude code
-from the program but keep it as a sort of comment for future reference.
-@end itemize
-
-Simple programs that do not need system-specific logic or complex
-debugging hooks generally will not need to use preprocessing
-conditionals.
-
-@node Conditional Syntax
-@section Conditional Syntax
-
-@findex #if
-A conditional in the C preprocessor begins with a @dfn{conditional
-directive}: @samp{#if}, @samp{#ifdef} or @samp{#ifndef}.
-
-@menu
-* Ifdef::
-* If::
-* Defined::
-* Else::
-* Elif::
-@end menu
-
-@node Ifdef
-@subsection Ifdef
-@findex #ifdef
-@findex #endif
-
-The simplest sort of conditional is
-
-@smallexample
-@group
-#ifdef @var{MACRO}
-
-@var{controlled text}
-
-#endif /* @var{MACRO} */
-@end group
-@end smallexample
-
-@cindex conditional group
-This block is called a @dfn{conditional group}.  @var{controlled text}
-will be included in the output of the preprocessor if and only if
-@var{MACRO} is defined.  We say that the conditional @dfn{succeeds} if
-@var{MACRO} is defined, @dfn{fails} if it is not.
-
-The @var{controlled text} inside of a conditional can include
-preprocessing directives.  They are executed only if the conditional
-succeeds.  You can nest conditional groups inside other conditional
-groups, but they must be completely nested.  In other words,
-@samp{#endif} always matches the nearest @samp{#ifdef} (or
-@samp{#ifndef}, or @samp{#if}).  Also, you cannot start a conditional
-group in one file and end it in another.
-
-Even if a conditional fails, the @var{controlled text} inside it is
-still run through initial transformations and tokenization.  Therefore,
-it must all be lexically valid C@.  Normally the only way this matters is
-that all comments and string literals inside a failing conditional group
-must still be properly ended.
-
-The comment following the @samp{#endif} is not required, but it is a
-good practice if there is a lot of @var{controlled text}, because it
-helps people match the @samp{#endif} to the corresponding @samp{#ifdef}.
-Older programs sometimes put @var{MACRO} directly after the
-@samp{#endif} without enclosing it in a comment.  This is invalid code
-according to the C standard.  CPP accepts it with a warning.  It
-never affects which @samp{#ifndef} the @samp{#endif} matches.
-
-@findex #ifndef
-Sometimes you wish to use some code if a macro is @emph{not} defined.
-You can do this by writing @samp{#ifndef} instead of @samp{#ifdef}.
-One common use of @samp{#ifndef} is to include code only the first
-time a header file is included.  @xref{Once-Only Headers}.
-
-Macro definitions can vary between compilations for several reasons.
-Here are some samples.
-
-@itemize @bullet
-@item
-Some macros are predefined on each kind of machine
-(@pxref{System-specific Predefined Macros}).  This allows you to provide
-code specially tuned for a particular machine.
-
-@item
-System header files define more macros, associated with the features
-they implement.  You can test these macros with conditionals to avoid
-using a system feature on a machine where it is not implemented.
-
-@item
-Macros can be defined or undefined with the @option{-D} and @option{-U}
-command-line options when you compile the program.  You can arrange to
-compile the same source file into two different programs by choosing a
-macro name to specify which program you want, writing conditionals to
-test whether or how this macro is defined, and then controlling the
-state of the macro with command-line options, perhaps set in the
-Makefile.  @xref{Invocation}.
-
-@item
-Your program might have a special header file (often called
-@file{config.h}) that is adjusted when the program is compiled.  It can
-define or not define macros depending on the features of the system and
-the desired capabilities of the program.  The adjustment can be
-automated by a tool such as @command{autoconf}, or done by hand.
-@end itemize
-
-@node If
-@subsection If
-
-The @samp{#if} directive allows you to test the value of an arithmetic
-expression, rather than the mere existence of one macro.  Its syntax is
-
-@smallexample
-@group
-#if @var{expression}
-
-@var{controlled text}
-
-#endif /* @var{expression} */
-@end group
-@end smallexample
-
-@var{expression} is a C expression of integer type, subject to stringent
-restrictions.  It may contain
-
-@itemize @bullet
-@item
-Integer constants.
-
-@item
-Character constants, which are interpreted as they would be in normal
-code.
-
-@item
-Arithmetic operators for addition, subtraction, multiplication,
-division, bitwise operations, shifts, comparisons, and logical
-operations (@code{&&} and @code{||}).  The latter two obey the usual
-short-circuiting rules of standard C@.
-
-@item
-Macros.  All macros in the expression are expanded before actual
-computation of the expression's value begins.
-
-@item
-Uses of the @code{defined} operator, which lets you check whether macros
-are defined in the middle of an @samp{#if}.
-
-@item
-Identifiers that are not macros, which are all considered to be the
-number zero.  This allows you to write @code{@w{#if MACRO}} instead of
-@code{@w{#ifdef MACRO}}, if you know that MACRO, when defined, will
-always have a nonzero value.  Function-like macros used without their
-function call parentheses are also treated as zero.
-
-In some contexts this shortcut is undesirable.  The @option{-Wundef}
-option causes GCC to warn whenever it encounters an identifier which is
-not a macro in an @samp{#if}.
-@end itemize
-
-The preprocessor does not know anything about types in the language.
-Therefore, @code{sizeof} operators are not recognized in @samp{#if}, and
-neither are @code{enum} constants.  They will be taken as identifiers
-which are not macros, and replaced by zero.  In the case of
-@code{sizeof}, this is likely to cause the expression to be invalid.
-
-The preprocessor calculates the value of @var{expression}.  It carries
-out all calculations in the widest integer type known to the compiler;
-on most machines supported by GCC this is 64 bits.  This is not the same
-rule as the compiler uses to calculate the value of a constant
-expression, and may give different results in some cases.  If the value
-comes out to be nonzero, the @samp{#if} succeeds and the @var{controlled
-text} is included; otherwise it is skipped.
-
-@node Defined
-@subsection Defined
-
-@cindex @code{defined}
-The special operator @code{defined} is used in @samp{#if} and
-@samp{#elif} expressions to test whether a certain name is defined as a
-macro.  @code{defined @var{name}} and @code{defined (@var{name})} are
-both expressions whose value is 1 if @var{name} is defined as a macro at
-the current point in the program, and 0 otherwise.  Thus,  @code{@w{#if
-defined MACRO}} is precisely equivalent to @code{@w{#ifdef MACRO}}.
-
-@code{defined} is useful when you wish to test more than one macro for
-existence at once.  For example,
-
-@smallexample
-#if defined (__vax__) || defined (__ns16000__)
-@end smallexample
-
-@noindent
-would succeed if either of the names @code{__vax__} or
-@code{__ns16000__} is defined as a macro.
-
-Conditionals written like this:
-
-@smallexample
-#if defined BUFSIZE && BUFSIZE >= 1024
-@end smallexample
-
-@noindent
-can generally be simplified to just @code{@w{#if BUFSIZE >= 1024}},
-since if @code{BUFSIZE} is not defined, it will be interpreted as having
-the value zero.
-
-If the @code{defined} operator appears as a result of a macro expansion,
-the C standard says the behavior is undefined.  GNU cpp treats it as a
-genuine @code{defined} operator and evaluates it normally.  It will warn
-wherever your code uses this feature if you use the command-line option
-@option{-pedantic}, since other compilers may handle it differently.
-
-@node Else
-@subsection Else
-
-@findex #else
-The @samp{#else} directive can be added to a conditional to provide
-alternative text to be used if the condition fails.  This is what it
-looks like:
-
-@smallexample
-@group
-#if @var{expression}
-@var{text-if-true}
-#else /* Not @var{expression} */
-@var{text-if-false}
-#endif /* Not @var{expression} */
-@end group
-@end smallexample
-
-@noindent
-If @var{expression} is nonzero, the @var{text-if-true} is included and
-the @var{text-if-false} is skipped.  If @var{expression} is zero, the
-opposite happens.
-
-You can use @samp{#else} with @samp{#ifdef} and @samp{#ifndef}, too.
-
-@node Elif
-@subsection Elif
-
-@findex #elif
-One common case of nested conditionals is used to check for more than two
-possible alternatives.  For example, you might have
-
-@smallexample
-#if X == 1
-@dots{}
-#else /* X != 1 */
-#if X == 2
-@dots{}
-#else /* X != 2 */
-@dots{}
-#endif /* X != 2 */
-#endif /* X != 1 */
-@end smallexample
-
-Another conditional directive, @samp{#elif}, allows this to be
-abbreviated as follows:
-
-@smallexample
-#if X == 1
-@dots{}
-#elif X == 2
-@dots{}
-#else /* X != 2 and X != 1*/
-@dots{}
-#endif /* X != 2 and X != 1*/
-@end smallexample
-
-@samp{#elif} stands for ``else if''.  Like @samp{#else}, it goes in the
-middle of a conditional group and subdivides it; it does not require a
-matching @samp{#endif} of its own.  Like @samp{#if}, the @samp{#elif}
-directive includes an expression to be tested.  The text following the
-@samp{#elif} is processed only if the original @samp{#if}-condition
-failed and the @samp{#elif} condition succeeds.
-
-More than one @samp{#elif} can go in the same conditional group.  Then
-the text after each @samp{#elif} is processed only if the @samp{#elif}
-condition succeeds after the original @samp{#if} and all previous
-@samp{#elif} directives within it have failed.
-
-@samp{#else} is allowed after any number of @samp{#elif} directives, but
-@samp{#elif} may not follow @samp{#else}.
-
-@node Deleted Code
-@section Deleted Code
-@cindex commenting out code
-
-If you replace or delete a part of the program but want to keep the old
-code around for future reference, you often cannot simply comment it
-out.  Block comments do not nest, so the first comment inside the old
-code will end the commenting-out.  The probable result is a flood of
-syntax errors.
-
-One way to avoid this problem is to use an always-false conditional
-instead.  For instance, put @code{#if 0} before the deleted code and
-@code{#endif} after it.  This works even if the code being turned
-off contains conditionals, but they must be entire conditionals
-(balanced @samp{#if} and @samp{#endif}).
-
-Some people use @code{#ifdef notdef} instead.  This is risky, because
-@code{notdef} might be accidentally defined as a macro, and then the
-conditional would succeed.  @code{#if 0} can be counted on to fail.
-
-Do not use @code{#if 0} for comments which are not C code.  Use a real
-comment, instead.  The interior of @code{#if 0} must consist of complete
-tokens; in particular, single-quote characters must balance.  Comments
-often contain unbalanced single-quote characters (known in English as
-apostrophes).  These confuse @code{#if 0}.  They don't confuse
-@samp{/*}.
-
-@node Diagnostics
-@chapter Diagnostics
-@cindex diagnostic
-@cindex reporting errors
-@cindex reporting warnings
-
-@findex #error
-The directive @samp{#error} causes the preprocessor to report a fatal
-error.  The tokens forming the rest of the line following @samp{#error}
-are used as the error message.
-
-You would use @samp{#error} inside of a conditional that detects a
-combination of parameters which you know the program does not properly
-support.  For example, if you know that the program will not run
-properly on a VAX, you might write
-
-@smallexample
-@group
-#ifdef __vax__
-#error "Won't work on VAXen.  See comments at get_last_object."
-#endif
-@end group
-@end smallexample
-
-If you have several configuration parameters that must be set up by
-the installation in a consistent way, you can use conditionals to detect
-an inconsistency and report it with @samp{#error}.  For example,
-
-@smallexample
-#if !defined(FOO) && defined(BAR)
-#error "BAR requires FOO."
-#endif
-@end smallexample
-
-@findex #warning
-The directive @samp{#warning} is like @samp{#error}, but causes the
-preprocessor to issue a warning and continue preprocessing.  The tokens
-following @samp{#warning} are used as the warning message.
-
-You might use @samp{#warning} in obsolete header files, with a message
-directing the user to the header file which should be used instead.
-
-Neither @samp{#error} nor @samp{#warning} macro-expands its argument.
-Internal whitespace sequences are each replaced with a single space.
-The line must consist of complete tokens.  It is wisest to make the
-argument of these directives be a single string constant; this avoids
-problems with apostrophes and the like.
-
-@node Line Control
-@chapter Line Control
-@cindex line control
-
-The C preprocessor informs the C compiler of the location in your source
-code where each token came from.  Presently, this is just the file name
-and line number.  All the tokens resulting from macro expansion are
-reported as having appeared on the line of the source file where the
-outermost macro was used.  We intend to be more accurate in the future.
-
-If you write a program which generates source code, such as the
-@command{bison} parser generator, you may want to adjust the preprocessor's
-notion of the current file name and line number by hand.  Parts of the
-output from @command{bison} are generated from scratch, other parts come
-from a standard parser file.  The rest are copied verbatim from
-@command{bison}'s input.  You would like compiler error messages and
-symbolic debuggers to be able to refer to @code{bison}'s input file.
-
-@findex #line
-@command{bison} or any such program can arrange this by writing
-@samp{#line} directives into the output file.  @samp{#line} is a
-directive that specifies the original line number and source file name
-for subsequent input in the current preprocessor input file.
-@samp{#line} has three variants:
-
-@table @code
-@item #line @var{linenum}
-@var{linenum} is a non-negative decimal integer constant.  It specifies
-the line number which should be reported for the following line of
-input.  Subsequent lines are counted from @var{linenum}.
-
-@item #line @var{linenum} @var{filename}
-@var{linenum} is the same as for the first form, and has the same
-effect.  In addition, @var{filename} is a string constant.  The
-following line and all subsequent lines are reported to come from the
-file it specifies, until something else happens to change that.
-@var{filename} is interpreted according to the normal rules for a string
-constant: backslash escapes are interpreted.  This is different from
-@samp{#include}.
-
-Previous versions of CPP did not interpret escapes in @samp{#line};
-we have changed it because the standard requires they be interpreted,
-and most other compilers do.
-
-@item #line @var{anything else}
-@var{anything else} is checked for macro calls, which are expanded.
-The result should match one of the above two forms.
-@end table
-
-@samp{#line} directives alter the results of the @code{__FILE__} and
-@code{__LINE__} predefined macros from that point on.  @xref{Standard
-Predefined Macros}.  They do not have any effect on @samp{#include}'s
-idea of the directory containing the current file.  This is a change
-from GCC 2.95.  Previously, a file reading
-
-@smallexample
-#line 1 "../src/gram.y"
-#include "gram.h"
-@end smallexample
-
-would search for @file{gram.h} in @file{../src}, then the @option{-I}
-chain; the directory containing the physical source file would not be
-searched.  In GCC 3.0 and later, the @samp{#include} is not affected by
-the presence of a @samp{#line} referring to a different directory.
-
-We made this change because the old behavior caused problems when
-generated source files were transported between machines.  For instance,
-it is common practice to ship generated parsers with a source release,
-so that people building the distribution do not need to have yacc or
-Bison installed.  These files frequently have @samp{#line} directives
-referring to the directory tree of the system where the distribution was
-created.  If GCC tries to search for headers in those directories, the
-build is likely to fail.
-
-The new behavior can cause failures too, if the generated file is not
-in the same directory as its source and it attempts to include a header
-which would be visible searching from the directory containing the
-source file.  However, this problem is easily solved with an additional
-@option{-I} switch on the command line.  The failures caused by the old
-semantics could sometimes be corrected only by editing the generated
-files, which is difficult and error-prone.
-
-@node Pragmas
-@chapter Pragmas
-
-The @samp{#pragma} directive is the method specified by the C standard
-for providing additional information to the compiler, beyond what is
-conveyed in the language itself.  Three forms of this directive
-(commonly known as @dfn{pragmas}) are specified by the 1999 C standard.
-A C compiler is free to attach any meaning it likes to other pragmas.
-
-GCC has historically preferred to use extensions to the syntax of the
-language, such as @code{__attribute__}, for this purpose.  However, GCC
-does define a few pragmas of its own.  These mostly have effects on the
-entire translation unit or source file.
-
-In GCC version 3, all GNU-defined, supported pragmas have been given a
-@code{GCC} prefix.  This is in line with the @code{STDC} prefix on all
-pragmas defined by C99.  For backward compatibility, pragmas which were
-recognized by previous versions are still recognized without the
-@code{GCC} prefix, but that usage is deprecated.  Some older pragmas are
-deprecated in their entirety.  They are not recognized with the
-@code{GCC} prefix.  @xref{Obsolete Features}.
-
-@cindex @code{_Pragma}
-C99 introduces the @code{@w{_Pragma}} operator.  This feature addresses a
-major problem with @samp{#pragma}: being a directive, it cannot be
-produced as the result of macro expansion.  @code{@w{_Pragma}} is an
-operator, much like @code{sizeof} or @code{defined}, and can be embedded
-in a macro.
-
-Its syntax is @code{@w{_Pragma (@var{string-literal})}}, where
-@var{string-literal} can be either a normal or wide-character string
-literal.  It is destringized, by replacing all @samp{\\} with a single
-@samp{\} and all @samp{\"} with a @samp{"}.  The result is then
-processed as if it had appeared as the right hand side of a
-@samp{#pragma} directive.  For example,
-
-@smallexample
-_Pragma ("GCC dependency \"parse.y\"")
-@end smallexample
-
-@noindent
-has the same effect as @code{#pragma GCC dependency "parse.y"}.  The
-same effect could be achieved using macros, for example
-
-@smallexample
-#define DO_PRAGMA(x) _Pragma (#x)
-DO_PRAGMA (GCC dependency "parse.y")
-@end smallexample
-
-The standard is unclear on where a @code{_Pragma} operator can appear.
-The preprocessor does not accept it within a preprocessing conditional
-directive like @samp{#if}.  To be safe, you are probably best keeping it
-out of directives other than @samp{#define}, and putting it on a line of
-its own.
-
-This manual documents the pragmas which are meaningful to the
-preprocessor itself.  Other pragmas are meaningful to the C or C++
-compilers.  They are documented in the GCC manual.
-
-GCC plugins may provide their own pragmas.
-
-@ftable @code
-@item #pragma GCC dependency
-@code{#pragma GCC dependency} allows you to check the relative dates of
-the current file and another file.  If the other file is more recent than
-the current file, a warning is issued.  This is useful if the current
-file is derived from the other file, and should be regenerated.  The
-other file is searched for using the normal include search path.
-Optional trailing text can be used to give more information in the
-warning message.
-
-@smallexample
-#pragma GCC dependency "parse.y"
-#pragma GCC dependency "/usr/include/time.h" rerun fixincludes
-@end smallexample
-
-@item #pragma GCC poison
-Sometimes, there is an identifier that you want to remove completely
-from your program, and make sure that it never creeps back in.  To
-enforce this, you can @dfn{poison} the identifier with this pragma.
-@code{#pragma GCC poison} is followed by a list of identifiers to
-poison.  If any of those identifiers appears anywhere in the source
-after the directive, it is a hard error.  For example,
-
-@smallexample
-#pragma GCC poison printf sprintf fprintf
-sprintf(some_string, "hello");
-@end smallexample
-
-@noindent
-will produce an error.
-
-If a poisoned identifier appears as part of the expansion of a macro
-which was defined before the identifier was poisoned, it will @emph{not}
-cause an error.  This lets you poison an identifier without worrying
-about system headers defining macros that use it.
-
-For example,
-
-@smallexample
-#define strrchr rindex
-#pragma GCC poison rindex
-strrchr(some_string, 'h');
-@end smallexample
-
-@noindent
-will not produce an error.
-
-@item #pragma GCC system_header
-This pragma takes no arguments.  It causes the rest of the code in the
-current file to be treated as if it came from a system header.
-@xref{System Headers}.
-
-@item #pragma GCC warning
-@itemx #pragma GCC error
-@code{#pragma GCC warning "message"} causes the preprocessor to issue
-a warning diagnostic with the text @samp{message}.  The message
-contained in the pragma must be a single string literal.  Similarly,
-@code{#pragma GCC error "message"} issues an error message.  Unlike
-the @samp{#warning} and @samp{#error} directives, these pragmas can be
-embedded in preprocessor macros using @samp{_Pragma}.
-
-@end ftable
-
-@node Other Directives
-@chapter Other Directives
-
-@findex #ident
-@findex #sccs
-The @samp{#ident} directive takes one argument, a string constant.  On
-some systems, that string constant is copied into a special segment of
-the object file.  On other systems, the directive is ignored.  The
-@samp{#sccs} directive is a synonym for @samp{#ident}.
-
-These directives are not part of the C standard, but they are not
-official GNU extensions either.  What historical information we have
-been able to find, suggests they originated with System V@.
-
-@cindex null directive
-The @dfn{null directive} consists of a @samp{#} followed by a newline,
-with only whitespace (including comments) in between.  A null directive
-is understood as a preprocessing directive but has no effect on the
-preprocessor output.  The primary significance of the existence of the
-null directive is that an input line consisting of just a @samp{#} will
-produce no output, rather than a line of output containing just a
-@samp{#}.  Supposedly some old C programs contain such lines.
-
-@node Preprocessor Output
-@chapter Preprocessor Output
-
-When the C preprocessor is used with the C, C++, or Objective-C
-compilers, it is integrated into the compiler and communicates a stream
-of binary tokens directly to the compiler's parser.  However, it can
-also be used in the more conventional standalone mode, where it produces
-textual output.
-@c FIXME: Document the library interface.
-
-@cindex output format
-The output from the C preprocessor looks much like the input, except
-that all preprocessing directive lines have been replaced with blank
-lines and all comments with spaces.  Long runs of blank lines are
-discarded.
-
-The ISO standard specifies that it is implementation defined whether a
-preprocessor preserves whitespace between tokens, or replaces it with
-e.g.@: a single space.  In GNU CPP, whitespace between tokens is collapsed
-to become a single space, with the exception that the first token on a
-non-directive line is preceded with sufficient spaces that it appears in
-the same column in the preprocessed output that it appeared in the
-original source file.  This is so the output is easy to read.
-@xref{Differences from previous versions}.  CPP does not insert any
-whitespace where there was none in the original source, except where
-necessary to prevent an accidental token paste.
-
-@cindex linemarkers
-Source file name and line number information is conveyed by lines
-of the form
-
-@smallexample
-# @var{linenum} @var{filename} @var{flags}
-@end smallexample
-
-@noindent
-These are called @dfn{linemarkers}.  They are inserted as needed into
-the output (but never within a string or character constant).  They mean
-that the following line originated in file @var{filename} at line
-@var{linenum}.  @var{filename} will never contain any non-printing
-characters; they are replaced with octal escape sequences.
-
-After the file name comes zero or more flags, which are @samp{1},
-@samp{2}, @samp{3}, or @samp{4}.  If there are multiple flags, spaces
-separate them.  Here is what the flags mean:
-
-@table @samp
-@item 1
-This indicates the start of a new file.
-@item 2
-This indicates returning to a file (after having included another file).
-@item 3
-This indicates that the following text comes from a system header file,
-so certain warnings should be suppressed.
-@item 4
-This indicates that the following text should be treated as being
-wrapped in an implicit @code{extern "C"} block.
-@c maybe cross reference NO_IMPLICIT_EXTERN_C
-@end table
-
-As an extension, the preprocessor accepts linemarkers in non-assembler
-input files.  They are treated like the corresponding @samp{#line}
-directive, (@pxref{Line Control}), except that trailing flags are
-permitted, and are interpreted with the meanings described above.  If
-multiple flags are given, they must be in ascending order.
-
-Some directives may be duplicated in the output of the preprocessor.
-These are @samp{#ident} (always), @samp{#pragma} (only if the
-preprocessor does not handle the pragma itself), and @samp{#define} and
-@samp{#undef} (with certain debugging options).  If this happens, the
-@samp{#} of the directive will always be in the first column, and there
-will be no space between the @samp{#} and the directive name.  If macro
-expansion happens to generate tokens which might be mistaken for a
-duplicated directive, a space will be inserted between the @samp{#} and
-the directive name.
-
-@node Traditional Mode
-@chapter Traditional Mode
-
-Traditional (pre-standard) C preprocessing is rather different from
-the preprocessing specified by the standard.  When GCC is given the
-@option{-traditional-cpp} option, it attempts to emulate a traditional
-preprocessor.
-
-GCC versions 3.2 and later only support traditional mode semantics in
-the preprocessor, and not in the compiler front ends.  This chapter
-outlines the traditional preprocessor semantics we implemented.
-
-The implementation does not correspond precisely to the behavior of
-earlier versions of GCC, nor to any true traditional preprocessor.
-After all, inconsistencies among traditional implementations were a
-major motivation for C standardization.  However, we intend that it
-should be compatible with true traditional preprocessors in all ways
-that actually matter.
-
-@menu
-* Traditional lexical analysis::
-* Traditional macros::
-* Traditional miscellany::
-* Traditional warnings::
-@end menu
-
-@node Traditional lexical analysis
-@section Traditional lexical analysis
-
-The traditional preprocessor does not decompose its input into tokens
-the same way a standards-conforming preprocessor does.  The input is
-simply treated as a stream of text with minimal internal form.
-
-This implementation does not treat trigraphs (@pxref{trigraphs})
-specially since they were an invention of the standards committee.  It
-handles arbitrarily-positioned escaped newlines properly and splices
-the lines as you would expect; many traditional preprocessors did not
-do this.
-
-The form of horizontal whitespace in the input file is preserved in
-the output.  In particular, hard tabs remain hard tabs.  This can be
-useful if, for example, you are preprocessing a Makefile.
-
-Traditional CPP only recognizes C-style block comments, and treats the
-@samp{/*} sequence as introducing a comment only if it lies outside
-quoted text.  Quoted text is introduced by the usual single and double
-quotes, and also by an initial @samp{<} in a @code{#include}
-directive.
-
-Traditionally, comments are completely removed and are not replaced
-with a space.  Since a traditional compiler does its own tokenization
-of the output of the preprocessor, this means that comments can
-effectively be used as token paste operators.  However, comments
-behave like separators for text handled by the preprocessor itself,
-since it doesn't re-lex its input.  For example, in
-
-@smallexample
-#if foo/**/bar
-@end smallexample
-
-@noindent
-@samp{foo} and @samp{bar} are distinct identifiers and expanded
-separately if they happen to be macros.  In other words, this
-directive is equivalent to
-
-@smallexample
-#if foo bar
-@end smallexample
-
-@noindent
-rather than
-
-@smallexample
-#if foobar
-@end smallexample
-
-Generally speaking, in traditional mode an opening quote need not have
-a matching closing quote.  In particular, a macro may be defined with
-replacement text that contains an unmatched quote.  Of course, if you
-attempt to compile preprocessed output containing an unmatched quote
-you will get a syntax error.
-
-However, all preprocessing directives other than @code{#define}
-require matching quotes.  For example:
-
-@smallexample
-#define m This macro's fine and has an unmatched quote
-"/* This is not a comment.  */
-/* @r{This is a comment.  The following #include directive
-   is ill-formed.}  */
-#include <stdio.h
-@end smallexample
-
-Just as for the ISO preprocessor, what would be a closing quote can be
-escaped with a backslash to prevent the quoted text from closing.
-
-@node Traditional macros
-@section Traditional macros
-
-The major difference between traditional and ISO macros is that the
-former expand to text rather than to a token sequence.  CPP removes
-all leading and trailing horizontal whitespace from a macro's
-replacement text before storing it, but preserves the form of internal
-whitespace.
-
-One consequence is that it is legitimate for the replacement text to
-contain an unmatched quote (@pxref{Traditional lexical analysis}).  An
-unclosed string or character constant continues into the text
-following the macro call.  Similarly, the text at the end of a macro's
-expansion can run together with the text after the macro invocation to
-produce a single token.
-
-Normally comments are removed from the replacement text after the
-macro is expanded, but if the @option{-CC} option is passed on the
-command-line comments are preserved.  (In fact, the current
-implementation removes comments even before saving the macro
-replacement text, but it careful to do it in such a way that the
-observed effect is identical even in the function-like macro case.)
-
-The ISO stringification operator @samp{#} and token paste operator
-@samp{##} have no special meaning.  As explained later, an effect
-similar to these operators can be obtained in a different way.  Macro
-names that are embedded in quotes, either from the main file or after
-macro replacement, do not expand.
-
-CPP replaces an unquoted object-like macro name with its replacement
-text, and then rescans it for further macros to replace.  Unlike
-standard macro expansion, traditional macro expansion has no provision
-to prevent recursion.  If an object-like macro appears unquoted in its
-replacement text, it will be replaced again during the rescan pass,
-and so on @emph{ad infinitum}.  GCC detects when it is expanding
-recursive macros, emits an error message, and continues after the
-offending macro invocation.
-
-@smallexample
-#define PLUS +
-#define INC(x) PLUS+x
-INC(foo);
-     @expansion{} ++foo;
-@end smallexample
-
-Function-like macros are similar in form but quite different in
-behavior to their ISO counterparts.  Their arguments are contained
-within parentheses, are comma-separated, and can cross physical lines.
-Commas within nested parentheses are not treated as argument
-separators.  Similarly, a quote in an argument cannot be left
-unclosed; a following comma or parenthesis that comes before the
-closing quote is treated like any other character.  There is no
-facility for handling variadic macros.
-
-This implementation removes all comments from macro arguments, unless
-the @option{-C} option is given.  The form of all other horizontal
-whitespace in arguments is preserved, including leading and trailing
-whitespace.  In particular
-
-@smallexample
-f( )
-@end smallexample
-
-@noindent
-is treated as an invocation of the macro @samp{f} with a single
-argument consisting of a single space.  If you want to invoke a
-function-like macro that takes no arguments, you must not leave any
-whitespace between the parentheses.
-
-If a macro argument crosses a new line, the new line is replaced with
-a space when forming the argument.  If the previous line contained an
-unterminated quote, the following line inherits the quoted state.
-
-Traditional preprocessors replace parameters in the replacement text
-with their arguments regardless of whether the parameters are within
-quotes or not.  This provides a way to stringize arguments.  For
-example
-
-@smallexample
-#define str(x) "x"
-str(/* @r{A comment} */some text )
-     @expansion{} "some text "
-@end smallexample
-
-@noindent
-Note that the comment is removed, but that the trailing space is
-preserved.  Here is an example of using a comment to effect token
-pasting.
-
-@smallexample
-#define suffix(x) foo_/**/x
-suffix(bar)
-     @expansion{} foo_bar
-@end smallexample
-
-@node Traditional miscellany
-@section Traditional miscellany
-
-Here are some things to be aware of when using the traditional
-preprocessor.
-
-@itemize @bullet
-@item
-Preprocessing directives are recognized only when their leading
-@samp{#} appears in the first column.  There can be no whitespace
-between the beginning of the line and the @samp{#}, but whitespace can
-follow the @samp{#}.
-
-@item
-A true traditional C preprocessor does not recognize @samp{#error} or
-@samp{#pragma}, and may not recognize @samp{#elif}.  CPP supports all
-the directives in traditional mode that it supports in ISO mode,
-including extensions, with the exception that the effects of
-@samp{#pragma GCC poison} are undefined.
-
-@item
-__STDC__ is not defined.
-
-@item
-If you use digraphs the behavior is undefined.
-
-@item
-If a line that looks like a directive appears within macro arguments,
-the behavior is undefined.
-
-@end itemize
-
-@node Traditional warnings
-@section Traditional warnings
-You can request warnings about features that did not exist, or worked
-differently, in traditional C with the @option{-Wtraditional} option.
-GCC does not warn about features of ISO C which you must use when you
-are using a conforming compiler, such as the @samp{#} and @samp{##}
-operators.
-
-Presently @option{-Wtraditional} warns about:
-
-@itemize @bullet
-@item
-Macro parameters that appear within string literals in the macro body.
-In traditional C macro replacement takes place within string literals,
-but does not in ISO C@.
-
-@item
-In traditional C, some preprocessor directives did not exist.
-Traditional preprocessors would only consider a line to be a directive
-if the @samp{#} appeared in column 1 on the line.  Therefore
-@option{-Wtraditional} warns about directives that traditional C
-understands but would ignore because the @samp{#} does not appear as the
-first character on the line.  It also suggests you hide directives like
-@samp{#pragma} not understood by traditional C by indenting them.  Some
-traditional implementations would not recognize @samp{#elif}, so it
-suggests avoiding it altogether.
-
-@item
-A function-like macro that appears without an argument list.  In some
-traditional preprocessors this was an error.  In ISO C it merely means
-that the macro is not expanded.
-
-@item
-The unary plus operator.  This did not exist in traditional C@.
-
-@item
-The @samp{U} and @samp{LL} integer constant suffixes, which were not
-available in traditional C@.  (Traditional C does support the @samp{L}
-suffix for simple long integer constants.)  You are not warned about
-uses of these suffixes in macros defined in system headers.  For
-instance, @code{UINT_MAX} may well be defined as @code{4294967295U}, but
-you will not be warned if you use @code{UINT_MAX}.
-
-You can usually avoid the warning, and the related warning about
-constants which are so large that they are unsigned, by writing the
-integer constant in question in hexadecimal, with no U suffix.  Take
-care, though, because this gives the wrong result in exotic cases.
-@end itemize
-
-@node Implementation Details
-@chapter Implementation Details
-
-Here we document details of how the preprocessor's implementation
-affects its user-visible behavior.  You should try to avoid undue
-reliance on behavior described here, as it is possible that it will
-change subtly in future implementations.
-
-Also documented here are obsolete features and changes from previous
-versions of CPP@.
-
-@menu
-* Implementation-defined behavior::
-* Implementation limits::
-* Obsolete Features::
-* Differences from previous versions::
-@end menu
-
-@node Implementation-defined behavior
-@section Implementation-defined behavior
-@cindex implementation-defined behavior
-
-This is how CPP behaves in all the cases which the C standard
-describes as @dfn{implementation-defined}.  This term means that the
-implementation is free to do what it likes, but must document its choice
-and stick to it.
-@c FIXME: Check the C++ standard for more implementation-defined stuff.
-
-@itemize @bullet
-@need 1000
-@item The mapping of physical source file multi-byte characters to the
-execution character set.
-
-The input character set can be specified using the
-@option{-finput-charset} option, while the execution character set may
-be controlled using the @option{-fexec-charset} and
-@option{-fwide-exec-charset} options.
-
-@item Identifier characters.
-@anchor{Identifier characters}
-
-The C and C++ standards allow identifiers to be composed of @samp{_}
-and the alphanumeric characters.  C++ and C99 also allow universal
-character names, and C99 further permits implementation-defined
-characters.
-
-GCC allows the @samp{$} character in identifiers as an extension for
-most targets.  This is true regardless of the @option{std=} switch,
-since this extension cannot conflict with standards-conforming
-programs.  When preprocessing assembler, however, dollars are not
-identifier characters by default.
-
-Currently the targets that by default do not permit @samp{$} are AVR,
-IP2K, MMIX, MIPS Irix 3, ARM aout, and PowerPC targets for the AIX
-operating system.
-
-You can override the default with @option{-fdollars-in-identifiers} or
-@option{fno-dollars-in-identifiers}.  @xref{fdollars-in-identifiers}.
-
-@item Non-empty sequences of whitespace characters.
-
-In textual output, each whitespace sequence is collapsed to a single
-space.  For aesthetic reasons, the first token on each non-directive
-line of output is preceded with sufficient spaces that it appears in the
-same column as it did in the original source file.
-
-@item The numeric value of character constants in preprocessor expressions.
-
-The preprocessor and compiler interpret character constants in the
-same way; i.e.@: escape sequences such as @samp{\a} are given the
-values they would have on the target machine.
-
-The compiler evaluates a multi-character character constant a character
-at a time, shifting the previous value left by the number of bits per
-target character, and then or-ing in the bit-pattern of the new
-character truncated to the width of a target character.  The final
-bit-pattern is given type @code{int}, and is therefore signed,
-regardless of whether single characters are signed or not (a slight
-change from versions 3.1 and earlier of GCC)@.  If there are more
-characters in the constant than would fit in the target @code{int} the
-compiler issues a warning, and the excess leading characters are
-ignored.
-
-For example, @code{'ab'} for a target with an 8-bit @code{char} would be
-interpreted as @w{@samp{(int) ((unsigned char) 'a' * 256 + (unsigned char)
-'b')}}, and @code{'\234a'} as @w{@samp{(int) ((unsigned char) '\234' *
-256 + (unsigned char) 'a')}}.
-
-@item Source file inclusion.
-
-For a discussion on how the preprocessor locates header files,
-@ref{Include Operation}.
-
-@item Interpretation of the filename resulting from a macro-expanded
-@samp{#include} directive.
-
-@xref{Computed Includes}.
-
-@item Treatment of a @samp{#pragma} directive that after macro-expansion
-results in a standard pragma.
-
-No macro expansion occurs on any @samp{#pragma} directive line, so the
-question does not arise.
-
-Note that GCC does not yet implement any of the standard
-pragmas.
-
-@end itemize
-
-@node Implementation limits
-@section Implementation limits
-@cindex implementation limits
-
-CPP has a small number of internal limits.  This section lists the
-limits which the C standard requires to be no lower than some minimum,
-and all the others known.  It is intended that there should be as few limits
-as possible.  If you encounter an undocumented or inconvenient limit,
-please report that as a bug.  @xref{Bugs, , Reporting Bugs, gcc, Using
-the GNU Compiler Collection (GCC)}.
-
-Where we say something is limited @dfn{only by available memory}, that
-means that internal data structures impose no intrinsic limit, and space
-is allocated with @code{malloc} or equivalent.  The actual limit will
-therefore depend on many things, such as the size of other things
-allocated by the compiler at the same time, the amount of memory
-consumed by other processes on the same computer, etc.
-
-@itemize @bullet
-
-@item Nesting levels of @samp{#include} files.
-
-We impose an arbitrary limit of 200 levels, to avoid runaway recursion.
-The standard requires at least 15 levels.
-
-@item Nesting levels of conditional inclusion.
-
-The C standard mandates this be at least 63.  CPP is limited only by
-available memory.
-
-@item Levels of parenthesized expressions within a full expression.
-
-The C standard requires this to be at least 63.  In preprocessor
-conditional expressions, it is limited only by available memory.
-
-@item Significant initial characters in an identifier or macro name.
-
-The preprocessor treats all characters as significant.  The C standard
-requires only that the first 63 be significant.
-
-@item Number of macros simultaneously defined in a single translation unit.
-
-The standard requires at least 4095 be possible.  CPP is limited only
-by available memory.
-
-@item Number of parameters in a macro definition and arguments in a macro call.
-
-We allow @code{USHRT_MAX}, which is no smaller than 65,535.  The minimum
-required by the standard is 127.
-
-@item Number of characters on a logical source line.
-
-The C standard requires a minimum of 4096 be permitted.  CPP places
-no limits on this, but you may get incorrect column numbers reported in
-diagnostics for lines longer than 65,535 characters.
-
-@item Maximum size of a source file.
-
-The standard does not specify any lower limit on the maximum size of a
-source file.  GNU cpp maps files into memory, so it is limited by the
-available address space.  This is generally at least two gigabytes.
-Depending on the operating system, the size of physical memory may or
-may not be a limitation.
-
-@end itemize
-
-@node Obsolete Features
-@section Obsolete Features
-
-CPP has some features which are present mainly for compatibility with
-older programs.  We discourage their use in new code.  In some cases,
-we plan to remove the feature in a future version of GCC@.
-
-@subsection Assertions
-@cindex assertions
-
-@dfn{Assertions} are a deprecated alternative to macros in writing
-conditionals to test what sort of computer or system the compiled
-program will run on.  Assertions are usually predefined, but you can
-define them with preprocessing directives or command-line options.
-
-Assertions were intended to provide a more systematic way to describe
-the compiler's target system and we added them for compatibility with
-existing compilers.  In practice they are just as unpredictable as the
-system-specific predefined macros.  In addition, they are not part of
-any standard, and only a few compilers support them.
-Therefore, the use of assertions is @strong{less} portable than the use
-of system-specific predefined macros.  We recommend you do not use them at
-all.
-
-@cindex predicates
-An assertion looks like this:
-
-@smallexample
-#@var{predicate} (@var{answer})
-@end smallexample
-
-@noindent
-@var{predicate} must be a single identifier.  @var{answer} can be any
-sequence of tokens; all characters are significant except for leading
-and trailing whitespace, and differences in internal whitespace
-sequences are ignored.  (This is similar to the rules governing macro
-redefinition.)  Thus, @code{(x + y)} is different from @code{(x+y)} but
-equivalent to @code{@w{( x + y )}}.  Parentheses do not nest inside an
-answer.
-
-@cindex testing predicates
-To test an assertion, you write it in an @samp{#if}.  For example, this
-conditional succeeds if either @code{vax} or @code{ns16000} has been
-asserted as an answer for @code{machine}.
-
-@smallexample
-#if #machine (vax) || #machine (ns16000)
-@end smallexample
-
-@noindent
-You can test whether @emph{any} answer is asserted for a predicate by
-omitting the answer in the conditional:
-
-@smallexample
-#if #machine
-@end smallexample
-
-@findex #assert
-Assertions are made with the @samp{#assert} directive.  Its sole
-argument is the assertion to make, without the leading @samp{#} that
-identifies assertions in conditionals.
-
-@smallexample
-#assert @var{predicate} (@var{answer})
-@end smallexample
-
-@noindent
-You may make several assertions with the same predicate and different
-answers.  Subsequent assertions do not override previous ones for the
-same predicate.  All the answers for any given predicate are
-simultaneously true.
-
-@cindex assertions, canceling
-@findex #unassert
-Assertions can be canceled with the @samp{#unassert} directive.  It
-has the same syntax as @samp{#assert}.  In that form it cancels only the
-answer which was specified on the @samp{#unassert} line; other answers
-for that predicate remain true.  You can cancel an entire predicate by
-leaving out the answer:
-
-@smallexample
-#unassert @var{predicate}
-@end smallexample
-
-@noindent
-In either form, if no such assertion has been made, @samp{#unassert} has
-no effect.
-
-You can also make or cancel assertions using command-line options.
-@xref{Invocation}.
-
-@node Differences from previous versions
-@section Differences from previous versions
-@cindex differences from previous versions
-
-This section details behavior which has changed from previous versions
-of CPP@.  We do not plan to change it again in the near future, but
-we do not promise not to, either.
-
-The ``previous versions'' discussed here are 2.95 and before.  The
-behavior of GCC 3.0 is mostly the same as the behavior of the widely
-used 2.96 and 2.97 development snapshots.  Where there are differences,
-they generally represent bugs in the snapshots.
-
-@itemize @bullet
-
-@item -I- deprecated
-
-This option has been deprecated in 4.0.  @option{-iquote} is meant to
-replace the need for this option.
-
-@item Order of evaluation of @samp{#} and @samp{##} operators
-
-The standard does not specify the order of evaluation of a chain of
-@samp{##} operators, nor whether @samp{#} is evaluated before, after, or
-at the same time as @samp{##}.  You should therefore not write any code
-which depends on any specific ordering.  It is possible to guarantee an
-ordering, if you need one, by suitable use of nested macros.
-
-An example of where this might matter is pasting the arguments @samp{1},
-@samp{e} and @samp{-2}.  This would be fine for left-to-right pasting,
-but right-to-left pasting would produce an invalid token @samp{e-2}.
-
-GCC 3.0 evaluates @samp{#} and @samp{##} at the same time and strictly
-left to right.  Older versions evaluated all @samp{#} operators first,
-then all @samp{##} operators, in an unreliable order.
-
-@item The form of whitespace between tokens in preprocessor output
-
-@xref{Preprocessor Output}, for the current textual format.  This is
-also the format used by stringification.  Normally, the preprocessor
-communicates tokens directly to the compiler's parser, and whitespace
-does not come up at all.
-
-Older versions of GCC preserved all whitespace provided by the user and
-inserted lots more whitespace of their own, because they could not
-accurately predict when extra spaces were needed to prevent accidental
-token pasting.
-
-@item Optional argument when invoking rest argument macros
-
-As an extension, GCC permits you to omit the variable arguments entirely
-when you use a variable argument macro.  This is forbidden by the 1999 C
-standard, and will provoke a pedantic warning with GCC 3.0.  Previous
-versions accepted it silently.
-
-@item @samp{##} swallowing preceding text in rest argument macros
-
-Formerly, in a macro expansion, if @samp{##} appeared before a variable
-arguments parameter, and the set of tokens specified for that argument
-in the macro invocation was empty, previous versions of CPP would
-back up and remove the preceding sequence of non-whitespace characters
-(@strong{not} the preceding token).  This extension is in direct
-conflict with the 1999 C standard and has been drastically pared back.
-
-In the current version of the preprocessor, if @samp{##} appears between
-a comma and a variable arguments parameter, and the variable argument is
-omitted entirely, the comma will be removed from the expansion.  If the
-variable argument is empty, or the token before @samp{##} is not a
-comma, then @samp{##} behaves as a normal token paste.
-
-@item @samp{#line} and @samp{#include}
-
-The @samp{#line} directive used to change GCC's notion of the
-``directory containing the current file'', used by @samp{#include} with
-a double-quoted header file name.  In 3.0 and later, it does not.
-@xref{Line Control}, for further explanation.
-
-@item Syntax of @samp{#line}
-
-In GCC 2.95 and previous, the string constant argument to @samp{#line}
-was treated the same way as the argument to @samp{#include}: backslash
-escapes were not honored, and the string ended at the second @samp{"}.
-This is not compliant with the C standard.  In GCC 3.0, an attempt was
-made to correct the behavior, so that the string was treated as a real
-string constant, but it turned out to be buggy.  In 3.1, the bugs have
-been fixed.  (We are not fixing the bugs in 3.0 because they affect
-relatively few people and the fix is quite invasive.)
-
-@end itemize
-
-@node Invocation
-@chapter Invocation
-@cindex invocation
-@cindex command line
-
-Most often when you use the C preprocessor you will not have to invoke it
-explicitly: the C compiler will do so automatically.  However, the
-preprocessor is sometimes useful on its own.  All the options listed
-here are also acceptable to the C compiler and have the same meaning,
-except that the C compiler has different rules for specifying the output
-file.
-
-@emph{Note:} Whether you use the preprocessor by way of @command{gcc}
-or @command{cpp}, the @dfn{compiler driver} is run first.  This
-program's purpose is to translate your command into invocations of the
-programs that do the actual work.  Their command-line interfaces are
-similar but not identical to the documented interface, and may change
-without notice.
-
-@ignore
-@c man begin SYNOPSIS
-cpp [@option{-D}@var{macro}[=@var{defn}]@dots{}] [@option{-U}@var{macro}]
-    [@option{-I}@var{dir}@dots{}] [@option{-iquote}@var{dir}@dots{}]
-    [@option{-W}@var{warn}@dots{}]
-    [@option{-M}|@option{-MM}] [@option{-MG}] [@option{-MF} @var{filename}]
-    [@option{-MP}] [@option{-MQ} @var{target}@dots{}]
-    [@option{-MT} @var{target}@dots{}]
-    [@option{-P}] [@option{-fno-working-directory}]
-    [@option{-x} @var{language}] [@option{-std=}@var{standard}]
-    @var{infile} @var{outfile}
-
-Only the most useful options are listed here; see below for the remainder.
-@c man end
-@c man begin SEEALSO
-gpl(7), gfdl(7), fsf-funding(7),
-gcc(1), as(1), ld(1), and the Info entries for @file{cpp}, @file{gcc}, and
-@file{binutils}.
-@c man end
-@end ignore
-
-@c man begin OPTIONS
-The C preprocessor expects two file names as arguments, @var{infile} and
-@var{outfile}.  The preprocessor reads @var{infile} together with any
-other files it specifies with @samp{#include}.  All the output generated
-by the combined input files is written in @var{outfile}.
-
-Either @var{infile} or @var{outfile} may be @option{-}, which as
-@var{infile} means to read from standard input and as @var{outfile}
-means to write to standard output.  Also, if either file is omitted, it
-means the same as if @option{-} had been specified for that file.
-
-Unless otherwise noted, or the option ends in @samp{=}, all options
-which take an argument may have that argument appear either immediately
-after the option, or with a space between option and argument:
-@option{-Ifoo} and @option{-I foo} have the same effect.
-
-@cindex grouping options
-@cindex options, grouping
-Many options have multi-letter names; therefore multiple single-letter
-options may @emph{not} be grouped: @option{-dM} is very different from
-@w{@samp{-d -M}}.
-
-@cindex options
-@include cppopts.texi
-@c man end
-
-@node Environment Variables
-@chapter Environment Variables
-@cindex environment variables
-@c man begin ENVIRONMENT
-
-This section describes the environment variables that affect how CPP
-operates.  You can use them to specify directories or prefixes to use
-when searching for include files, or to control dependency output.
-
-Note that you can also specify places to search using options such as
-@option{-I}, and control dependency output with options like
-@option{-M} (@pxref{Invocation}).  These take precedence over
-environment variables, which in turn take precedence over the
-configuration of GCC@.
-
-@include cppenv.texi
-@c man end
-
-@page
-@include fdl.texi
-
-@page
-@node Index of Directives
-@unnumbered Index of Directives
-@printindex fn
-
-@node Option Index
-@unnumbered Option Index
-@noindent
-CPP's command-line options and environment variables are indexed here
-without any initial @samp{-} or @samp{--}.
-@printindex op
-
-@page
-@node Concept Index
-@unnumbered Concept Index
-@printindex cp
-
-@bye
diff --git a/contrib/gcc-5.0/gcc/doc/cppenv.texi b/contrib/gcc-5.0/gcc/doc/cppenv.texi
deleted file mode 100644 (file)
index 100811d..0000000
+++ /dev/null
@@ -1,82 +0,0 @@
-@c Copyright (C) 1999-2015 Free Software Foundation, Inc.
-@c This is part of the CPP and GCC manuals.
-@c For copying conditions, see the file gcc.texi.
-
-@c ---------------------------------------------------------------------
-@c Environment variables affecting the preprocessor
-@c ---------------------------------------------------------------------
-
-@c If this file is included with the flag ``cppmanual'' set, it is
-@c formatted for inclusion in the CPP manual; otherwise the main GCC manual.
-
-@vtable @env
-@item CPATH
-@itemx C_INCLUDE_PATH
-@itemx CPLUS_INCLUDE_PATH
-@itemx OBJC_INCLUDE_PATH
-@c Commented out until ObjC++ is part of GCC:
-@c @itemx OBJCPLUS_INCLUDE_PATH
-Each variable's value is a list of directories separated by a special
-character, much like @env{PATH}, in which to look for header files.
-The special character, @code{PATH_SEPARATOR}, is target-dependent and
-determined at GCC build time.  For Microsoft Windows-based targets it is a
-semicolon, and for almost all other targets it is a colon.
-
-@env{CPATH} specifies a list of directories to be searched as if
-specified with @option{-I}, but after any paths given with @option{-I}
-options on the command line.  This environment variable is used
-regardless of which language is being preprocessed.
-
-The remaining environment variables apply only when preprocessing the
-particular language indicated.  Each specifies a list of directories
-to be searched as if specified with @option{-isystem}, but after any
-paths given with @option{-isystem} options on the command line.
-
-In all these variables, an empty element instructs the compiler to
-search its current working directory.  Empty elements can appear at the
-beginning or end of a path.  For instance, if the value of
-@env{CPATH} is @code{:/special/include}, that has the same
-effect as @samp{@w{-I. -I/special/include}}.
-
-@c man end
-@ifset cppmanual
-See also @ref{Search Path}.
-@end ifset
-@c man begin ENVIRONMENT
-
-@item DEPENDENCIES_OUTPUT
-@cindex dependencies for make as output
-If this variable is set, its value specifies how to output
-dependencies for Make based on the non-system header files processed
-by the compiler.  System header files are ignored in the dependency
-output.
-
-The value of @env{DEPENDENCIES_OUTPUT} can be just a file name, in
-which case the Make rules are written to that file, guessing the target
-name from the source file name.  Or the value can have the form
-@samp{@var{file} @var{target}}, in which case the rules are written to
-file @var{file} using @var{target} as the target name.
-
-In other words, this environment variable is equivalent to combining
-the options @option{-MM} and @option{-MF}
-@ifset cppmanual
-(@pxref{Invocation}),
-@end ifset
-@ifclear cppmanual
-(@pxref{Preprocessor Options}),
-@end ifclear
-with an optional @option{-MT} switch too.
-
-@item SUNPRO_DEPENDENCIES
-@cindex dependencies for make as output
-This variable is the same as @env{DEPENDENCIES_OUTPUT} (see above),
-except that system header files are not ignored, so it implies
-@option{-M} rather than @option{-MM}.  However, the dependence on the
-main input file is omitted.
-@ifset cppmanual
-@xref{Invocation}.
-@end ifset
-@ifclear cppmanual
-@xref{Preprocessor Options}.
-@end ifclear
-@end vtable
diff --git a/contrib/gcc-5.0/gcc/doc/cppinternals.texi b/contrib/gcc-5.0/gcc/doc/cppinternals.texi
deleted file mode 100644 (file)
index 29efa80..0000000
+++ /dev/null
@@ -1,1066 +0,0 @@
-\input texinfo
-@setfilename cppinternals.info
-@settitle The GNU C Preprocessor Internals
-
-@include gcc-common.texi
-
-@ifinfo
-@dircategory Software development
-@direntry
-* Cpplib: (cppinternals).      Cpplib internals.
-@end direntry
-@end ifinfo
-
-@c @smallbook
-@c @cropmarks
-@c @finalout
-@setchapternewpage odd
-@ifinfo
-This file documents the internals of the GNU C Preprocessor.
-
-Copyright (C) 2000-2015 Free Software Foundation, Inc.
-
-Permission is granted to make and distribute verbatim copies of
-this manual provided the copyright notice and this permission notice
-are preserved on all copies.
-
-@ignore
-Permission is granted to process this file through Tex and print the
-results, provided the printed document carries copying permission
-notice identical to this one except for the removal of this paragraph
-(this paragraph not being relevant to the printed manual).
-
-@end ignore
-Permission is granted to copy and distribute modified versions of this
-manual under the conditions for verbatim copying, provided also that
-the entire resulting derived work is distributed under the terms of a
-permission notice identical to this one.
-
-Permission is granted to copy and distribute translations of this manual
-into another language, under the above conditions for modified versions.
-@end ifinfo
-
-@titlepage
-@title Cpplib Internals
-@versionsubtitle
-@author Neil Booth
-@page
-@vskip 0pt plus 1filll
-@c man begin COPYRIGHT
-Copyright @copyright{} 2000-2015 Free Software Foundation, Inc.
-
-Permission is granted to make and distribute verbatim copies of
-this manual provided the copyright notice and this permission notice
-are preserved on all copies.
-
-Permission is granted to copy and distribute modified versions of this
-manual under the conditions for verbatim copying, provided also that
-the entire resulting derived work is distributed under the terms of a
-permission notice identical to this one.
-
-Permission is granted to copy and distribute translations of this manual
-into another language, under the above conditions for modified versions.
-@c man end
-@end titlepage
-@contents
-@page
-
-@ifnottex
-@node Top
-@top
-@chapter Cpplib---the GNU C Preprocessor
-
-The GNU C preprocessor is
-implemented as a library, @dfn{cpplib}, so it can be easily shared between
-a stand-alone preprocessor, and a preprocessor integrated with the C,
-C++ and Objective-C front ends.  It is also available for use by other
-programs, though this is not recommended as its exposed interface has
-not yet reached a point of reasonable stability.
-
-The library has been written to be re-entrant, so that it can be used
-to preprocess many files simultaneously if necessary.  It has also been
-written with the preprocessing token as the fundamental unit; the
-preprocessor in previous versions of GCC would operate on text strings
-as the fundamental unit.
-
-This brief manual documents the internals of cpplib, and explains some
-of the tricky issues.  It is intended that, along with the comments in
-the source code, a reasonably competent C programmer should be able to
-figure out what the code is doing, and why things have been implemented
-the way they have.
-
-@menu
-* Conventions::         Conventions used in the code.
-* Lexer::               The combined C, C++ and Objective-C Lexer.
-* Hash Nodes::          All identifiers are entered into a hash table.
-* Macro Expansion::     Macro expansion algorithm.
-* Token Spacing::       Spacing and paste avoidance issues.
-* Line Numbering::      Tracking location within files.
-* Guard Macros::        Optimizing header files with guard macros.
-* Files::               File handling.
-* Concept Index::       Index.
-@end menu
-@end ifnottex
-
-@node Conventions
-@unnumbered Conventions
-@cindex interface
-@cindex header files
-
-cpplib has two interfaces---one is exposed internally only, and the
-other is for both internal and external use.
-
-The convention is that functions and types that are exposed to multiple
-files internally are prefixed with @samp{_cpp_}, and are to be found in
-the file @file{internal.h}.  Functions and types exposed to external
-clients are in @file{cpplib.h}, and prefixed with @samp{cpp_}.  For
-historical reasons this is no longer quite true, but we should strive to
-stick to it.
-
-We are striving to reduce the information exposed in @file{cpplib.h} to the
-bare minimum necessary, and then to keep it there.  This makes clear
-exactly what external clients are entitled to assume, and allows us to
-change internals in the future without worrying whether library clients
-are perhaps relying on some kind of undocumented implementation-specific
-behavior.
-
-@node Lexer
-@unnumbered The Lexer
-@cindex lexer
-@cindex newlines
-@cindex escaped newlines
-
-@section Overview
-The lexer is contained in the file @file{lex.c}.  It is a hand-coded
-lexer, and not implemented as a state machine.  It can understand C, C++
-and Objective-C source code, and has been extended to allow reasonably
-successful preprocessing of assembly language.  The lexer does not make
-an initial pass to strip out trigraphs and escaped newlines, but handles
-them as they are encountered in a single pass of the input file.  It
-returns preprocessing tokens individually, not a line at a time.
-
-It is mostly transparent to users of the library, since the library's
-interface for obtaining the next token, @code{cpp_get_token}, takes care
-of lexing new tokens, handling directives, and expanding macros as
-necessary.  However, the lexer does expose some functionality so that
-clients of the library can easily spell a given token, such as
-@code{cpp_spell_token} and @code{cpp_token_len}.  These functions are
-useful when generating diagnostics, and for emitting the preprocessed
-output.
-
-@section Lexing a token
-Lexing of an individual token is handled by @code{_cpp_lex_direct} and
-its subroutines.  In its current form the code is quite complicated,
-with read ahead characters and such-like, since it strives to not step
-back in the character stream in preparation for handling non-ASCII file
-encodings.  The current plan is to convert any such files to UTF-8
-before processing them.  This complexity is therefore unnecessary and
-will be removed, so I'll not discuss it further here.
-
-The job of @code{_cpp_lex_direct} is simply to lex a token.  It is not
-responsible for issues like directive handling, returning lookahead
-tokens directly, multiple-include optimization, or conditional block
-skipping.  It necessarily has a minor r@^ole to play in memory
-management of lexed lines.  I discuss these issues in a separate section
-(@pxref{Lexing a line}).
-
-The lexer places the token it lexes into storage pointed to by the
-variable @code{cur_token}, and then increments it.  This variable is
-important for correct diagnostic positioning.  Unless a specific line
-and column are passed to the diagnostic routines, they will examine the
-@code{line} and @code{col} values of the token just before the location
-that @code{cur_token} points to, and use that location to report the
-diagnostic.
-
-The lexer does not consider whitespace to be a token in its own right.
-If whitespace (other than a new line) precedes a token, it sets the
-@code{PREV_WHITE} bit in the token's flags.  Each token has its
-@code{line} and @code{col} variables set to the line and column of the
-first character of the token.  This line number is the line number in
-the translation unit, and can be converted to a source (file, line) pair
-using the line map code.
-
-The first token on a logical, i.e.@: unescaped, line has the flag
-@code{BOL} set for beginning-of-line.  This flag is intended for
-internal use, both to distinguish a @samp{#} that begins a directive
-from one that doesn't, and to generate a call-back to clients that want
-to be notified about the start of every non-directive line with tokens
-on it.  Clients cannot reliably determine this for themselves: the first
-token might be a macro, and the tokens of a macro expansion do not have
-the @code{BOL} flag set.  The macro expansion may even be empty, and the
-next token on the line certainly won't have the @code{BOL} flag set.
-
-New lines are treated specially; exactly how the lexer handles them is
-context-dependent.  The C standard mandates that directives are
-terminated by the first unescaped newline character, even if it appears
-in the middle of a macro expansion.  Therefore, if the state variable
-@code{in_directive} is set, the lexer returns a @code{CPP_EOF} token,
-which is normally used to indicate end-of-file, to indicate
-end-of-directive.  In a directive a @code{CPP_EOF} token never means
-end-of-file.  Conveniently, if the caller was @code{collect_args}, it
-already handles @code{CPP_EOF} as if it were end-of-file, and reports an
-error about an unterminated macro argument list.
-
-The C standard also specifies that a new line in the middle of the
-arguments to a macro is treated as whitespace.  This white space is
-important in case the macro argument is stringified.  The state variable
-@code{parsing_args} is nonzero when the preprocessor is collecting the
-arguments to a macro call.  It is set to 1 when looking for the opening
-parenthesis to a function-like macro, and 2 when collecting the actual
-arguments up to the closing parenthesis, since these two cases need to
-be distinguished sometimes.  One such time is here: the lexer sets the
-@code{PREV_WHITE} flag of a token if it meets a new line when
-@code{parsing_args} is set to 2.  It doesn't set it if it meets a new
-line when @code{parsing_args} is 1, since then code like
-
-@smallexample
-#define foo() bar
-foo
-baz
-@end smallexample
-
-@noindent would be output with an erroneous space before @samp{baz}:
-
-@smallexample
-foo
- baz
-@end smallexample
-
-This is a good example of the subtlety of getting token spacing correct
-in the preprocessor; there are plenty of tests in the testsuite for
-corner cases like this.
-
-The lexer is written to treat each of @samp{\r}, @samp{\n}, @samp{\r\n}
-and @samp{\n\r} as a single new line indicator.  This allows it to
-transparently preprocess MS-DOS, Macintosh and Unix files without their
-needing to pass through a special filter beforehand.
-
-We also decided to treat a backslash, either @samp{\} or the trigraph
-@samp{??/}, separated from one of the above newline indicators by
-non-comment whitespace only, as intending to escape the newline.  It
-tends to be a typing mistake, and cannot reasonably be mistaken for
-anything else in any of the C-family grammars.  Since handling it this
-way is not strictly conforming to the ISO standard, the library issues a
-warning wherever it encounters it.
-
-Handling newlines like this is made simpler by doing it in one place
-only.  The function @code{handle_newline} takes care of all newline
-characters, and @code{skip_escaped_newlines} takes care of arbitrarily
-long sequences of escaped newlines, deferring to @code{handle_newline}
-to handle the newlines themselves.
-
-The most painful aspect of lexing ISO-standard C and C++ is handling
-trigraphs and backlash-escaped newlines.  Trigraphs are processed before
-any interpretation of the meaning of a character is made, and unfortunately
-there is a trigraph representation for a backslash, so it is possible for
-the trigraph @samp{??/} to introduce an escaped newline.
-
-Escaped newlines are tedious because theoretically they can occur
-anywhere---between the @samp{+} and @samp{=} of the @samp{+=} token,
-within the characters of an identifier, and even between the @samp{*}
-and @samp{/} that terminates a comment.  Moreover, you cannot be sure
-there is just one---there might be an arbitrarily long sequence of them.
-
-So, for example, the routine that lexes a number, @code{parse_number},
-cannot assume that it can scan forwards until the first non-number
-character and be done with it, because this could be the @samp{\}
-introducing an escaped newline, or the @samp{?} introducing the trigraph
-sequence that represents the @samp{\} of an escaped newline.  If it
-encounters a @samp{?} or @samp{\}, it calls @code{skip_escaped_newlines}
-to skip over any potential escaped newlines before checking whether the
-number has been finished.
-
-Similarly code in the main body of @code{_cpp_lex_direct} cannot simply
-check for a @samp{=} after a @samp{+} character to determine whether it
-has a @samp{+=} token; it needs to be prepared for an escaped newline of
-some sort.  Such cases use the function @code{get_effective_char}, which
-returns the first character after any intervening escaped newlines.
-
-The lexer needs to keep track of the correct column position, including
-counting tabs as specified by the @option{-ftabstop=} option.  This
-should be done even within C-style comments; they can appear in the
-middle of a line, and we want to report diagnostics in the correct
-position for text appearing after the end of the comment.
-
-@anchor{Invalid identifiers}
-Some identifiers, such as @code{__VA_ARGS__} and poisoned identifiers,
-may be invalid and require a diagnostic.  However, if they appear in a
-macro expansion we don't want to complain with each use of the macro.
-It is therefore best to catch them during the lexing stage, in
-@code{parse_identifier}.  In both cases, whether a diagnostic is needed
-or not is dependent upon the lexer's state.  For example, we don't want
-to issue a diagnostic for re-poisoning a poisoned identifier, or for
-using @code{__VA_ARGS__} in the expansion of a variable-argument macro.
-Therefore @code{parse_identifier} makes use of state flags to determine
-whether a diagnostic is appropriate.  Since we change state on a
-per-token basis, and don't lex whole lines at a time, this is not a
-problem.
-
-Another place where state flags are used to change behavior is whilst
-lexing header names.  Normally, a @samp{<} would be lexed as a single
-token.  After a @code{#include} directive, though, it should be lexed as
-a single token as far as the nearest @samp{>} character.  Note that we
-don't allow the terminators of header names to be escaped; the first
-@samp{"} or @samp{>} terminates the header name.
-
-Interpretation of some character sequences depends upon whether we are
-lexing C, C++ or Objective-C, and on the revision of the standard in
-force.  For example, @samp{::} is a single token in C++, but in C it is
-two separate @samp{:} tokens and almost certainly a syntax error.  Such
-cases are handled by @code{_cpp_lex_direct} based upon command-line
-flags stored in the @code{cpp_options} structure.
-
-Once a token has been lexed, it leads an independent existence.  The
-spelling of numbers, identifiers and strings is copied to permanent
-storage from the original input buffer, so a token remains valid and
-correct even if its source buffer is freed with @code{_cpp_pop_buffer}.
-The storage holding the spellings of such tokens remains until the
-client program calls cpp_destroy, probably at the end of the translation
-unit.
-
-@anchor{Lexing a line}
-@section Lexing a line
-@cindex token run
-
-When the preprocessor was changed to return pointers to tokens, one
-feature I wanted was some sort of guarantee regarding how long a
-returned pointer remains valid.  This is important to the stand-alone
-preprocessor, the future direction of the C family front ends, and even
-to cpplib itself internally.
-
-Occasionally the preprocessor wants to be able to peek ahead in the
-token stream.  For example, after the name of a function-like macro, it
-wants to check the next token to see if it is an opening parenthesis.
-Another example is that, after reading the first few tokens of a
-@code{#pragma} directive and not recognizing it as a registered pragma,
-it wants to backtrack and allow the user-defined handler for unknown
-pragmas to access the full @code{#pragma} token stream.  The stand-alone
-preprocessor wants to be able to test the current token with the
-previous one to see if a space needs to be inserted to preserve their
-separate tokenization upon re-lexing (paste avoidance), so it needs to
-be sure the pointer to the previous token is still valid.  The
-recursive-descent C++ parser wants to be able to perform tentative
-parsing arbitrarily far ahead in the token stream, and then to be able
-to jump back to a prior position in that stream if necessary.
-
-The rule I chose, which is fairly natural, is to arrange that the
-preprocessor lex all tokens on a line consecutively into a token buffer,
-which I call a @dfn{token run}, and when meeting an unescaped new line
-(newlines within comments do not count either), to start lexing back at
-the beginning of the run.  Note that we do @emph{not} lex a line of
-tokens at once; if we did that @code{parse_identifier} would not have
-state flags available to warn about invalid identifiers (@pxref{Invalid
-identifiers}).
-
-In other words, accessing tokens that appeared earlier in the current
-line is valid, but since each logical line overwrites the tokens of the
-previous line, tokens from prior lines are unavailable.  In particular,
-since a directive only occupies a single logical line, this means that
-the directive handlers like the @code{#pragma} handler can jump around
-in the directive's tokens if necessary.
-
-Two issues remain: what about tokens that arise from macro expansions,
-and what happens when we have a long line that overflows the token run?
-
-Since we promise clients that we preserve the validity of pointers that
-we have already returned for tokens that appeared earlier in the line,
-we cannot reallocate the run.  Instead, on overflow it is expanded by
-chaining a new token run on to the end of the existing one.
-
-The tokens forming a macro's replacement list are collected by the
-@code{#define} handler, and placed in storage that is only freed by
-@code{cpp_destroy}.  So if a macro is expanded in the line of tokens,
-the pointers to the tokens of its expansion that are returned will always
-remain valid.  However, macros are a little trickier than that, since
-they give rise to three sources of fresh tokens.  They are the built-in
-macros like @code{__LINE__}, and the @samp{#} and @samp{##} operators
-for stringification and token pasting.  I handled this by allocating
-space for these tokens from the lexer's token run chain.  This means
-they automatically receive the same lifetime guarantees as lexed tokens,
-and we don't need to concern ourselves with freeing them.
-
-Lexing into a line of tokens solves some of the token memory management
-issues, but not all.  The opening parenthesis after a function-like
-macro name might lie on a different line, and the front ends definitely
-want the ability to look ahead past the end of the current line.  So
-cpplib only moves back to the start of the token run at the end of a
-line if the variable @code{keep_tokens} is zero.  Line-buffering is
-quite natural for the preprocessor, and as a result the only time cpplib
-needs to increment this variable is whilst looking for the opening
-parenthesis to, and reading the arguments of, a function-like macro.  In
-the near future cpplib will export an interface to increment and
-decrement this variable, so that clients can share full control over the
-lifetime of token pointers too.
-
-The routine @code{_cpp_lex_token} handles moving to new token runs,
-calling @code{_cpp_lex_direct} to lex new tokens, or returning
-previously-lexed tokens if we stepped back in the token stream.  It also
-checks each token for the @code{BOL} flag, which might indicate a
-directive that needs to be handled, or require a start-of-line call-back
-to be made.  @code{_cpp_lex_token} also handles skipping over tokens in
-failed conditional blocks, and invalidates the control macro of the
-multiple-include optimization if a token was successfully lexed outside
-a directive.  In other words, its callers do not need to concern
-themselves with such issues.
-
-@node Hash Nodes
-@unnumbered Hash Nodes
-@cindex hash table
-@cindex identifiers
-@cindex macros
-@cindex assertions
-@cindex named operators
-
-When cpplib encounters an ``identifier'', it generates a hash code for
-it and stores it in the hash table.  By ``identifier'' we mean tokens
-with type @code{CPP_NAME}; this includes identifiers in the usual C
-sense, as well as keywords, directive names, macro names and so on.  For
-example, all of @code{pragma}, @code{int}, @code{foo} and
-@code{__GNUC__} are identifiers and hashed when lexed.
-
-Each node in the hash table contain various information about the
-identifier it represents.  For example, its length and type.  At any one
-time, each identifier falls into exactly one of three categories:
-
-@itemize @bullet
-@item Macros
-
-These have been declared to be macros, either on the command line or
-with @code{#define}.  A few, such as @code{__TIME__} are built-ins
-entered in the hash table during initialization.  The hash node for a
-normal macro points to a structure with more information about the
-macro, such as whether it is function-like, how many arguments it takes,
-and its expansion.  Built-in macros are flagged as special, and instead
-contain an enum indicating which of the various built-in macros it is.
-
-@item Assertions
-
-Assertions are in a separate namespace to macros.  To enforce this, cpp
-actually prepends a @code{#} character before hashing and entering it in
-the hash table.  An assertion's node points to a chain of answers to
-that assertion.
-
-@item Void
-
-Everything else falls into this category---an identifier that is not
-currently a macro, or a macro that has since been undefined with
-@code{#undef}.
-
-When preprocessing C++, this category also includes the named operators,
-such as @code{xor}.  In expressions these behave like the operators they
-represent, but in contexts where the spelling of a token matters they
-are spelt differently.  This spelling distinction is relevant when they
-are operands of the stringizing and pasting macro operators @code{#} and
-@code{##}.  Named operator hash nodes are flagged, both to catch the
-spelling distinction and to prevent them from being defined as macros.
-@end itemize
-
-The same identifiers share the same hash node.  Since each identifier
-token, after lexing, contains a pointer to its hash node, this is used
-to provide rapid lookup of various information.  For example, when
-parsing a @code{#define} statement, CPP flags each argument's identifier
-hash node with the index of that argument.  This makes duplicated
-argument checking an O(1) operation for each argument.  Similarly, for
-each identifier in the macro's expansion, lookup to see if it is an
-argument, and which argument it is, is also an O(1) operation.  Further,
-each directive name, such as @code{endif}, has an associated directive
-enum stored in its hash node, so that directive lookup is also O(1).
-
-@node Macro Expansion
-@unnumbered Macro Expansion Algorithm
-@cindex macro expansion
-
-Macro expansion is a tricky operation, fraught with nasty corner cases
-and situations that render what you thought was a nifty way to
-optimize the preprocessor's expansion algorithm wrong in quite subtle
-ways.
-
-I strongly recommend you have a good grasp of how the C and C++
-standards require macros to be expanded before diving into this
-section, let alone the code!.  If you don't have a clear mental
-picture of how things like nested macro expansion, stringification and
-token pasting are supposed to work, damage to your sanity can quickly
-result.
-
-@section Internal representation of macros
-@cindex macro representation (internal)
-
-The preprocessor stores macro expansions in tokenized form.  This
-saves repeated lexing passes during expansion, at the cost of a small
-increase in memory consumption on average.  The tokens are stored
-contiguously in memory, so a pointer to the first one and a token
-count is all you need to get the replacement list of a macro.
-
-If the macro is a function-like macro the preprocessor also stores its
-parameters, in the form of an ordered list of pointers to the hash
-table entry of each parameter's identifier.  Further, in the macro's
-stored expansion each occurrence of a parameter is replaced with a
-special token of type @code{CPP_MACRO_ARG}.  Each such token holds the
-index of the parameter it represents in the parameter list, which
-allows rapid replacement of parameters with their arguments during
-expansion.  Despite this optimization it is still necessary to store
-the original parameters to the macro, both for dumping with e.g.,
-@option{-dD}, and to warn about non-trivial macro redefinitions when
-the parameter names have changed.
-
-@section Macro expansion overview
-The preprocessor maintains a @dfn{context stack}, implemented as a
-linked list of @code{cpp_context} structures, which together represent
-the macro expansion state at any one time.  The @code{struct
-cpp_reader} member variable @code{context} points to the current top
-of this stack.  The top normally holds the unexpanded replacement list
-of the innermost macro under expansion, except when cpplib is about to
-pre-expand an argument, in which case it holds that argument's
-unexpanded tokens.
-
-When there are no macros under expansion, cpplib is in @dfn{base
-context}.  All contexts other than the base context contain a
-contiguous list of tokens delimited by a starting and ending token.
-When not in base context, cpplib obtains the next token from the list
-of the top context.  If there are no tokens left in the list, it pops
-that context off the stack, and subsequent ones if necessary, until an
-unexhausted context is found or it returns to base context.  In base
-context, cpplib reads tokens directly from the lexer.
-
-If it encounters an identifier that is both a macro and enabled for
-expansion, cpplib prepares to push a new context for that macro on the
-stack by calling the routine @code{enter_macro_context}.  When this
-routine returns, the new context will contain the unexpanded tokens of
-the replacement list of that macro.  In the case of function-like
-macros, @code{enter_macro_context} also replaces any parameters in the
-replacement list, stored as @code{CPP_MACRO_ARG} tokens, with the
-appropriate macro argument.  If the standard requires that the
-parameter be replaced with its expanded argument, the argument will
-have been fully macro expanded first.
-
-@code{enter_macro_context} also handles special macros like
-@code{__LINE__}.  Although these macros expand to a single token which
-cannot contain any further macros, for reasons of token spacing
-(@pxref{Token Spacing}) and simplicity of implementation, cpplib
-handles these special macros by pushing a context containing just that
-one token.
-
-The final thing that @code{enter_macro_context} does before returning
-is to mark the macro disabled for expansion (except for special macros
-like @code{__TIME__}).  The macro is re-enabled when its context is
-later popped from the context stack, as described above.  This strict
-ordering ensures that a macro is disabled whilst its expansion is
-being scanned, but that it is @emph{not} disabled whilst any arguments
-to it are being expanded.
-
-@section Scanning the replacement list for macros to expand
-The C standard states that, after any parameters have been replaced
-with their possibly-expanded arguments, the replacement list is
-scanned for nested macros.  Further, any identifiers in the
-replacement list that are not expanded during this scan are never
-again eligible for expansion in the future, if the reason they were
-not expanded is that the macro in question was disabled.
-
-Clearly this latter condition can only apply to tokens resulting from
-argument pre-expansion.  Other tokens never have an opportunity to be
-re-tested for expansion.  It is possible for identifiers that are
-function-like macros to not expand initially but to expand during a
-later scan.  This occurs when the identifier is the last token of an
-argument (and therefore originally followed by a comma or a closing
-parenthesis in its macro's argument list), and when it replaces its
-parameter in the macro's replacement list, the subsequent token
-happens to be an opening parenthesis (itself possibly the first token
-of an argument).
-
-It is important to note that when cpplib reads the last token of a
-given context, that context still remains on the stack.  Only when
-looking for the @emph{next} token do we pop it off the stack and drop
-to a lower context.  This makes backing up by one token easy, but more
-importantly ensures that the macro corresponding to the current
-context is still disabled when we are considering the last token of
-its replacement list for expansion (or indeed expanding it).  As an
-example, which illustrates many of the points above, consider
-
-@smallexample
-#define foo(x) bar x
-foo(foo) (2)
-@end smallexample
-
-@noindent which fully expands to @samp{bar foo (2)}.  During pre-expansion
-of the argument, @samp{foo} does not expand even though the macro is
-enabled, since it has no following parenthesis [pre-expansion of an
-argument only uses tokens from that argument; it cannot take tokens
-from whatever follows the macro invocation].  This still leaves the
-argument token @samp{foo} eligible for future expansion.  Then, when
-re-scanning after argument replacement, the token @samp{foo} is
-rejected for expansion, and marked ineligible for future expansion,
-since the macro is now disabled.  It is disabled because the
-replacement list @samp{bar foo} of the macro is still on the context
-stack.
-
-If instead the algorithm looked for an opening parenthesis first and
-then tested whether the macro were disabled it would be subtly wrong.
-In the example above, the replacement list of @samp{foo} would be
-popped in the process of finding the parenthesis, re-enabling
-@samp{foo} and expanding it a second time.
-
-@section Looking for a function-like macro's opening parenthesis
-Function-like macros only expand when immediately followed by a
-parenthesis.  To do this cpplib needs to temporarily disable macros
-and read the next token.  Unfortunately, because of spacing issues
-(@pxref{Token Spacing}), there can be fake padding tokens in-between,
-and if the next real token is not a parenthesis cpplib needs to be
-able to back up that one token as well as retain the information in
-any intervening padding tokens.
-
-Backing up more than one token when macros are involved is not
-permitted by cpplib, because in general it might involve issues like
-restoring popped contexts onto the context stack, which are too hard.
-Instead, searching for the parenthesis is handled by a special
-function, @code{funlike_invocation_p}, which remembers padding
-information as it reads tokens.  If the next real token is not an
-opening parenthesis, it backs up that one token, and then pushes an
-extra context just containing the padding information if necessary.
-
-@section Marking tokens ineligible for future expansion
-As discussed above, cpplib needs a way of marking tokens as
-unexpandable.  Since the tokens cpplib handles are read-only once they
-have been lexed, it instead makes a copy of the token and adds the
-flag @code{NO_EXPAND} to the copy.
-
-For efficiency and to simplify memory management by avoiding having to
-remember to free these tokens, they are allocated as temporary tokens
-from the lexer's current token run (@pxref{Lexing a line}) using the
-function @code{_cpp_temp_token}.  The tokens are then re-used once the
-current line of tokens has been read in.
-
-This might sound unsafe.  However, tokens runs are not re-used at the
-end of a line if it happens to be in the middle of a macro argument
-list, and cpplib only wants to back-up more than one lexer token in
-situations where no macro expansion is involved, so the optimization
-is safe.
-
-@node Token Spacing
-@unnumbered Token Spacing
-@cindex paste avoidance
-@cindex spacing
-@cindex token spacing
-
-First, consider an issue that only concerns the stand-alone
-preprocessor: there needs to be a guarantee that re-reading its preprocessed
-output results in an identical token stream.  Without taking special
-measures, this might not be the case because of macro substitution.
-For example:
-
-@smallexample
-#define PLUS +
-#define EMPTY
-#define f(x) =x=
-+PLUS -EMPTY- PLUS+ f(=)
-        @expansion{} + + - - + + = = =
-@emph{not}
-        @expansion{} ++ -- ++ ===
-@end smallexample
-
-One solution would be to simply insert a space between all adjacent
-tokens.  However, we would like to keep space insertion to a minimum,
-both for aesthetic reasons and because it causes problems for people who
-still try to abuse the preprocessor for things like Fortran source and
-Makefiles.
-
-For now, just notice that when tokens are added (or removed, as shown by
-the @code{EMPTY} example) from the original lexed token stream, we need
-to check for accidental token pasting.  We call this @dfn{paste
-avoidance}.  Token addition and removal can only occur because of macro
-expansion, but accidental pasting can occur in many places: both before
-and after each macro replacement, each argument replacement, and
-additionally each token created by the @samp{#} and @samp{##} operators.
-
-Look at how the preprocessor gets whitespace output correct
-normally.  The @code{cpp_token} structure contains a flags byte, and one
-of those flags is @code{PREV_WHITE}.  This is flagged by the lexer, and
-indicates that the token was preceded by whitespace of some form other
-than a new line.  The stand-alone preprocessor can use this flag to
-decide whether to insert a space between tokens in the output.
-
-Now consider the result of the following macro expansion:
-
-@smallexample
-#define add(x, y, z) x + y +z;
-sum = add (1,2, 3);
-        @expansion{} sum = 1 + 2 +3;
-@end smallexample
-
-The interesting thing here is that the tokens @samp{1} and @samp{2} are
-output with a preceding space, and @samp{3} is output without a
-preceding space, but when lexed none of these tokens had that property.
-Careful consideration reveals that @samp{1} gets its preceding
-whitespace from the space preceding @samp{add} in the macro invocation,
-@emph{not} replacement list.  @samp{2} gets its whitespace from the
-space preceding the parameter @samp{y} in the macro replacement list,
-and @samp{3} has no preceding space because parameter @samp{z} has none
-in the replacement list.
-
-Once lexed, tokens are effectively fixed and cannot be altered, since
-pointers to them might be held in many places, in particular by
-in-progress macro expansions.  So instead of modifying the two tokens
-above, the preprocessor inserts a special token, which I call a
-@dfn{padding token}, into the token stream to indicate that spacing of
-the subsequent token is special.  The preprocessor inserts padding
-tokens in front of every macro expansion and expanded macro argument.
-These point to a @dfn{source token} from which the subsequent real token
-should inherit its spacing.  In the above example, the source tokens are
-@samp{add} in the macro invocation, and @samp{y} and @samp{z} in the
-macro replacement list, respectively.
-
-It is quite easy to get multiple padding tokens in a row, for example if
-a macro's first replacement token expands straight into another macro.
-
-@smallexample
-#define foo bar
-#define bar baz
-[foo]
-        @expansion{} [baz]
-@end smallexample
-
-Here, two padding tokens are generated with sources the @samp{foo} token
-between the brackets, and the @samp{bar} token from foo's replacement
-list, respectively.  Clearly the first padding token is the one to
-use, so the output code should contain a rule that the first
-padding token in a sequence is the one that matters.
-
-But what if a macro expansion is left?  Adjusting the above
-example slightly:
-
-@smallexample
-#define foo bar
-#define bar EMPTY baz
-#define EMPTY
-[foo] EMPTY;
-        @expansion{} [ baz] ;
-@end smallexample
-
-As shown, now there should be a space before @samp{baz} and the
-semicolon in the output.
-
-The rules we decided above fail for @samp{baz}: we generate three
-padding tokens, one per macro invocation, before the token @samp{baz}.
-We would then have it take its spacing from the first of these, which
-carries source token @samp{foo} with no leading space.
-
-It is vital that cpplib get spacing correct in these examples since any
-of these macro expansions could be stringified, where spacing matters.
-
-So, this demonstrates that not just entering macro and argument
-expansions, but leaving them requires special handling too.  I made
-cpplib insert a padding token with a @code{NULL} source token when
-leaving macro expansions, as well as after each replaced argument in a
-macro's replacement list.  It also inserts appropriate padding tokens on
-either side of tokens created by the @samp{#} and @samp{##} operators.
-I expanded the rule so that, if we see a padding token with a
-@code{NULL} source token, @emph{and} that source token has no leading
-space, then we behave as if we have seen no padding tokens at all.  A
-quick check shows this rule will then get the above example correct as
-well.
-
-Now a relationship with paste avoidance is apparent: we have to be
-careful about paste avoidance in exactly the same locations we have
-padding tokens in order to get white space correct.  This makes
-implementation of paste avoidance easy: wherever the stand-alone
-preprocessor is fixing up spacing because of padding tokens, and it
-turns out that no space is needed, it has to take the extra step to
-check that a space is not needed after all to avoid an accidental paste.
-The function @code{cpp_avoid_paste} advises whether a space is required
-between two consecutive tokens.  To avoid excessive spacing, it tries
-hard to only require a space if one is likely to be necessary, but for
-reasons of efficiency it is slightly conservative and might recommend a
-space where one is not strictly needed.
-
-@node Line Numbering
-@unnumbered Line numbering
-@cindex line numbers
-
-@section Just which line number anyway?
-
-There are three reasonable requirements a cpplib client might have for
-the line number of a token passed to it:
-
-@itemize @bullet
-@item
-The source line it was lexed on.
-@item
-The line it is output on.  This can be different to the line it was
-lexed on if, for example, there are intervening escaped newlines or
-C-style comments.  For example:
-
-@smallexample
-foo /* @r{A long
-comment} */ bar \
-baz
-@result{}
-foo bar baz
-@end smallexample
-
-@item
-If the token results from a macro expansion, the line of the macro name,
-or possibly the line of the closing parenthesis in the case of
-function-like macro expansion.
-@end itemize
-
-The @code{cpp_token} structure contains @code{line} and @code{col}
-members.  The lexer fills these in with the line and column of the first
-character of the token.  Consequently, but maybe unexpectedly, a token
-from the replacement list of a macro expansion carries the location of
-the token within the @code{#define} directive, because cpplib expands a
-macro by returning pointers to the tokens in its replacement list.  The
-current implementation of cpplib assigns tokens created from built-in
-macros and the @samp{#} and @samp{##} operators the location of the most
-recently lexed token.  This is a because they are allocated from the
-lexer's token runs, and because of the way the diagnostic routines infer
-the appropriate location to report.
-
-The diagnostic routines in cpplib display the location of the most
-recently @emph{lexed} token, unless they are passed a specific line and
-column to report.  For diagnostics regarding tokens that arise from
-macro expansions, it might also be helpful for the user to see the
-original location in the macro definition that the token came from.
-Since that is exactly the information each token carries, such an
-enhancement could be made relatively easily in future.
-
-The stand-alone preprocessor faces a similar problem when determining
-the correct line to output the token on: the position attached to a
-token is fairly useless if the token came from a macro expansion.  All
-tokens on a logical line should be output on its first physical line, so
-the token's reported location is also wrong if it is part of a physical
-line other than the first.
-
-To solve these issues, cpplib provides a callback that is generated
-whenever it lexes a preprocessing token that starts a new logical line
-other than a directive.  It passes this token (which may be a
-@code{CPP_EOF} token indicating the end of the translation unit) to the
-callback routine, which can then use the line and column of this token
-to produce correct output.
-
-@section Representation of line numbers
-
-As mentioned above, cpplib stores with each token the line number that
-it was lexed on.  In fact, this number is not the number of the line in
-the source file, but instead bears more resemblance to the number of the
-line in the translation unit.
-
-The preprocessor maintains a monotonic increasing line count, which is
-incremented at every new line character (and also at the end of any
-buffer that does not end in a new line).  Since a line number of zero is
-useful to indicate certain special states and conditions, this variable
-starts counting from one.
-
-This variable therefore uniquely enumerates each line in the translation
-unit.  With some simple infrastructure, it is straight forward to map
-from this to the original source file and line number pair, saving space
-whenever line number information needs to be saved.  The code the
-implements this mapping lies in the files @file{line-map.c} and
-@file{line-map.h}.
-
-Command-line macros and assertions are implemented by pushing a buffer
-containing the right hand side of an equivalent @code{#define} or
-@code{#assert} directive.  Some built-in macros are handled similarly.
-Since these are all processed before the first line of the main input
-file, it will typically have an assigned line closer to twenty than to
-one.
-
-@node Guard Macros
-@unnumbered The Multiple-Include Optimization
-@cindex guard macros
-@cindex controlling macros
-@cindex multiple-include optimization
-
-Header files are often of the form
-
-@smallexample
-#ifndef FOO
-#define FOO
-@dots{}
-#endif
-@end smallexample
-
-@noindent
-to prevent the compiler from processing them more than once.  The
-preprocessor notices such header files, so that if the header file
-appears in a subsequent @code{#include} directive and @code{FOO} is
-defined, then it is ignored and it doesn't preprocess or even re-open
-the file a second time.  This is referred to as the @dfn{multiple
-include optimization}.
-
-Under what circumstances is such an optimization valid?  If the file
-were included a second time, it can only be optimized away if that
-inclusion would result in no tokens to return, and no relevant
-directives to process.  Therefore the current implementation imposes
-requirements and makes some allowances as follows:
-
-@enumerate
-@item
-There must be no tokens outside the controlling @code{#if}-@code{#endif}
-pair, but whitespace and comments are permitted.
-
-@item
-There must be no directives outside the controlling directive pair, but
-the @dfn{null directive} (a line containing nothing other than a single
-@samp{#} and possibly whitespace) is permitted.
-
-@item
-The opening directive must be of the form
-
-@smallexample
-#ifndef FOO
-@end smallexample
-
-or
-
-@smallexample
-#if !defined FOO     [equivalently, #if !defined(FOO)]
-@end smallexample
-
-@item
-In the second form above, the tokens forming the @code{#if} expression
-must have come directly from the source file---no macro expansion must
-have been involved.  This is because macro definitions can change, and
-tracking whether or not a relevant change has been made is not worth the
-implementation cost.
-
-@item
-There can be no @code{#else} or @code{#elif} directives at the outer
-conditional block level, because they would probably contain something
-of interest to a subsequent pass.
-@end enumerate
-
-First, when pushing a new file on the buffer stack,
-@code{_stack_include_file} sets the controlling macro @code{mi_cmacro} to
-@code{NULL}, and sets @code{mi_valid} to @code{true}.  This indicates
-that the preprocessor has not yet encountered anything that would
-invalidate the multiple-include optimization.  As described in the next
-few paragraphs, these two variables having these values effectively
-indicates top-of-file.
-
-When about to return a token that is not part of a directive,
-@code{_cpp_lex_token} sets @code{mi_valid} to @code{false}.  This
-enforces the constraint that tokens outside the controlling conditional
-block invalidate the optimization.
-
-The @code{do_if}, when appropriate, and @code{do_ifndef} directive
-handlers pass the controlling macro to the function
-@code{push_conditional}.  cpplib maintains a stack of nested conditional
-blocks, and after processing every opening conditional this function
-pushes an @code{if_stack} structure onto the stack.  In this structure
-it records the controlling macro for the block, provided there is one
-and we're at top-of-file (as described above).  If an @code{#elif} or
-@code{#else} directive is encountered, the controlling macro for that
-block is cleared to @code{NULL}.  Otherwise, it survives until the
-@code{#endif} closing the block, upon which @code{do_endif} sets
-@code{mi_valid} to true and stores the controlling macro in
-@code{mi_cmacro}.
-
-@code{_cpp_handle_directive} clears @code{mi_valid} when processing any
-directive other than an opening conditional and the null directive.
-With this, and requiring top-of-file to record a controlling macro, and
-no @code{#else} or @code{#elif} for it to survive and be copied to
-@code{mi_cmacro} by @code{do_endif}, we have enforced the absence of
-directives outside the main conditional block for the optimization to be
-on.
-
-Note that whilst we are inside the conditional block, @code{mi_valid} is
-likely to be reset to @code{false}, but this does not matter since
-the closing @code{#endif} restores it to @code{true} if appropriate.
-
-Finally, since @code{_cpp_lex_direct} pops the file off the buffer stack
-at @code{EOF} without returning a token, if the @code{#endif} directive
-was not followed by any tokens, @code{mi_valid} is @code{true} and
-@code{_cpp_pop_file_buffer} remembers the controlling macro associated
-with the file.  Subsequent calls to @code{stack_include_file} result in
-no buffer being pushed if the controlling macro is defined, effecting
-the optimization.
-
-A quick word on how we handle the
-
-@smallexample
-#if !defined FOO
-@end smallexample
-
-@noindent
-case.  @code{_cpp_parse_expr} and @code{parse_defined} take steps to see
-whether the three stages @samp{!}, @samp{defined-expression} and
-@samp{end-of-directive} occur in order in a @code{#if} expression.  If
-so, they return the guard macro to @code{do_if} in the variable
-@code{mi_ind_cmacro}, and otherwise set it to @code{NULL}.
-@code{enter_macro_context} sets @code{mi_valid} to false, so if a macro
-was expanded whilst parsing any part of the expression, then the
-top-of-file test in @code{push_conditional} fails and the optimization
-is turned off.
-
-@node Files
-@unnumbered File Handling
-@cindex files
-
-Fairly obviously, the file handling code of cpplib resides in the file
-@file{files.c}.  It takes care of the details of file searching,
-opening, reading and caching, for both the main source file and all the
-headers it recursively includes.
-
-The basic strategy is to minimize the number of system calls.  On many
-systems, the basic @code{open ()} and @code{fstat ()} system calls can
-be quite expensive.  For every @code{#include}-d file, we need to try
-all the directories in the search path until we find a match.  Some
-projects, such as glibc, pass twenty or thirty include paths on the
-command line, so this can rapidly become time consuming.
-
-For a header file we have not encountered before we have little choice
-but to do this.  However, it is often the case that the same headers are
-repeatedly included, and in these cases we try to avoid repeating the
-filesystem queries whilst searching for the correct file.
-
-For each file we try to open, we store the constructed path in a splay
-tree.  This path first undergoes simplification by the function
-@code{_cpp_simplify_pathname}.  For example,
-@file{/usr/include/bits/../foo.h} is simplified to
-@file{/usr/include/foo.h} before we enter it in the splay tree and try
-to @code{open ()} the file.  CPP will then find subsequent uses of
-@file{foo.h}, even as @file{/usr/include/foo.h}, in the splay tree and
-save system calls.
-
-Further, it is likely the file contents have also been cached, saving a
-@code{read ()} system call.  We don't bother caching the contents of
-header files that are re-inclusion protected, and whose re-inclusion
-macro is defined when we leave the header file for the first time.  If
-the host supports it, we try to map suitably large files into memory,
-rather than reading them in directly.
-
-The include paths are internally stored on a null-terminated
-singly-linked list, starting with the @code{"header.h"} directory search
-chain, which then links into the @code{<header.h>} directory chain.
-
-Files included with the @code{<foo.h>} syntax start the lookup directly
-in the second half of this chain.  However, files included with the
-@code{"foo.h"} syntax start at the beginning of the chain, but with one
-extra directory prepended.  This is the directory of the current file;
-the one containing the @code{#include} directive.  Prepending this
-directory on a per-file basis is handled by the function
-@code{search_from}.
-
-Note that a header included with a directory component, such as
-@code{#include "mydir/foo.h"} and opened as
-@file{/usr/local/include/mydir/foo.h}, will have the complete path minus
-the basename @samp{foo.h} as the current directory.
-
-Enough information is stored in the splay tree that CPP can immediately
-tell whether it can skip the header file because of the multiple include
-optimization, whether the file didn't exist or couldn't be opened for
-some reason, or whether the header was flagged not to be re-used, as it
-is with the obsolete @code{#import} directive.
-
-For the benefit of MS-DOS filesystems with an 8.3 filename limitation,
-CPP offers the ability to treat various include file names as aliases
-for the real header files with shorter names.  The map from one to the
-other is found in a special file called @samp{header.gcc}, stored in the
-command line (or system) include directories to which the mapping
-applies.  This may be higher up the directory tree than the full path to
-the file minus the base name.
-
-@node Concept Index
-@unnumbered Concept Index
-@printindex cp
-
-@bye
diff --git a/contrib/gcc-5.0/gcc/doc/cppopts.texi b/contrib/gcc-5.0/gcc/doc/cppopts.texi
deleted file mode 100644 (file)
index 40e6443..0000000
+++ /dev/null
@@ -1,835 +0,0 @@
-@c Copyright (C) 1999-2015 Free Software Foundation, Inc.
-@c This is part of the CPP and GCC manuals.
-@c For copying conditions, see the file gcc.texi.
-
-@c ---------------------------------------------------------------------
-@c Options affecting the preprocessor
-@c ---------------------------------------------------------------------
-
-@c If this file is included with the flag ``cppmanual'' set, it is
-@c formatted for inclusion in the CPP manual; otherwise the main GCC manual.
-
-@table @gcctabopt
-@item -D @var{name}
-@opindex D
-Predefine @var{name} as a macro, with definition @code{1}.
-
-@item -D @var{name}=@var{definition}
-The contents of @var{definition} are tokenized and processed as if
-they appeared during translation phase three in a @samp{#define}
-directive.  In particular, the definition will be truncated by
-embedded newline characters.
-
-If you are invoking the preprocessor from a shell or shell-like
-program you may need to use the shell's quoting syntax to protect
-characters such as spaces that have a meaning in the shell syntax.
-
-If you wish to define a function-like macro on the command line, write
-its argument list with surrounding parentheses before the equals sign
-(if any).  Parentheses are meaningful to most shells, so you will need
-to quote the option.  With @command{sh} and @command{csh},
-@option{-D'@var{name}(@var{args@dots{}})=@var{definition}'} works.
-
-@option{-D} and @option{-U} options are processed in the order they
-are given on the command line.  All @option{-imacros @var{file}} and
-@option{-include @var{file}} options are processed after all
-@option{-D} and @option{-U} options.
-
-@item -U @var{name}
-@opindex U
-Cancel any previous definition of @var{name}, either built in or
-provided with a @option{-D} option.
-
-@item -undef
-@opindex undef
-Do not predefine any system-specific or GCC-specific macros.  The
-standard predefined macros remain defined.
-@ifset cppmanual
-@xref{Standard Predefined Macros}.
-@end ifset
-
-@item -I @var{dir}
-@opindex I
-Add the directory @var{dir} to the list of directories to be searched
-for header files.
-@ifset cppmanual
-@xref{Search Path}.
-@end ifset
-Directories named by @option{-I} are searched before the standard
-system include directories.  If the directory @var{dir} is a standard
-system include directory, the option is ignored to ensure that the
-default search order for system directories and the special treatment
-of system headers are not defeated
-@ifset cppmanual
-(@pxref{System Headers})
-@end ifset
-.
-If @var{dir} begins with @code{=}, then the @code{=} will be replaced
-by the sysroot prefix; see @option{--sysroot} and @option{-isysroot}.
-
-@item -o @var{file}
-@opindex o
-Write output to @var{file}.  This is the same as specifying @var{file}
-as the second non-option argument to @command{cpp}.  @command{gcc} has a
-different interpretation of a second non-option argument, so you must
-use @option{-o} to specify the output file.
-
-@item -Wall
-@opindex Wall
-Turns on all optional warnings which are desirable for normal code.
-At present this is @option{-Wcomment}, @option{-Wtrigraphs},
-@option{-Wmultichar} and a warning about integer promotion causing a
-change of sign in @code{#if} expressions.  Note that many of the
-preprocessor's warnings are on by default and have no options to
-control them.
-
-@item -Wcomment
-@itemx -Wcomments
-@opindex Wcomment
-@opindex Wcomments
-Warn whenever a comment-start sequence @samp{/*} appears in a @samp{/*}
-comment, or whenever a backslash-newline appears in a @samp{//} comment.
-(Both forms have the same effect.)
-
-@item -Wtrigraphs
-@opindex Wtrigraphs
-@anchor{Wtrigraphs}
-Most trigraphs in comments cannot affect the meaning of the program.
-However, a trigraph that would form an escaped newline (@samp{??/} at
-the end of a line) can, by changing where the comment begins or ends.
-Therefore, only trigraphs that would form escaped newlines produce
-warnings inside a comment.
-
-This option is implied by @option{-Wall}.  If @option{-Wall} is not
-given, this option is still enabled unless trigraphs are enabled.  To
-get trigraph conversion without warnings, but get the other
-@option{-Wall} warnings, use @samp{-trigraphs -Wall -Wno-trigraphs}.
-
-@item -Wtraditional
-@opindex Wtraditional
-Warn about certain constructs that behave differently in traditional and
-ISO C@.  Also warn about ISO C constructs that have no traditional C
-equivalent, and problematic constructs which should be avoided.
-@ifset cppmanual
-@xref{Traditional Mode}.
-@end ifset
-
-@item -Wundef
-@opindex Wundef
-Warn whenever an identifier which is not a macro is encountered in an
-@samp{#if} directive, outside of @samp{defined}.  Such identifiers are
-replaced with zero.
-
-@item -Wunused-macros
-@opindex Wunused-macros
-Warn about macros defined in the main file that are unused.  A macro
-is @dfn{used} if it is expanded or tested for existence at least once.
-The preprocessor will also warn if the macro has not been used at the
-time it is redefined or undefined.
-
-Built-in macros, macros defined on the command line, and macros
-defined in include files are not warned about.
-
-@emph{Note:} If a macro is actually used, but only used in skipped
-conditional blocks, then CPP will report it as unused.  To avoid the
-warning in such a case, you might improve the scope of the macro's
-definition by, for example, moving it into the first skipped block.
-Alternatively, you could provide a dummy use with something like:
-
-@smallexample
-#if defined the_macro_causing_the_warning
-#endif
-@end smallexample
-
-@item -Wendif-labels
-@opindex Wendif-labels
-Warn whenever an @samp{#else} or an @samp{#endif} are followed by text.
-This usually happens in code of the form
-
-@smallexample
-#if FOO
-@dots{}
-#else FOO
-@dots{}
-#endif FOO
-@end smallexample
-
-@noindent
-The second and third @code{FOO} should be in comments, but often are not
-in older programs.  This warning is on by default.
-
-@item -Werror
-@opindex Werror
-Make all warnings into hard errors.  Source code which triggers warnings
-will be rejected.
-
-@item -Wsystem-headers
-@opindex Wsystem-headers
-Issue warnings for code in system headers.  These are normally unhelpful
-in finding bugs in your own code, therefore suppressed.  If you are
-responsible for the system library, you may want to see them.
-
-@item -w
-@opindex w
-Suppress all warnings, including those which GNU CPP issues by default.
-
-@item -pedantic
-@opindex pedantic
-Issue all the mandatory diagnostics listed in the C standard.  Some of
-them are left out by default, since they trigger frequently on harmless
-code.
-
-@item -pedantic-errors
-@opindex pedantic-errors
-Issue all the mandatory diagnostics, and make all mandatory diagnostics
-into errors.  This includes mandatory diagnostics that GCC issues
-without @samp{-pedantic} but treats as warnings.
-
-@item -M
-@opindex M
-@cindex @command{make}
-@cindex dependencies, @command{make}
-Instead of outputting the result of preprocessing, output a rule
-suitable for @command{make} describing the dependencies of the main
-source file.  The preprocessor outputs one @command{make} rule containing
-the object file name for that source file, a colon, and the names of all
-the included files, including those coming from @option{-include} or
-@option{-imacros} command-line options.
-
-Unless specified explicitly (with @option{-MT} or @option{-MQ}), the
-object file name consists of the name of the source file with any
-suffix replaced with object file suffix and with any leading directory
-parts removed.  If there are many included files then the rule is
-split into several lines using @samp{\}-newline.  The rule has no
-commands.
-
-This option does not suppress the preprocessor's debug output, such as
-@option{-dM}.  To avoid mixing such debug output with the dependency
-rules you should explicitly specify the dependency output file with
-@option{-MF}, or use an environment variable like
-@env{DEPENDENCIES_OUTPUT} (@pxref{Environment Variables}).  Debug output
-will still be sent to the regular output stream as normal.
-
-Passing @option{-M} to the driver implies @option{-E}, and suppresses
-warnings with an implicit @option{-w}.
-
-@item -MM
-@opindex MM
-Like @option{-M} but do not mention header files that are found in
-system header directories, nor header files that are included,
-directly or indirectly, from such a header.
-
-This implies that the choice of angle brackets or double quotes in an
-@samp{#include} directive does not in itself determine whether that
-header will appear in @option{-MM} dependency output.  This is a
-slight change in semantics from GCC versions 3.0 and earlier.
-
-@anchor{dashMF}
-@item -MF @var{file}
-@opindex MF
-When used with @option{-M} or @option{-MM}, specifies a
-file to write the dependencies to.  If no @option{-MF} switch is given
-the preprocessor sends the rules to the same place it would have sent
-preprocessed output.
-
-When used with the driver options @option{-MD} or @option{-MMD},
-@option{-MF} overrides the default dependency output file.
-
-@item -MG
-@opindex MG
-In conjunction with an option such as @option{-M} requesting
-dependency generation, @option{-MG} assumes missing header files are
-generated files and adds them to the dependency list without raising
-an error.  The dependency filename is taken directly from the
-@code{#include} directive without prepending any path.  @option{-MG}
-also suppresses preprocessed output, as a missing header file renders
-this useless.
-
-This feature is used in automatic updating of makefiles.
-
-@item -MP
-@opindex MP
-This option instructs CPP to add a phony target for each dependency
-other than the main file, causing each to depend on nothing.  These
-dummy rules work around errors @command{make} gives if you remove header
-files without updating the @file{Makefile} to match.
-
-This is typical output:
-
-@smallexample
-test.o: test.c test.h
-
-test.h:
-@end smallexample
-
-@item -MT @var{target}
-@opindex MT
-
-Change the target of the rule emitted by dependency generation.  By
-default CPP takes the name of the main input file, deletes any
-directory components and any file suffix such as @samp{.c}, and
-appends the platform's usual object suffix.  The result is the target.
-
-An @option{-MT} option will set the target to be exactly the string you
-specify.  If you want multiple targets, you can specify them as a single
-argument to @option{-MT}, or use multiple @option{-MT} options.
-
-For example, @option{@w{-MT '$(objpfx)foo.o'}} might give
-
-@smallexample
-$(objpfx)foo.o: foo.c
-@end smallexample
-
-@item -MQ @var{target}
-@opindex MQ
-
-Same as @option{-MT}, but it quotes any characters which are special to
-Make.  @option{@w{-MQ '$(objpfx)foo.o'}} gives
-
-@smallexample
-$$(objpfx)foo.o: foo.c
-@end smallexample
-
-The default target is automatically quoted, as if it were given with
-@option{-MQ}.
-
-@item -MD
-@opindex MD
-@option{-MD} is equivalent to @option{-M -MF @var{file}}, except that
-@option{-E} is not implied.  The driver determines @var{file} based on
-whether an @option{-o} option is given.  If it is, the driver uses its
-argument but with a suffix of @file{.d}, otherwise it takes the name
-of the input file, removes any directory components and suffix, and
-applies a @file{.d} suffix.
-
-If @option{-MD} is used in conjunction with @option{-E}, any
-@option{-o} switch is understood to specify the dependency output file
-(@pxref{dashMF,,-MF}), but if used without @option{-E}, each @option{-o}
-is understood to specify a target object file.
-
-Since @option{-E} is not implied, @option{-MD} can be used to generate
-a dependency output file as a side-effect of the compilation process.
-
-@item -MMD
-@opindex MMD
-Like @option{-MD} except mention only user header files, not system
-header files.
-
-@ifclear cppmanual
-@item -fpch-deps
-@opindex fpch-deps
-When using precompiled headers (@pxref{Precompiled Headers}), this flag
-will cause the dependency-output flags to also list the files from the
-precompiled header's dependencies.  If not specified only the
-precompiled header would be listed and not the files that were used to
-create it because those files are not consulted when a precompiled
-header is used.
-
-@item -fpch-preprocess
-@opindex fpch-preprocess
-This option allows use of a precompiled header (@pxref{Precompiled
-Headers}) together with @option{-E}.  It inserts a special @code{#pragma},
-@code{#pragma GCC pch_preprocess "@var{filename}"} in the output to mark
-the place where the precompiled header was found, and its @var{filename}.
-When @option{-fpreprocessed} is in use, GCC recognizes this @code{#pragma}
-and loads the PCH@.
-
-This option is off by default, because the resulting preprocessed output
-is only really suitable as input to GCC@.  It is switched on by
-@option{-save-temps}.
-
-You should not write this @code{#pragma} in your own code, but it is
-safe to edit the filename if the PCH file is available in a different
-location.  The filename may be absolute or it may be relative to GCC's
-current directory.
-
-@end ifclear
-@item -x c
-@itemx -x c++
-@itemx -x objective-c
-@itemx -x assembler-with-cpp
-@opindex x
-Specify the source language: C, C++, Objective-C, or assembly.  This has
-nothing to do with standards conformance or extensions; it merely
-selects which base syntax to expect.  If you give none of these options,
-cpp will deduce the language from the extension of the source file:
-@samp{.c}, @samp{.cc}, @samp{.m}, or @samp{.S}.  Some other common
-extensions for C++ and assembly are also recognized.  If cpp does not
-recognize the extension, it will treat the file as C; this is the most
-generic mode.
-
-@emph{Note:} Previous versions of cpp accepted a @option{-lang} option
-which selected both the language and the standards conformance level.
-This option has been removed, because it conflicts with the @option{-l}
-option.
-
-@item -std=@var{standard}
-@itemx -ansi
-@opindex ansi
-@opindex std=
-Specify the standard to which the code should conform.  Currently CPP
-knows about C and C++ standards; others may be added in the future.
-
-@var{standard}
-may be one of:
-@table @code
-@item c90
-@itemx c89
-@itemx iso9899:1990
-The ISO C standard from 1990.  @samp{c90} is the customary shorthand for
-this version of the standard.
-
-The @option{-ansi} option is equivalent to @option{-std=c90}.
-
-@item iso9899:199409
-The 1990 C standard, as amended in 1994.
-
-@item iso9899:1999
-@itemx c99
-@itemx iso9899:199x
-@itemx c9x
-The revised ISO C standard, published in December 1999.  Before
-publication, this was known as C9X@.
-
-@item iso9899:2011
-@itemx c11
-@itemx c1x
-The revised ISO C standard, published in December 2011.  Before
-publication, this was known as C1X@.
-
-@item gnu90
-@itemx gnu89
-The 1990 C standard plus GNU extensions.  This is the default.
-
-@item gnu99
-@itemx gnu9x
-The 1999 C standard plus GNU extensions.
-
-@item gnu11
-@itemx gnu1x
-The 2011 C standard plus GNU extensions.
-
-@item c++98
-The 1998 ISO C++ standard plus amendments.
-
-@item gnu++98
-The same as @option{-std=c++98} plus GNU extensions.  This is the
-default for C++ code.
-@end table
-
-@item -I-
-@opindex I-
-Split the include path.  Any directories specified with @option{-I}
-options before @option{-I-} are searched only for headers requested with
-@code{@w{#include "@var{file}"}}; they are not searched for
-@code{@w{#include <@var{file}>}}.  If additional directories are
-specified with @option{-I} options after the @option{-I-}, those
-directories are searched for all @samp{#include} directives.
-
-In addition, @option{-I-} inhibits the use of the directory of the current
-file directory as the first search directory for @code{@w{#include
-"@var{file}"}}.
-@ifset cppmanual
-@xref{Search Path}.
-@end ifset
-This option has been deprecated.
-
-@item -nostdinc
-@opindex nostdinc
-Do not search the standard system directories for header files.
-Only the directories you have specified with @option{-I} options
-(and the directory of the current file, if appropriate) are searched.
-
-@item -nostdinc++
-@opindex nostdinc++
-Do not search for header files in the C++-specific standard directories,
-but do still search the other standard directories.  (This option is
-used when building the C++ library.)
-
-@item -include @var{file}
-@opindex include
-Process @var{file} as if @code{#include "file"} appeared as the first
-line of the primary source file.  However, the first directory searched
-for @var{file} is the preprocessor's working directory @emph{instead of}
-the directory containing the main source file.  If not found there, it
-is searched for in the remainder of the @code{#include "@dots{}"} search
-chain as normal.
-
-If multiple @option{-include} options are given, the files are included
-in the order they appear on the command line.
-
-@item -imacros @var{file}
-@opindex imacros
-Exactly like @option{-include}, except that any output produced by
-scanning @var{file} is thrown away.  Macros it defines remain defined.
-This allows you to acquire all the macros from a header without also
-processing its declarations.
-
-All files specified by @option{-imacros} are processed before all files
-specified by @option{-include}.
-
-@item -idirafter @var{dir}
-@opindex idirafter
-Search @var{dir} for header files, but do it @emph{after} all
-directories specified with @option{-I} and the standard system directories
-have been exhausted.  @var{dir} is treated as a system include directory.
-If @var{dir} begins with @code{=}, then the @code{=} will be replaced
-by the sysroot prefix; see @option{--sysroot} and @option{-isysroot}.
-
-@item -iprefix @var{prefix}
-@opindex iprefix
-Specify @var{prefix} as the prefix for subsequent @option{-iwithprefix}
-options.  If the prefix represents a directory, you should include the
-final @samp{/}.
-
-@item -iwithprefix @var{dir}
-@itemx -iwithprefixbefore @var{dir}
-@opindex iwithprefix
-@opindex iwithprefixbefore
-Append @var{dir} to the prefix specified previously with
-@option{-iprefix}, and add the resulting directory to the include search
-path.  @option{-iwithprefixbefore} puts it in the same place @option{-I}
-would; @option{-iwithprefix} puts it where @option{-idirafter} would.
-
-@item -isysroot @var{dir}
-@opindex isysroot
-This option is like the @option{--sysroot} option, but applies only to
-header files (except for Darwin targets, where it applies to both header
-files and libraries).  See the @option{--sysroot} option for more
-information.
-
-@item -imultilib @var{dir}
-@opindex imultilib
-Use @var{dir} as a subdirectory of the directory containing
-target-specific C++ headers.
-
-@item -isystem @var{dir}
-@opindex isystem
-Search @var{dir} for header files, after all directories specified by
-@option{-I} but before the standard system directories.  Mark it
-as a system directory, so that it gets the same special treatment as
-is applied to the standard system directories.
-@ifset cppmanual
-@xref{System Headers}.
-@end ifset
-If @var{dir} begins with @code{=}, then the @code{=} will be replaced
-by the sysroot prefix; see @option{--sysroot} and @option{-isysroot}.
-
-@item -iquote @var{dir}
-@opindex iquote
-Search @var{dir} only for header files requested with
-@code{@w{#include "@var{file}"}}; they are not searched for
-@code{@w{#include <@var{file}>}}, before all directories specified by
-@option{-I} and before the standard system directories.
-@ifset cppmanual
-@xref{Search Path}.
-@end ifset
-If @var{dir} begins with @code{=}, then the @code{=} will be replaced
-by the sysroot prefix; see @option{--sysroot} and @option{-isysroot}.
-
-@item -fdirectives-only
-@opindex fdirectives-only
-When preprocessing, handle directives, but do not expand macros.
-
-The option's behavior depends on the @option{-E} and @option{-fpreprocessed}
-options.
-
-With @option{-E}, preprocessing is limited to the handling of directives
-such as @code{#define}, @code{#ifdef}, and @code{#error}.  Other
-preprocessor operations, such as macro expansion and trigraph
-conversion are not performed.  In addition, the @option{-dD} option is
-implicitly enabled.
-
-With @option{-fpreprocessed}, predefinition of command line and most
-builtin macros is disabled.  Macros such as @code{__LINE__}, which are
-contextually dependent, are handled normally.  This enables compilation of
-files previously preprocessed with @code{-E -fdirectives-only}.
-
-With both @option{-E} and @option{-fpreprocessed}, the rules for
-@option{-fpreprocessed} take precedence.  This enables full preprocessing of
-files previously preprocessed with @code{-E -fdirectives-only}.
-
-@item -fdollars-in-identifiers
-@opindex fdollars-in-identifiers
-@anchor{fdollars-in-identifiers}
-Accept @samp{$} in identifiers.
-@ifset cppmanual
-@xref{Identifier characters}.
-@end ifset
-
-@item -fextended-identifiers
-@opindex fextended-identifiers
-Accept universal character names in identifiers.  This option is
-enabled by default for C99 (and later C standard versions) and C++.
-
-@item -fno-canonical-system-headers
-@opindex fno-canonical-system-headers
-When preprocessing, do not shorten system header paths with canonicalization.
-
-@item -fpreprocessed
-@opindex fpreprocessed
-Indicate to the preprocessor that the input file has already been
-preprocessed.  This suppresses things like macro expansion, trigraph
-conversion, escaped newline splicing, and processing of most directives.
-The preprocessor still recognizes and removes comments, so that you can
-pass a file preprocessed with @option{-C} to the compiler without
-problems.  In this mode the integrated preprocessor is little more than
-a tokenizer for the front ends.
-
-@option{-fpreprocessed} is implicit if the input file has one of the
-extensions @samp{.i}, @samp{.ii} or @samp{.mi}.  These are the
-extensions that GCC uses for preprocessed files created by
-@option{-save-temps}.
-
-@item -ftabstop=@var{width}
-@opindex ftabstop
-Set the distance between tab stops.  This helps the preprocessor report
-correct column numbers in warnings or errors, even if tabs appear on the
-line.  If the value is less than 1 or greater than 100, the option is
-ignored.  The default is 8.
-
-@item -fdebug-cpp
-@opindex fdebug-cpp
-This option is only useful for debugging GCC.  When used with
-@option{-E}, dumps debugging information about location maps.  Every
-token in the output is preceded by the dump of the map its location
-belongs to.  The dump of the map holding the location of a token would
-be:
-@smallexample
-@{@samp{P}:@file{/file/path};@samp{F}:@file{/includer/path};@samp{L}:@var{line_num};@samp{C}:@var{col_num};@samp{S}:@var{system_header_p};@samp{M}:@var{map_address};@samp{E}:@var{macro_expansion_p},@samp{loc}:@var{location}@}
-@end smallexample
-
-When used without @option{-E}, this option has no effect.
-
-@item -ftrack-macro-expansion@r{[}=@var{level}@r{]}
-@opindex ftrack-macro-expansion
-Track locations of tokens across macro expansions. This allows the
-compiler to emit diagnostic about the current macro expansion stack
-when a compilation error occurs in a macro expansion. Using this
-option makes the preprocessor and the compiler consume more
-memory. The @var{level} parameter can be used to choose the level of
-precision of token location tracking thus decreasing the memory
-consumption if necessary. Value @samp{0} of @var{level} de-activates
-this option just as if no @option{-ftrack-macro-expansion} was present
-on the command line. Value @samp{1} tracks tokens locations in a
-degraded mode for the sake of minimal memory overhead. In this mode
-all tokens resulting from the expansion of an argument of a
-function-like macro have the same location. Value @samp{2} tracks
-tokens locations completely. This value is the most memory hungry.
-When this option is given no argument, the default parameter value is
-@samp{2}.
-
-Note that @code{-ftrack-macro-expansion=2} is activated by default.
-
-@item -fexec-charset=@var{charset}
-@opindex fexec-charset
-@cindex character set, execution
-Set the execution character set, used for string and character
-constants.  The default is UTF-8.  @var{charset} can be any encoding
-supported by the system's @code{iconv} library routine.
-
-@item -fwide-exec-charset=@var{charset}
-@opindex fwide-exec-charset
-@cindex character set, wide execution
-Set the wide execution character set, used for wide string and
-character constants.  The default is UTF-32 or UTF-16, whichever
-corresponds to the width of @code{wchar_t}.  As with
-@option{-fexec-charset}, @var{charset} can be any encoding supported
-by the system's @code{iconv} library routine; however, you will have
-problems with encodings that do not fit exactly in @code{wchar_t}.
-
-@item -finput-charset=@var{charset}
-@opindex finput-charset
-@cindex character set, input
-Set the input character set, used for translation from the character
-set of the input file to the source character set used by GCC@.  If the
-locale does not specify, or GCC cannot get this information from the
-locale, the default is UTF-8.  This can be overridden by either the locale
-or this command-line option.  Currently the command-line option takes
-precedence if there's a conflict.  @var{charset} can be any encoding
-supported by the system's @code{iconv} library routine.
-
-@item -fworking-directory
-@opindex fworking-directory
-@opindex fno-working-directory
-Enable generation of linemarkers in the preprocessor output that will
-let the compiler know the current working directory at the time of
-preprocessing.  When this option is enabled, the preprocessor will
-emit, after the initial linemarker, a second linemarker with the
-current working directory followed by two slashes.  GCC will use this
-directory, when it's present in the preprocessed input, as the
-directory emitted as the current working directory in some debugging
-information formats.  This option is implicitly enabled if debugging
-information is enabled, but this can be inhibited with the negated
-form @option{-fno-working-directory}.  If the @option{-P} flag is
-present in the command line, this option has no effect, since no
-@code{#line} directives are emitted whatsoever.
-
-@item -fno-show-column
-@opindex fno-show-column
-Do not print column numbers in diagnostics.  This may be necessary if
-diagnostics are being scanned by a program that does not understand the
-column numbers, such as @command{dejagnu}.
-
-@item -A @var{predicate}=@var{answer}
-@opindex A
-Make an assertion with the predicate @var{predicate} and answer
-@var{answer}.  This form is preferred to the older form @option{-A
-@var{predicate}(@var{answer})}, which is still supported, because
-it does not use shell special characters.
-@ifset cppmanual
-@xref{Obsolete Features}.
-@end ifset
-
-@item -A -@var{predicate}=@var{answer}
-Cancel an assertion with the predicate @var{predicate} and answer
-@var{answer}.
-
-@item -dCHARS
-@var{CHARS} is a sequence of one or more of the following characters,
-and must not be preceded by a space.  Other characters are interpreted
-by the compiler proper, or reserved for future versions of GCC, and so
-are silently ignored.  If you specify characters whose behavior
-conflicts, the result is undefined.
-
-@table @samp
-@item M
-@opindex dM
-Instead of the normal output, generate a list of @samp{#define}
-directives for all the macros defined during the execution of the
-preprocessor, including predefined macros.  This gives you a way of
-finding out what is predefined in your version of the preprocessor.
-Assuming you have no file @file{foo.h}, the command
-
-@smallexample
-touch foo.h; cpp -dM foo.h
-@end smallexample
-
-@noindent
-will show all the predefined macros.
-
-If you use @option{-dM} without the @option{-E} option, @option{-dM} is
-interpreted as a synonym for @option{-fdump-rtl-mach}.
-@xref{Debugging Options, , ,gcc}.
-
-@item D
-@opindex dD
-Like @samp{M} except in two respects: it does @emph{not} include the
-predefined macros, and it outputs @emph{both} the @samp{#define}
-directives and the result of preprocessing.  Both kinds of output go to
-the standard output file.
-
-@item N
-@opindex dN
-Like @samp{D}, but emit only the macro names, not their expansions.
-
-@item I
-@opindex dI
-Output @samp{#include} directives in addition to the result of
-preprocessing.
-
-@item&