init: init nachos hw01, should pass jenkins os_group_20_hw job but fail on os_group_20_ta job

usr/local/nachos/decstation-ultrix/lib/ldscripts/mipslit.x

@@ -0,0 +1,52 @@
+OUTPUT_FORMAT("ecoff-littlemips", "ecoff-bigmips",
+	      "ecoff-littlemips")
+ SEARCH_DIR(/usr/local/nachos/decstation-ultrix/lib);
+ENTRY(__start)
+SECTIONS
+{
+  . = 0x400000 + SIZEOF_HEADERS;
+  .text : {
+     _ftext = . ;
+    *(.init)
+     eprol  =  .;
+    *(.text)
+    PROVIDE (__runtime_reloc_start = .);
+    *(.rel.sdata)
+    PROVIDE (__runtime_reloc_stop = .);
+    *(.fini)
+     etext  =  .;
+     _etext  =  .;
+  }
+  . = 0x10000000;
+  .rdata : {
+    *(.rdata)
+  }
+   _fdata = ALIGN(16);
+  .data : {
+    *(.data)
+    CONSTRUCTORS
+  }
+   _gp = ALIGN(16) + 0x8000;
+  .lit8 : {
+    *(.lit8)
+  }
+  .lit4 : {
+    *(.lit4)
+  }
+  .sdata : {
+    *(.sdata)
+  }
+   edata  =  .;
+   _edata  =  .;
+   _fbss = .;
+  .sbss : {
+    *(.sbss)
+    *(.scommon)
+  }
+  .bss : {
+    *(.bss)
+    *(COMMON)
+  }
+   end = .;
+   _end = .;
+}

usr/local/nachos/decstation-ultrix/lib/ldscripts/mipslit.xbn

@@ -0,0 +1,52 @@
+OUTPUT_FORMAT("ecoff-littlemips", "ecoff-bigmips",
+	      "ecoff-littlemips")
+ SEARCH_DIR(/usr/local/nachos/decstation-ultrix/lib);
+ENTRY(__start)
+SECTIONS
+{
+  . = 0x400000 + SIZEOF_HEADERS;
+  .text : {
+     _ftext = . ;
+    *(.init)
+     eprol  =  .;
+    *(.text)
+    PROVIDE (__runtime_reloc_start = .);
+    *(.rel.sdata)
+    PROVIDE (__runtime_reloc_stop = .);
+    *(.fini)
+     etext  =  .;
+     _etext  =  .;
+  }
+  . = .;
+  .rdata : {
+    *(.rdata)
+  }
+   _fdata = ALIGN(16);
+  .data : {
+    *(.data)
+    CONSTRUCTORS
+  }
+   _gp = ALIGN(16) + 0x8000;
+  .lit8 : {
+    *(.lit8)
+  }
+  .lit4 : {
+    *(.lit4)
+  }
+  .sdata : {
+    *(.sdata)
+  }
+   edata  =  .;
+   _edata  =  .;
+   _fbss = .;
+  .sbss : {
+    *(.sbss)
+    *(.scommon)
+  }
+  .bss : {
+    *(.bss)
+    *(COMMON)
+  }
+   end = .;
+   _end = .;
+}

usr/local/nachos/decstation-ultrix/lib/ldscripts/mipslit.xn

@@ -0,0 +1,52 @@
+OUTPUT_FORMAT("ecoff-littlemips", "ecoff-bigmips",
+	      "ecoff-littlemips")
+ SEARCH_DIR(/usr/local/nachos/decstation-ultrix/lib);
+ENTRY(__start)
+SECTIONS
+{
+  . = 0x400000 + SIZEOF_HEADERS;
+  .text : {
+     _ftext = . ;
+    *(.init)
+     eprol  =  .;
+    *(.text)
+    PROVIDE (__runtime_reloc_start = .);
+    *(.rel.sdata)
+    PROVIDE (__runtime_reloc_stop = .);
+    *(.fini)
+     etext  =  .;
+     _etext  =  .;
+  }
+  . = .;
+  .rdata : {
+    *(.rdata)
+  }
+   _fdata = ALIGN(16);
+  .data : {
+    *(.data)
+    CONSTRUCTORS
+  }
+   _gp = ALIGN(16) + 0x8000;
+  .lit8 : {
+    *(.lit8)
+  }
+  .lit4 : {
+    *(.lit4)
+  }
+  .sdata : {
+    *(.sdata)
+  }
+   edata  =  .;
+   _edata  =  .;
+   _fbss = .;
+  .sbss : {
+    *(.sbss)
+    *(.scommon)
+  }
+  .bss : {
+    *(.bss)
+    *(COMMON)
+  }
+   end = .;
+   _end = .;
+}

usr/local/nachos/decstation-ultrix/lib/ldscripts/mipslit.xr

@@ -0,0 +1,40 @@
+OUTPUT_FORMAT("ecoff-littlemips", "ecoff-bigmips",
+	      "ecoff-littlemips")
+ SEARCH_DIR(/usr/local/nachos/decstation-ultrix/lib);
+ENTRY(__start)
+SECTIONS
+{
+  .text : {
+    ;
+    *(.init)
+    ;
+    *(.text)
+    *(.rel.sdata)
+    *(.fini)
+    ;
+    ;
+  }
+  .rdata : {
+    *(.rdata)
+  }
+  .data : {
+    *(.data)
+  }
+  .lit8 : {
+    *(.lit8)
+  }
+  .lit4 : {
+    *(.lit4)
+  }
+  .sdata : {
+    *(.sdata)
+  }
+  .sbss : {
+    *(.sbss)
+    *(.scommon)
+  }
+  .bss : {
+    *(.bss)
+    *(COMMON)
+  }
+}

usr/local/nachos/decstation-ultrix/lib/ldscripts/mipslit.xu

@@ -0,0 +1,41 @@
+OUTPUT_FORMAT("ecoff-littlemips", "ecoff-bigmips",
+	      "ecoff-littlemips")
+ SEARCH_DIR(/usr/local/nachos/decstation-ultrix/lib);
+ENTRY(__start)
+SECTIONS
+{
+  .text : {
+    ;
+    *(.init)
+    ;
+    *(.text)
+    *(.rel.sdata)
+    *(.fini)
+    ;
+    ;
+  }
+  .rdata : {
+    *(.rdata)
+  }
+  .data : {
+    *(.data)
+    CONSTRUCTORS
+  }
+  .lit8 : {
+    *(.lit8)
+  }
+  .lit4 : {
+    *(.lit4)
+  }
+  .sdata : {
+    *(.sdata)
+  }
+  .sbss : {
+    *(.sbss)
+    *(.scommon)
+  }
+  .bss : {
+    *(.bss)
+    *(COMMON)
+  }
+}

usr/local/nachos/include/ansidecl.h

@@ -0,0 +1,224 @@
+/* ANSI and traditional C compatability macros
+   Copyright 1991, 1992, 1996, 1999 Free Software Foundation, Inc.
+   This file is part of the GNU C Library.
+
+This program is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2 of the License, or
+(at your option) any later version.
+
+This program is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with this program; if not, write to the Free Software
+Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  */
+
+/* ANSI and traditional C compatibility macros
+
+   ANSI C is assumed if __STDC__ is #defined.
+
+   Macro	ANSI C definition	Traditional C definition
+   -----	---- - ----------	----------- - ----------
+   PTR		`void *'		`char *'
+   LONG_DOUBLE	`long double'		`double'
+   VOLATILE	`volatile'		`'
+   SIGNED	`signed'		`'
+   PTRCONST	`void *const'		`char *'
+   ANSI_PROTOTYPES  1			not defined
+
+   CONST is also defined, but is obsolete.  Just use const.
+
+   obsolete --     DEFUN (name, arglist, args)
+
+	Defines function NAME.
+
+	ARGLIST lists the arguments, separated by commas and enclosed in
+	parentheses.  ARGLIST becomes the argument list in traditional C.
+
+	ARGS list the arguments with their types.  It becomes a prototype in
+	ANSI C, and the type declarations in traditional C.  Arguments should
+	be separated with `AND'.  For functions with a variable number of
+	arguments, the last thing listed should be `DOTS'.
+
+   obsolete --     DEFUN_VOID (name)
+
+	Defines a function NAME, which takes no arguments.
+
+   obsolete --     EXFUN (name, (prototype))	-- obsolete.
+
+	Replaced by PARAMS.  Do not use; will disappear someday soon.
+	Was used in external function declarations.
+	In ANSI C it is `NAME PROTOTYPE' (so PROTOTYPE should be enclosed in
+	parentheses).  In traditional C it is `NAME()'.
+	For a function that takes no arguments, PROTOTYPE should be `(void)'.
+
+   obsolete --     PROTO (type, name, (prototype)    -- obsolete.
+
+	This one has also been replaced by PARAMS.  Do not use.
+
+   PARAMS ((args))
+
+	We could use the EXFUN macro to handle prototype declarations, but
+	the name is misleading and the result is ugly.  So we just define a
+	simple macro to handle the parameter lists, as in:
+
+	      static int foo PARAMS ((int, char));
+
+	This produces:  `static int foo();' or `static int foo (int, char);'
+
+	EXFUN would have done it like this:
+
+	      static int EXFUN (foo, (int, char));
+
+	but the function is not external...and it's hard to visually parse
+	the function name out of the mess.   EXFUN should be considered
+	obsolete; new code should be written to use PARAMS.
+
+   DOTS is also obsolete.
+
+   Examples:
+
+	extern int printf PARAMS ((const char *format, ...));
+*/
+
+#ifndef	_ANSIDECL_H
+
+#define	_ANSIDECL_H	1
+
+
+/* Every source file includes this file,
+   so they will all get the switch for lint.  */
+/* LINTLIBRARY */
+
+
+#if defined (__STDC__) || defined (_AIX) || (defined (__mips) && defined (_SYSTYPE_SVR4)) || defined(_WIN32)
+/* All known AIX compilers implement these things (but don't always
+   define __STDC__).  The RISC/OS MIPS compiler defines these things
+   in SVR4 mode, but does not define __STDC__.  */
+
+#define	PTR		void *
+#define	PTRCONST	void *CONST
+#define	LONG_DOUBLE	long double
+
+#ifndef IN_GCC
+#define	AND		,
+#define	NOARGS		void
+#define	VOLATILE	volatile
+#define	SIGNED		signed
+#endif /* ! IN_GCC */
+
+#define PARAMS(paramlist)		paramlist
+#define ANSI_PROTOTYPES			1
+
+#define VPARAMS(ARGS)			ARGS
+#define VA_START(va_list,var)		va_start(va_list,var)
+
+/* These are obsolete.  Do not use.  */
+#ifndef IN_GCC
+#define CONST				const
+#define DOTS				, ...
+#define PROTO(type, name, arglist)	type name arglist
+#define EXFUN(name, proto)		name proto
+#define DEFUN(name, arglist, args)	name(args)
+#define DEFUN_VOID(name)		name(void)
+#endif /* ! IN_GCC */
+
+#else	/* Not ANSI C.  */
+
+#define	PTR		char *
+#define	PTRCONST	PTR
+#define	LONG_DOUBLE	double
+
+#ifndef IN_GCC
+#define	AND		;
+#define	NOARGS
+#define	VOLATILE
+#define	SIGNED
+#endif /* !IN_GCC */
+
+#ifndef const /* some systems define it in header files for non-ansi mode */
+#define	const
+#endif
+
+#define PARAMS(paramlist)		()
+
+#define VPARAMS(ARGS)			(va_alist) va_dcl
+#define VA_START(va_list,var)		va_start(va_list)
+
+/* These are obsolete.  Do not use.  */
+#ifndef IN_GCC
+#define CONST
+#define DOTS
+#define PROTO(type, name, arglist)	type name ()
+#define EXFUN(name, proto)		name()
+#define DEFUN(name, arglist, args)	name arglist args;
+#define DEFUN_VOID(name)		name()
+#endif /* ! IN_GCC */
+
+#endif	/* ANSI C.  */
+
+/* Using MACRO(x,y) in cpp #if conditionals does not work with some
+   older preprocessors.  Thus we can't define something like this:
+
+#define HAVE_GCC_VERSION(MAJOR, MINOR) \
+  (__GNUC__ > (MAJOR) || (__GNUC__ == (MAJOR) && __GNUC_MINOR__ >= (MINOR)))
+
+and then test "#if HAVE_GCC_VERSION(2,7)".
+
+So instead we use the macro below and test it against specific values.  */
+
+/* This macro simplifies testing whether we are using gcc, and if it
+   is of a particular minimum version. (Both major & minor numbers are
+   significant.)  This macro will evaluate to 0 if we are not using
+   gcc at all.  */
+#ifndef GCC_VERSION
+#define GCC_VERSION (__GNUC__ * 1000 + __GNUC_MINOR__)
+#endif /* GCC_VERSION */
+
+/* Define macros for some gcc attributes.  This permits us to use the
+   macros freely, and know that they will come into play for the
+   version of gcc in which they are supported.  */
+
+#if (GCC_VERSION < 2007)
+# define __attribute__(x)
+#endif
+
+/* Attribute __malloc__ on functions was valid as of gcc 2.96. */
+#ifndef ATTRIBUTE_MALLOC
+# if (GCC_VERSION >= 2096)
+#  define ATTRIBUTE_MALLOC __attribute__ ((__malloc__))
+# else
+#  define ATTRIBUTE_MALLOC
+# endif /* GNUC >= 2.96 */
+#endif /* ATTRIBUTE_MALLOC */
+
+/* Attributes on labels were valid as of gcc 2.93. */
+#ifndef ATTRIBUTE_UNUSED_LABEL
+# if (GCC_VERSION >= 2093)
+#  define ATTRIBUTE_UNUSED_LABEL ATTRIBUTE_UNUSED
+# else
+#  define ATTRIBUTE_UNUSED_LABEL
+# endif /* GNUC >= 2.93 */
+#endif /* ATTRIBUTE_UNUSED_LABEL */
+
+#ifndef ATTRIBUTE_UNUSED
+#define ATTRIBUTE_UNUSED __attribute__ ((__unused__))
+#endif /* ATTRIBUTE_UNUSED */
+
+#ifndef ATTRIBUTE_NORETURN
+#define ATTRIBUTE_NORETURN __attribute__ ((__noreturn__))
+#endif /* ATTRIBUTE_NORETURN */
+
+#ifndef ATTRIBUTE_PRINTF
+#define ATTRIBUTE_PRINTF(m, n) __attribute__ ((__format__ (__printf__, m, n)))
+#define ATTRIBUTE_PRINTF_1 ATTRIBUTE_PRINTF(1, 2)
+#define ATTRIBUTE_PRINTF_2 ATTRIBUTE_PRINTF(2, 3)
+#define ATTRIBUTE_PRINTF_3 ATTRIBUTE_PRINTF(3, 4)
+#define ATTRIBUTE_PRINTF_4 ATTRIBUTE_PRINTF(4, 5)
+#define ATTRIBUTE_PRINTF_5 ATTRIBUTE_PRINTF(5, 6)
+#endif /* ATTRIBUTE_PRINTF */
+
+#endif	/* ansidecl.h	*/

usr/local/nachos/include/bfdlink.h

@@ -0,0 +1,530 @@
+/* bfdlink.h -- header file for BFD link routines
+   Copyright 1993, 94, 95, 96, 97, 1999 Free Software Foundation, Inc.
+   Written by Steve Chamberlain and Ian Lance Taylor, Cygnus Support.
+
+This file is part of BFD, the Binary File Descriptor library.
+
+This program is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2 of the License, or
+(at your option) any later version.
+
+This program is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with this program; if not, write to the Free Software
+Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  */
+
+#ifndef BFDLINK_H
+#define BFDLINK_H
+
+/* Which symbols to strip during a link.  */
+enum bfd_link_strip
+{
+  strip_none,		/* Don't strip any symbols.  */
+  strip_debugger,	/* Strip debugging symbols.  */
+  strip_some,		/* keep_hash is the list of symbols to keep.  */
+  strip_all		/* Strip all symbols.  */
+};
+
+/* Which local symbols to discard during a link.  This is irrelevant
+   if strip_all is used.  */
+enum bfd_link_discard
+{
+  discard_none,		/* Don't discard any locals.  */
+  discard_l,		/* Discard local temporary symbols.  */
+  discard_all		/* Discard all locals.  */
+};
+
+/* These are the possible types of an entry in the BFD link hash
+   table.  */
+
+enum bfd_link_hash_type
+{
+  bfd_link_hash_new,		/* Symbol is new.  */
+  bfd_link_hash_undefined,	/* Symbol seen before, but undefined.  */
+  bfd_link_hash_undefweak,	/* Symbol is weak and undefined.  */
+  bfd_link_hash_defined,	/* Symbol is defined.  */
+  bfd_link_hash_defweak,	/* Symbol is weak and defined.  */
+  bfd_link_hash_common,		/* Symbol is common.  */
+  bfd_link_hash_indirect,	/* Symbol is an indirect link.  */
+  bfd_link_hash_warning		/* Like indirect, but warn if referenced.  */
+};
+
+/* The linking routines use a hash table which uses this structure for
+   its elements.  */
+
+struct bfd_link_hash_entry
+{
+  /* Base hash table entry structure.  */
+  struct bfd_hash_entry root;
+  /* Type of this entry.  */
+  enum bfd_link_hash_type type;
+
+  /* Undefined and common symbols are kept in a linked list through
+     this field.  This field is not in the union because that would
+     force us to remove entries from the list when we changed their
+     type, which would force the list to be doubly linked, which would
+     waste more memory.  When an undefined or common symbol is
+     created, it should be added to this list, the head of which is in
+     the link hash table itself.  As symbols are defined, they need
+     not be removed from the list; anything which reads the list must
+     doublecheck the symbol type.
+
+     Weak symbols are not kept on this list.
+
+     Defined and defweak symbols use this field as a reference marker.
+     If the field is not NULL, or this structure is the tail of the
+     undefined symbol list, the symbol has been referenced.  If the
+     symbol is undefined and becomes defined, this field will
+     automatically be non-NULL since the symbol will have been on the
+     undefined symbol list.  */
+  struct bfd_link_hash_entry *next;
+  /* A union of information depending upon the type.  */
+  union
+    {
+      /* Nothing is kept for bfd_hash_new.  */
+      /* bfd_link_hash_undefined, bfd_link_hash_undefweak.  */
+      struct
+	{
+	  bfd *abfd;		/* BFD symbol was found in.  */
+	} undef;
+      /* bfd_link_hash_defined, bfd_link_hash_defweak.  */
+      struct
+	{
+	  bfd_vma value;	/* Symbol value.  */
+	  asection *section;	/* Symbol section.  */
+	} def;
+      /* bfd_link_hash_indirect, bfd_link_hash_warning.  */
+      struct
+	{
+	  struct bfd_link_hash_entry *link;	/* Real symbol.  */
+	  const char *warning;	/* Warning (bfd_link_hash_warning only).  */
+	} i;
+      /* bfd_link_hash_common.  */
+      struct
+	{
+	  /* The linker needs to know three things about common
+             symbols: the size, the alignment, and the section in
+             which the symbol should be placed.  We store the size
+             here, and we allocate a small structure to hold the
+             section and the alignment.  The alignment is stored as a
+             power of two.  We don't store all the information
+             directly because we don't want to increase the size of
+             the union; this structure is a major space user in the
+             linker.  */
+	  bfd_size_type size;	/* Common symbol size.  */
+	  struct bfd_link_hash_common_entry
+	    {
+	      unsigned int alignment_power;	/* Alignment.  */
+	      asection *section;		/* Symbol section.  */
+	    } *p;
+	} c;
+    } u;
+};
+
+/* This is the link hash table.  It is a derived class of
+   bfd_hash_table.  */
+
+struct bfd_link_hash_table
+{
+  /* The hash table itself.  */
+  struct bfd_hash_table table;
+  /* The back end which created this hash table.  This indicates the
+     type of the entries in the hash table, which is sometimes
+     important information when linking object files of different
+     types together.  */
+  const bfd_target *creator;
+  /* A linked list of undefined and common symbols, linked through the
+     next field in the bfd_link_hash_entry structure.  */
+  struct bfd_link_hash_entry *undefs;
+  /* Entries are added to the tail of the undefs list.  */
+  struct bfd_link_hash_entry *undefs_tail;
+};
+
+/* Look up an entry in a link hash table.  If FOLLOW is true, this
+   follows bfd_link_hash_indirect and bfd_link_hash_warning links to
+   the real symbol.  */
+extern struct bfd_link_hash_entry *bfd_link_hash_lookup
+  PARAMS ((struct bfd_link_hash_table *, const char *, boolean create,
+	   boolean copy, boolean follow));
+
+/* Look up an entry in the main linker hash table if the symbol might
+   be wrapped.  This should only be used for references to an
+   undefined symbol, not for definitions of a symbol.  */
+
+extern struct bfd_link_hash_entry *bfd_wrapped_link_hash_lookup
+  PARAMS ((bfd *, struct bfd_link_info *, const char *, boolean, boolean,
+	   boolean));
+
+/* Traverse a link hash table.  */
+extern void bfd_link_hash_traverse
+  PARAMS ((struct bfd_link_hash_table *,
+	   boolean (*) (struct bfd_link_hash_entry *, PTR),
+	   PTR));
+
+/* Add an entry to the undefs list.  */
+extern void bfd_link_add_undef
+  PARAMS ((struct bfd_link_hash_table *, struct bfd_link_hash_entry *));
+
+/* This structure holds all the information needed to communicate
+   between BFD and the linker when doing a link.  */
+
+struct bfd_link_info
+{
+  /* Function callbacks.  */
+  const struct bfd_link_callbacks *callbacks;
+  /* true if BFD should generate a relocateable object file.  */
+  boolean relocateable;
+  /* true if BFD should generate a "task linked" object file,
+     similar to relocatable but also with globals converted to statics. */
+  boolean task_link;
+  /* true if BFD should generate a shared object.  */
+  boolean shared;
+  /* true if BFD should pre-bind symbols in a shared object.  */
+  boolean symbolic;
+  /* true if shared objects should be linked directly, not shared.  */
+  boolean static_link;
+  /* true if the output file should be in a traditional format.  This
+     is equivalent to the setting of the BFD_TRADITIONAL_FORMAT flag
+     on the output file, but may be checked when reading the input
+     files.  */
+  boolean traditional_format;
+  /* true if we want to produced optimized output files.  This might
+     need much more time and therefore must be explicitly selected.  */
+  boolean optimize;
+  /* true if BFD should generate errors for undefined symbols
+     even if generating a shared object.  */
+  boolean no_undefined;
+  /* Which symbols to strip.  */
+  enum bfd_link_strip strip;
+  /* Which local symbols to discard.  */
+  enum bfd_link_discard discard;
+  /* true if symbols should be retained in memory, false if they
+     should be freed and reread.  */
+  boolean keep_memory;
+  /* The list of input BFD's involved in the link.  These are chained
+     together via the link_next field.  */
+  bfd *input_bfds;
+  /* If a symbol should be created for each input BFD, this is section
+     where those symbols should be placed.  It must be a section in
+     the output BFD.  It may be NULL, in which case no such symbols
+     will be created.  This is to support CREATE_OBJECT_SYMBOLS in the
+     linker command language.  */
+  asection *create_object_symbols_section;
+  /* Hash table handled by BFD.  */
+  struct bfd_link_hash_table *hash;
+  /* Hash table of symbols to keep.  This is NULL unless strip is
+     strip_some.  */
+  struct bfd_hash_table *keep_hash;
+  /* true if every symbol should be reported back via the notice
+     callback.  */
+  boolean notice_all;
+  /* Hash table of symbols to report back via the notice callback.  If
+     this is NULL, and notice_all is false, then no symbols are
+     reported back.  */
+  struct bfd_hash_table *notice_hash;
+  /* Hash table of symbols which are being wrapped (the --wrap linker
+     option).  If this is NULL, no symbols are being wrapped.  */
+  struct bfd_hash_table *wrap_hash;
+  /* If a base output file is wanted, then this points to it */
+  PTR base_file;
+
+  /* If non-zero, specifies that branches which are problematic for the
+  MPC860 C0 (or earlier) should be checked for and modified.  It gives the
+  number of bytes that should be checked at the end of each text page. */
+  int mpc860c0;
+
+  /* The function to call when the executable or shared object is
+     loaded.  */
+  const char *init_function;
+  /* The function to call when the executable or shared object is
+     unloaded.  */
+  const char *fini_function;
+};
+
+/* This structures holds a set of callback functions.  These are
+   called by the BFD linker routines.  The first argument to each
+   callback function is the bfd_link_info structure being used.  Each
+   function returns a boolean value.  If the function returns false,
+   then the BFD function which called it will return with a failure
+   indication.  */
+
+struct bfd_link_callbacks
+{
+  /* A function which is called when an object is added from an
+     archive.  ABFD is the archive element being added.  NAME is the
+     name of the symbol which caused the archive element to be pulled
+     in.  */
+  boolean (*add_archive_element) PARAMS ((struct bfd_link_info *,
+					  bfd *abfd,
+					  const char *name));
+  /* A function which is called when a symbol is found with multiple
+     definitions.  NAME is the symbol which is defined multiple times.
+     OBFD is the old BFD, OSEC is the old section, OVAL is the old
+     value, NBFD is the new BFD, NSEC is the new section, and NVAL is
+     the new value.  OBFD may be NULL.  OSEC and NSEC may be
+     bfd_com_section or bfd_ind_section.  */
+  boolean (*multiple_definition) PARAMS ((struct bfd_link_info *,
+					  const char *name,
+					  bfd *obfd,
+					  asection *osec,
+					  bfd_vma oval,
+					  bfd *nbfd,
+					  asection *nsec,
+					  bfd_vma nval));
+  /* A function which is called when a common symbol is defined
+     multiple times.  NAME is the symbol appearing multiple times.
+     OBFD is the BFD of the existing symbol; it may be NULL if this is
+     not known.  OTYPE is the type of the existing symbol, which may
+     be bfd_link_hash_defined, bfd_link_hash_defweak,
+     bfd_link_hash_common, or bfd_link_hash_indirect.  If OTYPE is
+     bfd_link_hash_common, OSIZE is the size of the existing symbol.
+     NBFD is the BFD of the new symbol.  NTYPE is the type of the new
+     symbol, one of bfd_link_hash_defined, bfd_link_hash_common, or
+     bfd_link_hash_indirect.  If NTYPE is bfd_link_hash_common, NSIZE
+     is the size of the new symbol.  */
+  boolean (*multiple_common) PARAMS ((struct bfd_link_info *,
+				      const char *name,
+				      bfd *obfd,
+				      enum bfd_link_hash_type otype,
+				      bfd_vma osize,
+				      bfd *nbfd,
+				      enum bfd_link_hash_type ntype,
+				      bfd_vma nsize));
+  /* A function which is called to add a symbol to a set.  ENTRY is
+     the link hash table entry for the set itself (e.g.,
+     __CTOR_LIST__).  RELOC is the relocation to use for an entry in
+     the set when generating a relocateable file, and is also used to
+     get the size of the entry when generating an executable file.
+     ABFD, SEC and VALUE identify the value to add to the set.  */
+  boolean (*add_to_set) PARAMS ((struct bfd_link_info *,
+				 struct bfd_link_hash_entry *entry,
+				 bfd_reloc_code_real_type reloc,
+				 bfd *abfd, asection *sec, bfd_vma value));
+  /* A function which is called when the name of a g++ constructor or
+     destructor is found.  This is only called by some object file
+     formats.  CONSTRUCTOR is true for a constructor, false for a
+     destructor.  This will use BFD_RELOC_CTOR when generating a
+     relocateable file.  NAME is the name of the symbol found.  ABFD,
+     SECTION and VALUE are the value of the symbol.  */
+  boolean (*constructor) PARAMS ((struct bfd_link_info *,
+				  boolean constructor,
+				  const char *name, bfd *abfd, asection *sec,
+				  bfd_vma value));
+  /* A function which is called to issue a linker warning.  For
+     example, this is called when there is a reference to a warning
+     symbol.  WARNING is the warning to be issued.  SYMBOL is the name
+     of the symbol which triggered the warning; it may be NULL if
+     there is none.  ABFD, SECTION and ADDRESS identify the location
+     which trigerred the warning; either ABFD or SECTION or both may
+     be NULL if the location is not known.  */
+  boolean (*warning) PARAMS ((struct bfd_link_info *,
+			      const char *warning, const char *symbol,
+			      bfd *abfd, asection *section,
+			      bfd_vma address));
+  /* A function which is called when a relocation is attempted against
+     an undefined symbol.  NAME is the symbol which is undefined.
+     ABFD, SECTION and ADDRESS identify the location from which the
+     reference is made. FATAL indicates whether an undefined symbol is
+     a fatal error or not. In some cases SECTION may be NULL.  */
+  boolean (*undefined_symbol) PARAMS ((struct bfd_link_info *,
+				       const char *name, bfd *abfd,
+				       asection *section,
+				       bfd_vma address,
+				       boolean fatal));
+  /* A function which is called when a reloc overflow occurs.  NAME is
+     the name of the symbol or section the reloc is against,
+     RELOC_NAME is the name of the relocation, and ADDEND is any
+     addend that is used.  ABFD, SECTION and ADDRESS identify the
+     location at which the overflow occurs; if this is the result of a
+     bfd_section_reloc_link_order or bfd_symbol_reloc_link_order, then
+     ABFD will be NULL.  */
+  boolean (*reloc_overflow) PARAMS ((struct bfd_link_info *,
+				     const char *name,
+				     const char *reloc_name, bfd_vma addend,
+				     bfd *abfd, asection *section,
+				     bfd_vma address));
+  /* A function which is called when a dangerous reloc is performed.
+     The canonical example is an a29k IHCONST reloc which does not
+     follow an IHIHALF reloc.  MESSAGE is an appropriate message.
+     ABFD, SECTION and ADDRESS identify the location at which the
+     problem occurred; if this is the result of a
+     bfd_section_reloc_link_order or bfd_symbol_reloc_link_order, then
+     ABFD will be NULL.  */
+  boolean (*reloc_dangerous) PARAMS ((struct bfd_link_info *,
+				      const char *message,
+				      bfd *abfd, asection *section,
+				      bfd_vma address));
+  /* A function which is called when a reloc is found to be attached
+     to a symbol which is not being written out.  NAME is the name of
+     the symbol.  ABFD, SECTION and ADDRESS identify the location of
+     the reloc; if this is the result of a
+     bfd_section_reloc_link_order or bfd_symbol_reloc_link_order, then
+     ABFD will be NULL.  */
+  boolean (*unattached_reloc) PARAMS ((struct bfd_link_info *,
+				       const char *name,
+				       bfd *abfd, asection *section,
+				       bfd_vma address));
+  /* A function which is called when a symbol in notice_hash is
+     defined or referenced.  NAME is the symbol.  ABFD, SECTION and
+     ADDRESS are the value of the symbol.  If SECTION is
+     bfd_und_section, this is a reference.  */
+  boolean (*notice) PARAMS ((struct bfd_link_info *, const char *name,
+			     bfd *abfd, asection *section, bfd_vma address));
+};
+
+/* The linker builds link_order structures which tell the code how to
+   include input data in the output file.  */
+
+/* These are the types of link_order structures.  */
+
+enum bfd_link_order_type
+{
+  bfd_undefined_link_order,	/* Undefined.  */
+  bfd_indirect_link_order,	/* Built from a section.  */
+  bfd_fill_link_order,		/* Fill with a 16 bit constant.  */
+  bfd_data_link_order,		/* Set to explicit data.  */
+  bfd_section_reloc_link_order,	/* Relocate against a section.  */
+  bfd_symbol_reloc_link_order	/* Relocate against a symbol.  */
+};
+
+/* This is the link_order structure itself.  These form a chain
+   attached to the section whose contents they are describing.  */
+
+struct bfd_link_order 
+{
+  /* Next link_order in chain.  */
+  struct bfd_link_order *next;
+  /* Type of link_order.  */
+  enum bfd_link_order_type type;
+  /* Offset within output section.  */
+  bfd_vma offset;  
+  /* Size within output section.  */
+  bfd_size_type size;
+  /* Type specific information.  */
+  union 
+    {
+      struct 
+	{
+	  /* Section to include.  If this is used, then
+	     section->output_section must be the section the
+	     link_order is attached to, section->output_offset must
+	     equal the link_order offset field, and section->_raw_size
+	     must equal the link_order size field.  Maybe these
+	     restrictions should be relaxed someday.  */
+	  asection *section;
+	} indirect;
+      struct
+	{
+	  /* Value to fill with.  */
+	  unsigned int value;
+	} fill;
+      struct
+	{
+	  /* Data to put into file.  The size field gives the number
+	     of bytes which this field points to.  */
+	  bfd_byte *contents;
+	} data;
+      struct
+	{
+	  /* Description of reloc to generate.  Used for
+	     bfd_section_reloc_link_order and
+	     bfd_symbol_reloc_link_order.  */
+	  struct bfd_link_order_reloc *p;
+	} reloc;
+    } u;
+};
+
+/* A linker order of type bfd_section_reloc_link_order or
+   bfd_symbol_reloc_link_order means to create a reloc against a
+   section or symbol, respectively.  This is used to implement -Ur to
+   generate relocs for the constructor tables.  The
+   bfd_link_order_reloc structure describes the reloc that BFD should
+   create.  It is similar to a arelent, but I didn't use arelent
+   because the linker does not know anything about most symbols, and
+   any asymbol structure it creates will be partially meaningless.
+   This information could logically be in the bfd_link_order struct,
+   but I didn't want to waste the space since these types of relocs
+   are relatively rare.  */
+
+struct bfd_link_order_reloc
+{
+  /* Reloc type.  */
+  bfd_reloc_code_real_type reloc;
+
+  union
+    {
+      /* For type bfd_section_reloc_link_order, this is the section
+	 the reloc should be against.  This must be a section in the
+	 output BFD, not any of the input BFDs.  */
+      asection *section;
+      /* For type bfd_symbol_reloc_link_order, this is the name of the
+	 symbol the reloc should be against.  */
+      const char *name;
+    } u;
+
+  /* Addend to use.  The object file should contain zero.  The BFD
+     backend is responsible for filling in the contents of the object
+     file correctly.  For some object file formats (e.g., COFF) the
+     addend must be stored into in the object file, and for some
+     (e.g., SPARC a.out) it is kept in the reloc.  */
+  bfd_vma addend;
+};
+
+/* Allocate a new link_order for a section.  */
+extern struct bfd_link_order *bfd_new_link_order PARAMS ((bfd *, asection *));
+
+/* These structures are used to describe version information for the
+   ELF linker.  These structures could be manipulated entirely inside
+   BFD, but it would be a pain.  Instead, the regular linker sets up
+   these structures, and then passes them into BFD.  */
+
+/* Regular expressions for a version.  */
+
+struct bfd_elf_version_expr
+{
+  /* Next regular expression for this version.  */
+  struct bfd_elf_version_expr *next;
+  /* Regular expression.  */
+  const char *pattern;
+  /* Matching function.  */
+  int (*match) PARAMS((struct bfd_elf_version_expr *, const char *));
+};
+
+/* Version dependencies.  */
+
+struct bfd_elf_version_deps
+{
+  /* Next dependency for this version.  */
+  struct bfd_elf_version_deps *next;
+  /* The version which this version depends upon.  */
+  struct bfd_elf_version_tree *version_needed;
+};
+
+/* A node in the version tree.  */
+
+struct bfd_elf_version_tree
+{
+  /* Next version.  */
+  struct bfd_elf_version_tree *next;
+  /* Name of this version.  */
+  const char *name;
+  /* Version number.  */
+  unsigned int vernum;
+  /* Regular expressions for global symbols in this version.  */
+  struct bfd_elf_version_expr *globals;
+  /* Regular expressions for local symbols in this version.  */
+  struct bfd_elf_version_expr *locals;
+  /* List of versions which this version depends upon.  */
+  struct bfd_elf_version_deps *deps;
+  /* Index of the version name.  This is used within BFD.  */
+  unsigned int name_indx;
+  /* Whether this version tree was used.  This is used within BFD.  */
+  int used;
+};
+
+#endif

usr/local/nachos/info/cpp.info

@@ -0,0 +1,80 @@
+This is Info file cpp.info, produced by Makeinfo version 1.68 from the
+input file ../../gcc-2.95.2/gcc/cpp.texi.
+
+INFO-DIR-SECTION Programming
+START-INFO-DIR-ENTRY
+* Cpp: (cpp).		       The GNU C preprocessor.
+END-INFO-DIR-ENTRY
+
+   This file documents the GNU C Preprocessor.
+
+   Copyright 1987, 1989, 1991, 1992, 1993, 1994, 1995, 1997, 1998 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.
+
+
+Indirect:
+cpp.info-1: 947
+cpp.info-2: 50078
+cpp.info-3: 91263
+
+Tag Table:
+(Indirect)
+Node: Top947
+Node: Global Actions3856
+Node: Directives6376
+Node: Header Files8063
+Node: Header Uses8722
+Node: Include Syntax10214
+Node: Include Operation13356
+Node: Once-Only15218
+Node: Inheritance17643
+Node: Macros20176
+Node: Simple Macros21090
+Node: Argument Macros24078
+Node: Predefined29876
+Node: Standard Predefined30306
+Node: Nonstandard Predefined37964
+Node: Stringification41540
+Node: Concatenation44466
+Node: Undefining47739
+Node: Redefining48778
+Node: Macro Pitfalls50078
+Node: Misnesting51182
+Node: Macro Parentheses52196
+Node: Swallow Semicolon54064
+Node: Side Effects55962
+Node: Self-Reference57660
+Node: Argument Prescan59936
+Node: Cascaded Macros64938
+Node: Newlines in Args66083
+Node: Conditionals67428
+Node: Conditional Uses68780
+Node: Conditional Syntax70203
+Node: #if Directive70789
+Node: #else Directive73078
+Node: #elif Directive73745
+Node: Deleted Code75123
+Node: Conditionals-Macros76184
+Node: Assertions79869
+Node: #error Directive84104
+Node: Combining Sources85589
+Node: Other Directives88500
+Node: Output89954
+Node: Invocation91263
+Node: Concept Index106047
+Node: Index109059
+
+End Tag Table

usr/local/nachos/info/cpp.info-3

@@ -0,0 +1,558 @@
+This is Info file cpp.info, produced by Makeinfo version 1.68 from the
+input file ../../gcc-2.95.2/gcc/cpp.texi.
+
+INFO-DIR-SECTION Programming
+START-INFO-DIR-ENTRY
+* Cpp: (cpp).		       The GNU C preprocessor.
+END-INFO-DIR-ENTRY
+
+   This file documents the GNU C Preprocessor.
+
+   Copyright 1987, 1989, 1991, 1992, 1993, 1994, 1995, 1997, 1998 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.
+
+
+File: cpp.info,  Node: Invocation,  Next: Concept Index,  Prev: Output,  Up: Top
+
+Invoking the C Preprocessor
+===========================
+
+   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.
+
+   The C preprocessor expects two file names as arguments, INFILE and
+OUTFILE.  The preprocessor reads INFILE together with any other files
+it specifies with `#include'.  All the output generated by the combined
+input files is written in OUTFILE.
+
+   Either INFILE or OUTFILE may be `-', which as INFILE means to read
+from standard input and as OUTFILE means to write to standard output.
+Also, if OUTFILE or both file names are omitted, the standard output
+and standard input are used for the omitted file names.
+
+   Here is a table of command options accepted by the C preprocessor.
+These options can also be given when compiling a C program; they are
+passed along automatically to the preprocessor when it is invoked by the
+compiler.
+
+`-P'
+     Inhibit generation of `#'-lines with line-number information in
+     the output from the preprocessor (*note Output::.).  This might be
+     useful when running the preprocessor on something that is not C
+     code and will be sent to a program which might be confused by the
+     `#'-lines.
+
+`-C'
+     Do not discard comments: pass them through to the output file.
+     Comments appearing in arguments of a macro call will be copied to
+     the output before the expansion of the macro call.
+
+`-traditional'
+     Try to imitate the behavior of old-fashioned C, as opposed to ANSI
+     C.
+
+        * Traditional macro expansion pays no attention to singlequote
+          or doublequote characters; macro argument symbols are
+          replaced by the argument values even when they appear within
+          apparent string or character constants.
+
+        * Traditionally, it is permissible for a macro expansion to end
+          in the middle of a string or character constant.  The
+          constant continues into the text surrounding the macro call.
+
+        * However, traditionally the end of the line terminates a
+          string or character constant, with no error.
+
+        * In traditional C, a comment is equivalent to no text at all.
+          (In ANSI C, a comment counts as whitespace.)
+
+        * Traditional C does not have the concept of a "preprocessing
+          number".  It considers `1.0e+4' to be three tokens: `1.0e',
+          `+', and `4'.
+
+        * A macro is not suppressed within its own definition, in
+          traditional C.  Thus, any macro that is used recursively
+          inevitably causes an error.
+
+        * The character `#' has no special meaning within a macro
+          definition in traditional C.
+
+        * In traditional C, the text at the end of a macro expansion
+          can run together with the text after the macro call, to
+          produce a single token.  (This is impossible in ANSI C.)
+
+        * Traditionally, `\' inside a macro argument suppresses the
+          syntactic significance of the following character.
+
+     Use the `-traditional' option when preprocessing Fortran code, so
+     that singlequotes and doublequotes within Fortran comment lines
+     (which are generally not recognized as such by the preprocessor)
+     do not cause diagnostics about unterminated character or string
+     constants.
+
+     However, this option does not prevent diagnostics about
+     unterminated comments when a C-style comment appears to start, but
+     not end, within Fortran-style commentary.
+
+     So, the following Fortran comment lines are accepted with
+     `-traditional':
+
+          C This isn't an unterminated character constant
+          C Neither is "20000000000, an octal constant
+          C in some dialects of Fortran
+
+     However, this type of comment line will likely produce a
+     diagnostic, or at least unexpected output from the preprocessor,
+     due to the unterminated comment:
+
+          C Some Fortran compilers accept /* as starting
+          C an inline comment.
+
+     Note that `g77' automatically supplies the `-traditional' option
+     when it invokes the preprocessor.  However, a future version of
+     `g77' might use a different, more-Fortran-aware preprocessor in
+     place of `cpp'.
+
+`-trigraphs'
+     Process ANSI standard trigraph sequences.  These are
+     three-character sequences, all starting with `??', that are
+     defined by ANSI C to stand for single characters.  For example,
+     `??/' stands for `\', so `'??/n'' is a character constant for a
+     newline.  Strictly speaking, the GNU C preprocessor does not
+     support all programs in ANSI Standard C unless `-trigraphs' is
+     used, but if you ever notice the difference it will be with relief.
+
+     You don't want to know any more about trigraphs.
+
+`-pedantic'
+     Issue warnings required by the ANSI C standard in certain cases
+     such as when text other than a comment follows `#else' or `#endif'.
+
+`-pedantic-errors'
+     Like `-pedantic', except that errors are produced rather than
+     warnings.
+
+`-Wtrigraphs'
+     Warn if any trigraphs are encountered.  Currently this only works
+     if you have turned trigraphs on with `-trigraphs' or `-ansi'; in
+     the future this restriction will be removed.
+
+`-Wcomment'
+     Warn whenever a comment-start sequence `/*' appears in a `/*'
+     comment, or whenever a Backslash-Newline appears in a `//' comment.
+
+`-Wall'
+     Requests both `-Wtrigraphs' and `-Wcomment' (but not
+     `-Wtraditional' or `-Wundef').
+
+`-Wtraditional'
+     Warn about certain constructs that behave differently in
+     traditional and ANSI C.
+
+`-Wundef'
+     Warn if an undefined identifier is evaluated in an `#if' directive.
+
+`-I DIRECTORY'
+     Add the directory DIRECTORY to the head of the list of directories
+     to be searched for header files (*note Include Syntax::.).  This
+     can be used to override a system header file, substituting your
+     own version, since these directories are searched before the system
+     header file directories.  If you use more than one `-I' option,
+     the directories are scanned in left-to-right order; the standard
+     system directories come after.
+
+`-I-'
+     Any directories specified with `-I' options before the `-I-'
+     option are searched only for the case of `#include "FILE"'; they
+     are not searched for `#include <FILE>'.
+
+     If additional directories are specified with `-I' options after
+     the `-I-', these directories are searched for all `#include'
+     directives.
+
+     In addition, the `-I-' option inhibits the use of the current
+     directory as the first search directory for `#include "FILE"'.
+     Therefore, the current directory is searched only if it is
+     requested explicitly with `-I.'.  Specifying both `-I-' and `-I.'
+     allows you to control precisely which directories are searched
+     before the current one and which are searched after.
+
+`-nostdinc'
+     Do not search the standard system directories for header files.
+     Only the directories you have specified with `-I' options (and the
+     current directory, if appropriate) are searched.
+
+`-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.)
+
+`-remap'
+     When searching for a header file in a directory, remap file names
+     if a file named `header.gcc' exists in that directory.  This can
+     be used to work around limitations of file systems with file name
+     restrictions.  The `header.gcc' file should contain a series of
+     lines with two tokens on each line: the first token is the name to
+     map, and the second token is the actual name to use.
+
+`-D NAME'
+     Predefine NAME as a macro, with definition `1'.
+
+`-D NAME=DEFINITION'
+     Predefine NAME as a macro, with definition DEFINITION.  There are
+     no restrictions on the contents of DEFINITION, but 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
+     use more than one `-D' for the same NAME, the rightmost definition
+     takes effect.
+
+`-U NAME'
+     Do not predefine NAME.  If both `-U' and `-D' are specified for
+     one name, the `-U' beats the `-D' and the name is not predefined.
+
+`-undef'
+     Do not predefine any nonstandard macros.
+
+`-gcc'
+     Define the macros __GNUC__ and __GNUC_MINOR__.  These are defined
+     automatically when you use `gcc -E'; you can turn them off in that
+     case with `-no-gcc'.
+
+`-A PREDICATE(ANSWER)'
+     Make an assertion with the predicate PREDICATE and answer ANSWER.
+     *Note Assertions::.
+
+     You can use `-A-' to disable all predefined assertions; it also
+     undefines all predefined macros and all macros that preceded it on
+     the command line.
+
+`-dM'
+     Instead of outputting the result of preprocessing, output a list of
+     `#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 `foo.h', the command
+
+          touch foo.h; cpp -dM foo.h
+
+     will show the values of any predefined macros.
+
+`-dD'
+     Like `-dM' except in two respects: it does *not* include the
+     predefined macros, and it outputs *both* the `#define' directives
+     and the result of preprocessing.  Both kinds of output go to the
+     standard output file.
+
+`-dI'
+     Output `#include' directives in addition to the result of
+     preprocessing.
+
+`-M [-MG]'
+     Instead of outputting the result of preprocessing, output a rule
+     suitable for `make' describing the dependencies of the main source
+     file.  The preprocessor outputs one `make' rule containing the
+     object file name for that source file, a colon, and the names of
+     all the included files.  If there are many included files then the
+     rule is split into several lines using `\'-newline.
+
+     `-MG' says to treat missing header files as generated files and
+     assume they live in the same directory as the source file.  It
+     must be specified in addition to `-M'.
+
+     This feature is used in automatic updating of makefiles.
+
+`-MM [-MG]'
+     Like `-M' but mention only the files included with `#include
+     "FILE"'.  System header files included with `#include <FILE>' are
+     omitted.
+
+`-MD FILE'
+     Like `-M' but the dependency information is written to FILE.  This
+     is in addition to compiling the file as specified--`-MD' does not
+     inhibit ordinary compilation the way `-M' does.
+
+     When invoking `gcc', do not specify the FILE argument.  `gcc' will
+     create file names made by replacing ".c" with ".d" at the end of
+     the input file names.
+
+     In Mach, you can use the utility `md' to merge multiple dependency
+     files into a single dependency file suitable for using with the
+     `make' command.
+
+`-MMD FILE'
+     Like `-MD' except mention only user header files, not system
+     header files.
+
+`-H'
+     Print the name of each header file used, in addition to other
+     normal activities.
+
+`-imacros FILE'
+     Process FILE as input, discarding the resulting output, before
+     processing the regular input file.  Because the output generated
+     from FILE is discarded, the only effect of `-imacros FILE' is to
+     make the macros defined in FILE available for use in the main
+     input.
+
+`-include FILE'
+     Process FILE as input, and include all the resulting output,
+     before processing the regular input file.
+
+`-idirafter DIR'
+     Add the directory DIR to the second include path.  The directories
+     on the second include path are searched when a header file is not
+     found in any of the directories in the main include path (the one
+     that `-I' adds to).
+
+`-iprefix PREFIX'
+     Specify PREFIX as the prefix for subsequent `-iwithprefix' options.
+
+`-iwithprefix DIR'
+     Add a directory to the second include path.  The directory's name
+     is made by concatenating PREFIX and DIR, where PREFIX was
+     specified previously with `-iprefix'.
+
+`-isystem DIR'
+     Add a directory to the beginning of the second include path,
+     marking it as a system directory, so that it gets the same special
+     treatment as is applied to the standard system directories.
+
+`-x c'
+`-x c++'
+`-x objective-c'
+`-x assembler-with-cpp'
+     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: `.c', `.cc', `.m', or `.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.
+
+     *Note:* Previous versions of cpp accepted a `-lang' option which
+     selected both the language and the standards conformance level.
+     This option has been removed, because it conflicts with the `-l'
+     option.
+
+`-std=STANDARD'
+`-ansi'
+     Specify the standard to which the code should conform.  Currently
+     cpp only knows about the standards for C; other language standards
+     will be added in the future.
+
+     STANDARD may be one of:
+    `iso9899:1990'
+          The ISO C standard from 1990.
+
+    `iso9899:199409'
+    `c89'
+          The 1990 C standard, as amended in 1994.  `c89' is the
+          customary shorthand for this version of the standard.
+
+          The `-ansi' option is equivalent to `-std=c89'.
+
+    `iso9899:199x'
+    `c9x'
+          The revised ISO C standard, which is expected to be
+          promulgated some time in 1999.  It has not been approved yet,
+          hence the `x'.
+
+    `gnu89'
+          The 1990 C standard plus GNU extensions.  This is the default.
+
+    `gnu9x'
+          The 199x C standard plus GNU extensions.
+
+`-Wp,-lint'
+     Look for commands to the program checker `lint' embedded in
+     comments, and emit them preceded by `#pragma lint'.  For example,
+     the comment `/* NOTREACHED */' becomes `#pragma lint NOTREACHED'.
+
+     Because of the clash with `-l', you must use the awkward syntax
+     above.  In a future release, this option will be replaced by
+     `-flint' or `-Wlint'; we are not sure which yet.
+
+`-$'
+     Forbid the use of `$' in identifiers.  The C standard does not
+     permit this, but it is a common extension.
+
+
+File: cpp.info,  Node: Concept Index,  Next: Index,  Prev: Invocation,  Up: Top
+
+Concept Index
+*************
+
+* Menu:
+
+* ##:                                    Concatenation.
+* arguments in macro definitions:        Argument Macros.
+* assertions:                            Assertions.
+* assertions, undoing:                   Assertions.
+* blank macro arguments:                 Argument Macros.
+* cascaded macros:                       Cascaded Macros.
+* commenting out code:                   Deleted Code.
+* computed #include:                     Include Syntax.
+* concatenation:                         Concatenation.
+* conditionals:                          Conditionals.
+* directives:                            Directives.
+* expansion of arguments:                Argument Prescan.
+* Fortran:                               Invocation.
+* function-like macro:                   Argument Macros.
+* g77:                                   Invocation.
+* header file:                           Header Files.
+* including just once:                   Once-Only.
+* inheritance:                           Inheritance.
+* invocation of the preprocessor:        Invocation.
+* line control:                          Combining Sources.
+* macro argument expansion:              Argument Prescan.
+* macro body uses macro:                 Cascaded Macros.
+* macros with argument:                  Argument Macros.
+* manifest constant:                     Simple Macros.
+* newlines in macro arguments:           Newlines in Args.
+* null directive:                        Other Directives.
+* options:                               Invocation.
+* output format:                         Output.
+* overriding a header file:              Inheritance.
+* parentheses in macro bodies:           Macro Parentheses.
+* pitfalls of macros:                    Macro Pitfalls.
+* predefined macros:                     Predefined.
+* predicates:                            Assertions.
+* preprocessing directives:              Directives.
+* prescan of macro arguments:            Argument Prescan.
+* problems with macros:                  Macro Pitfalls.
+* redefining macros:                     Redefining.
+* repeated inclusion:                    Once-Only.
+* retracting assertions:                 Assertions.
+* second include path:                   Invocation.
+* self-reference:                        Self-Reference.
+* semicolons (after macro calls):        Swallow Semicolon.
+* side effects (in macro arguments):     Side Effects.
+* simple macro:                          Simple Macros.
+* space as macro argument:               Argument Macros.
+* standard predefined macros:            Standard Predefined.
+* stringification:                       Stringification.
+* testing predicates:                    Assertions.
+* unassert:                              Assertions.
+* undefining macros:                     Undefining.
+* unsafe macros:                         Side Effects.
+* unterminated:                          Invocation.
+
+
+File: cpp.info,  Node: Index,  Prev: Concept Index,  Up: Top
+
+Index of Directives, Macros and Options
+***************************************
+
+* Menu:
+
+* #assert:                               Assertions.
+* #cpu:                                  Assertions.
+* #define:                               Argument Macros.
+* #elif:                                 #elif Directive.
+* #else:                                 #else Directive.
+* #error:                                #error Directive.
+* #ident:                                Other Directives.
+* #if:                                   Conditional Syntax.
+* #ifdef:                                Conditionals-Macros.
+* #ifndef:                               Conditionals-Macros.
+* #import:                               Once-Only.
+* #include:                              Include Syntax.
+* #include_next:                         Inheritance.
+* #line:                                 Combining Sources.
+* #machine:                              Assertions.
+* #pragma:                               Other Directives.
+* #pragma once:                          Once-Only.
+* #system:                               Assertions.
+* #unassert:                             Assertions.
+* #warning:                              #error Directive.
+* -$:                                    Invocation.
+* -A:                                    Invocation.
+* -ansi:                                 Invocation.
+* -C:                                    Invocation.
+* -D:                                    Invocation.
+* -dD:                                   Invocation.
+* -dI:                                   Invocation.
+* -dM:                                   Invocation.
+* -gcc:                                  Invocation.
+* -H:                                    Invocation.
+* -I:                                    Invocation.
+* -idirafter:                            Invocation.
+* -imacros:                              Invocation.
+* -include:                              Invocation.
+* -iprefix:                              Invocation.
+* -isystem:                              Invocation.
+* -iwithprefix:                          Invocation.
+* -lint:                                 Invocation.
+* -M:                                    Invocation.
+* -MD:                                   Invocation.
+* -MM:                                   Invocation.
+* -MMD:                                  Invocation.
+* -nostdinc:                             Invocation.
+* -nostdinc++:                           Invocation.
+* -P:                                    Invocation.
+* -pedantic:                             Invocation.
+* -pedantic-errors:                      Invocation.
+* -remap:                                Invocation.
+* -std:                                  Invocation.
+* -traditional:                          Invocation.
+* -trigraphs:                            Invocation.
+* -U:                                    Invocation.
+* -undef:                                Invocation.
+* -Wall:                                 Invocation.
+* -Wcomment:                             Invocation.
+* -Wtraditional:                         Invocation.
+* -Wtrigraphs:                           Invocation.
+* -Wundef:                               Invocation.
+* -x assembler-with-cpp:                 Invocation.
+* -x c:                                  Invocation.
+* -x objective-c:                        Invocation.
+* __BASE_FILE__:                         Standard Predefined.
+* __CHAR_UNSIGNED__:                     Standard Predefined.
+* __cplusplus:                           Standard Predefined.
+* __DATE__:                              Standard Predefined.
+* __FILE__:                              Standard Predefined.
+* __GNUC__:                              Standard Predefined.
+* __GNUC_MINOR__:                        Standard Predefined.
+* __GNUG__:                              Standard Predefined.
+* __INCLUDE_LEVEL_:                      Standard Predefined.
+* __LINE__:                              Standard Predefined.
+* __OPTIMIZE__:                          Standard Predefined.
+* __REGISTER_PREFIX__:                   Standard Predefined.
+* __STDC__:                              Standard Predefined.
+* __STDC_VERSION__:                      Standard Predefined.
+* __STRICT_ANSI__:                       Standard Predefined.
+* __TIME__:                              Standard Predefined.
+* __USER_LABEL_PREFIX__:                 Standard Predefined.
+* __VERSION__:                           Standard Predefined.
+* _AM29000:                              Nonstandard Predefined.
+* _AM29K:                                Nonstandard Predefined.
+* BSD:                                   Nonstandard Predefined.
+* defined:                               Conditionals-Macros.
+* M68020:                                Nonstandard Predefined.
+* m68k:                                  Nonstandard Predefined.
+* mc68000:                               Nonstandard Predefined.
+* ns32000:                               Nonstandard Predefined.
+* pyr:                                   Nonstandard Predefined.
+* sequent:                               Nonstandard Predefined.
+* sun:                                   Nonstandard Predefined.
+* system header files:                   Header Uses.
+* unix:                                  Nonstandard Predefined.
+* vax:                                   Nonstandard Predefined.
+
+

usr/local/nachos/info/gcc.info

@@ -0,0 +1,329 @@
+This is Info file gcc.info, produced by Makeinfo version 1.68 from the
+input file ../../gcc-2.95.2/gcc/gcc.texi.
+
+INFO-DIR-SECTION Programming
+START-INFO-DIR-ENTRY
+* gcc: (gcc).                  The GNU Compiler Collection.
+END-INFO-DIR-ENTRY
+   This file documents the use and the internals of the GNU compiler.
+
+   Published by the Free Software Foundation 59 Temple Place - Suite 330
+Boston, MA 02111-1307 USA
+
+   Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
+1999 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 sections entitled "GNU General Public License" and "Funding
+for Free Software" are included exactly as in the original, and
+provided 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, except that the sections entitled "GNU General Public
+License" and "Funding for Free Software", and this permission notice,
+may be included in translations approved by the Free Software Foundation
+instead of in the original English.
+
+
+Indirect:
+gcc.info-1: 1468
+gcc.info-2: 42003
+gcc.info-3: 75234
+gcc.info-4: 122510
+gcc.info-5: 166689
+gcc.info-6: 213193
+gcc.info-7: 260569
+gcc.info-8: 302186
+gcc.info-9: 349051
+gcc.info-10: 399031
+gcc.info-11: 440266
+gcc.info-12: 488386
+gcc.info-13: 529896
+gcc.info-14: 578788
+gcc.info-15: 626050
+gcc.info-16: 671156
+gcc.info-17: 721050
+gcc.info-18: 769831
+gcc.info-19: 816705
+gcc.info-20: 865531
+gcc.info-21: 915283
+gcc.info-22: 952344
+gcc.info-23: 994139
+gcc.info-24: 1039021
+gcc.info-25: 1084921
+gcc.info-26: 1129014
+gcc.info-27: 1178605
+gcc.info-28: 1218283
+gcc.info-29: 1263090
+gcc.info-30: 1287554
+
+Tag Table:
+(Indirect)
+Node: Top1468
+Node: G++ and GCC3229
+Node: Invoking GCC5627
+Node: Option Summary8988
+Node: Overall Options23740
+Node: Invoking G++28760
+Node: C Dialect Options30217
+Node: C++ Dialect Options42003
+Node: Warning Options57982
+Node: Debugging Options75234
+Node: Optimize Options92302
+Node: Preprocessor Options109774
+Node: Assembler Options116237
+Node: Link Options116604
+Node: Directory Options122510
+Node: Target Options126375
+Node: Submodel Options130006
+Node: M680x0 Options131556
+Node: VAX Options137072
+Node: SPARC Options137607
+Node: Convex Options147471
+Node: AMD29K Options149652
+Node: ARM Options153048
+Node: Thumb Options161069
+Node: MN10200 Options163039
+Node: MN10300 Options163563
+Node: M32R/D Options164339
+Node: M88K Options166689
+Node: RS/6000 and PowerPC Options174627
+Node: RT Options193741
+Node: MIPS Options195445
+Node: i386 Options205190
+Node: HPPA Options213193
+Node: Intel 960 Options217464
+Node: DEC Alpha Options220406
+Node: Clipper Options229800
+Node: H8/300 Options230199
+Node: SH Options231013
+Node: System V Options231832
+Node: TMS320C3x/C4x Options232650
+Node: V850 Options238155
+Node: ARC Options240164
+Node: NS32K Options241366
+Node: Code Gen Options245586
+Node: Environment Variables260569
+Node: Running Protoize266755
+Node: Installation273121
+Node: Configuration Files300581
+Node: Configurations302186
+Node: Other Dir341310
+Node: Cross-Compiler343026
+Node: Steps of Cross344857
+Node: Configure Cross345975
+Node: Tools and Libraries346612
+Node: Cross Runtime349051
+Node: Cross Headers353132
+Node: Build Cross355131
+Node: Sun Install357007
+Node: VMS Install358679
+Node: Collect2368609
+Node: Header Dirs371174
+Node: C Extensions372598
+Node: Statement Exprs376123
+Node: Local Labels378017
+Node: Labels as Values380079
+Node: Nested Functions381943
+Node: Constructing Calls385786
+Node: Naming Types387843
+Node: Typeof388937
+Node: Lvalues390802
+Node: Conditionals393242
+Node: Long Long394133
+Node: Complex395573
+Node: Hex Floats397434
+Node: Zero Length398354
+Node: Variable Length399031
+Node: Macro Varargs401556
+Node: Subscripting403659
+Node: Pointer Arith404142
+Node: Initializers404707
+Node: Constructors405172
+Node: Labeled Elements406866
+Node: Case Ranges409495
+Node: Cast to Union410176
+Node: Function Attributes411254
+Node: Function Prototypes427178
+Node: C++ Comments428980
+Node: Dollar Signs429516
+Node: Character Escapes429974
+Node: Alignment430261
+Node: Variable Attributes431733
+Node: Type Attributes440266
+Node: Inline449477
+Node: Extended Asm453719
+Node: Asm Labels468652
+Node: Explicit Reg Vars469971
+Node: Global Reg Vars471426
+Node: Local Reg Vars475991
+Node: Alternate Keywords477795
+Node: Incomplete Enums479197
+Node: Function Names479953
+Node: Return Address481227
+Node: Other Builtins483270
+Node: Deprecated Features485736
+Node: C++ Extensions487013
+Node: Naming Results488386
+Node: Min and Max491700
+Node: Destructors and Goto493140
+Node: C++ Interface493616
+Node: Template Instantiation498850
+Node: Bound member functions507465
+Node: C++ Signatures508798
+Node: Gcov513142
+Node: Gcov Intro513665
+Node: Invoking Gcov516346
+Node: Gcov and Optimization521957
+Node: Gcov Data Files523381
+Node: Trouble526951
+Node: Actual Bugs528629
+Node: Installation Problems529896
+Node: Cross-Compiler Problems543574
+Node: Interoperation545045
+Node: External Bugs558323
+Node: Incompatibilities560446
+Node: Fixed Headers568918
+Node: Standard Libraries571228
+Node: Disappointments572469
+Node: C++ Misunderstandings577008
+Node: Static Definitions577734
+Node: Temporaries578788
+Node: Copy Assignment580766
+Node: Protoize Caveats582577
+Node: Non-bugs586533
+Node: Warnings and Errors596164
+Node: Bugs597925
+Node: Bug Criteria599273
+Node: Bug Lists601711
+Node: Bug Reporting602827
+Node: Sending Patches615050
+Node: Service620425
+Node: Contributing620992
+Node: VMS621798
+Node: Include Files and VMS622184
+Node: Global Declarations626050
+Node: VMS Misc630355
+Node: Portability634662
+Node: Interface636411
+Node: Passes640993
+Node: RTL659344
+Node: RTL Objects661312
+Node: RTL Classes664358
+Node: Accessors668776
+Node: Flags671156
+Node: Machine Modes681491
+Node: Constants689125
+Node: Regs and Memory694313
+Node: Arithmetic706789
+Node: Comparisons712687
+Node: Bit Fields716750
+Node: Conversions718162
+Node: RTL Declarations721050
+Node: Side Effects721859
+Node: Incdec734863
+Node: Assembler738364
+Node: Insns739886
+Node: Calls763221
+Node: Sharing765816
+Node: Reading RTL768892
+Node: Machine Desc769831
+Node: Patterns771684
+Node: Example774628
+Node: RTL Template775756
+Node: Output Template788835
+Node: Output Statement792817
+Node: Constraints796530
+Node: Simple Constraints797533
+Node: Multi-Alternative809445
+Node: Class Preferences812281
+Node: Modifiers813161
+Node: Machine Constraints816705
+Node: No Constraints825767
+Node: Standard Names826888
+Node: Pattern Ordering864304
+Node: Dependent Patterns865531
+Node: Jump Patterns868346
+Node: Insn Canonicalizations874162
+Node: Peephole Definitions877657
+Node: Expander Definitions884575
+Node: Insn Splitting891960
+Node: Insn Attributes898891
+Node: Defining Attributes899938
+Node: Expressions901950
+Node: Tagging Insns908544
+Node: Attr Example912907
+Node: Insn Lengths915283
+Node: Constant Attributes918576
+Node: Delay Slots919736
+Node: Function Units922947
+Node: Target Macros928617
+Node: Driver930500
+Node: Run-time Target946047
+Node: Storage Layout952344
+Node: Type Layout969671
+Node: Registers976444
+Node: Register Basics977424
+Node: Allocation Order982220
+Node: Values in Registers983636
+Node: Leaf Functions988756
+Node: Stack Registers991534
+Node: Obsolete Register Macros992367
+Node: Register Classes994139
+Node: Stack and Calling1014146
+Node: Frame Layout1014601
+Node: Stack Checking1020098
+Node: Frame Registers1023678
+Node: Elimination1028093
+Node: Stack Arguments1032349
+Node: Register Arguments1039021
+Node: Scalar Return1049531
+Node: Aggregate Return1053769
+Node: Caller Saves1057484
+Node: Function Entry1059023
+Node: Profiling1069925
+Node: Varargs1077006
+Node: Trampolines1084921
+Node: Library Calls1091639
+Node: Addressing Modes1099697
+Node: Condition Code1110105
+Node: Costs1116304
+Node: Sections1129014
+Node: PIC1135245
+Node: Assembler Format1137954
+Node: File Framework1139020
+Node: Data Output1143718
+Node: Uninitialized Data1150912
+Node: Label Output1156318
+Node: Initialization1167524
+Node: Macros for Initialization1173667
+Node: Instruction Output1178605
+Node: Dispatch Tables1186792
+Node: Exception Region Output1189345
+Node: Alignment Output1192339
+Node: Debugging Info1194562
+Node: All Debuggers1195171
+Node: DBX Options1197999
+Node: DBX Hooks1203282
+Node: File Names and DBX1206922
+Node: SDB and DWARF1208895
+Node: Cross-compilation1211717
+Node: Misc1218283
+Node: Config1242660
+Node: Fragments1249923
+Node: Target Fragment1250519
+Node: Host Fragment1254674
+Node: Funding1255276
+Node: GNU/Linux1257775
+Node: Copying1263090
+Node: Contributors1282278
+Node: Index1287554
+
+End Tag Table

usr/local/nachos/info/gcc.info-1

@@ -0,0 +1,954 @@
+This is Info file gcc.info, produced by Makeinfo version 1.68 from the
+input file ../../gcc-2.95.2/gcc/gcc.texi.
+
+INFO-DIR-SECTION Programming
+START-INFO-DIR-ENTRY
+* gcc: (gcc).                  The GNU Compiler Collection.
+END-INFO-DIR-ENTRY
+   This file documents the use and the internals of the GNU compiler.
+
+   Published by the Free Software Foundation 59 Temple Place - Suite 330
+Boston, MA 02111-1307 USA
+
+   Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
+1999 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 sections entitled "GNU General Public License" and "Funding
+for Free Software" are included exactly as in the original, and
+provided 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, except that the sections entitled "GNU General Public
+License" and "Funding for Free Software", and this permission notice,
+may be included in translations approved by the Free Software Foundation
+instead of in the original English.
+
+
+File: gcc.info,  Node: Top,  Next: G++ and GCC,  Up: (DIR)
+
+Introduction
+************
+
+   This manual documents how to run, install and port the GNU compiler,
+as well as its new features and incompatibilities, and how to report
+bugs.  It corresponds to GCC version 2.95.
+
+* Menu:
+
+
+* G++ and GCC::     You can compile C or C++ programs.
+* Invoking GCC::    Command options supported by `gcc'.
+* Installation::    How to configure, compile and install GCC.
+* C Extensions::    GNU extensions to the C language family.
+* C++ Extensions::  GNU extensions to the C++ language.
+* Gcov::	    gcov: a GCC test coverage program.
+* Trouble::         If you have trouble installing GCC.
+* Bugs::            How, why and where to report bugs.
+* Service::         How to find suppliers of support for GCC.
+* Contributing::    How to contribute to testing and developing GCC.
+* VMS::             Using GCC on VMS.
+
+* Portability::     Goals of GCC's portability features.
+* Interface::       Function-call interface of GCC output.
+* Passes::          Order of passes, what they do, and what each file is for.
+* RTL::             The intermediate representation that most passes work on.
+* Machine Desc::    How to write machine description instruction patterns.
+* Target Macros::   How to write the machine description C macros.
+* Config::          Writing the `xm-MACHINE.h' file.
+* Fragments::       Writing the `t-TARGET' and `x-HOST' files.
+
+* Funding::         How to help assure funding for free software.
+* GNU/Linux::       Linux and the GNU Project
+
+* Copying::         GNU General Public License says
+                     how you can copy and share GCC.
+* Contributors::    People who have contributed to GCC.
+
+* Index::	    Index of concepts and symbol names.
+
+
+File: gcc.info,  Node: G++ and GCC,  Next: Invoking GCC,  Prev: Top,  Up: Top
+
+Compile C, C++, Objective C, or Fortran
+***************************************
+
+   The C, C++, and Objective C, and Fortran versions of the compiler are
+integrated; this is why we use the name "GNU Compiler Collection".  GCC
+can compile programs written in C, C++, Objective C, or Fortran.  The
+Fortran compiler is described in a separate manual.
+
+   "GCC" is a common shorthand term for the GNU Compiler Collection.
+This is both the most general name for the compiler, and the name used
+when the emphasis is on compiling C programs (as the abbreviation
+formerly stood for "GNU C Compiler").
+
+   When referring to C++ compilation, it is usual to call the compiler
+"G++".  Since there is only one compiler, it is also accurate to call
+it "GCC" no matter what the language context; however, the term "G++"
+is more useful when the emphasis is on compiling C++ programs.
+
+   We use the name "GCC" to refer to the compilation system as a whole,
+and more specifically to the language-independent part of the compiler.
+For example, we refer to the optimization options as affecting the
+behavior of "GCC" or sometimes just "the compiler".
+
+   Front ends for other languages, such as Ada 9X, Fortran, Modula-3,
+and Pascal, are under development.  These front-ends, like that for
+C++, are built in subdirectories of GCC and link to it.  The result is
+an integrated compiler that can compile programs written in C, C++,
+Objective C, or any of the languages for which you have installed front
+ends.
+
+   In this manual, we only discuss the options for the C, Objective-C,
+and C++ compilers and those of the GCC core.  Consult the documentation
+of the other front ends for the options to use when compiling programs
+written in other languages.
+
+   G++ is a *compiler*, not merely a preprocessor.  G++ builds object
+code directly from your C++ program source.  There is no intermediate C
+version of the program.  (By contrast, for example, some other
+implementations use a program that generates a C program from your C++
+source.)  Avoiding an intermediate C representation of the program means
+that you get better object code, and better debugging information.  The
+GNU debugger, GDB, works with this information in the object code to
+give you comprehensive C++ source-level editing capabilities (*note C
+and C++: (gdb.info)C.).
+
+
+File: gcc.info,  Node: Invoking GCC,  Next: Installation,  Prev: G++ and GCC,  Up: Top
+
+GCC Command Options
+*******************
+
+   When you invoke GCC, it normally does preprocessing, compilation,
+assembly and linking.  The "overall options" allow you to stop this
+process at an intermediate stage.  For example, the `-c' option says
+not to run the linker.  Then the output consists of object files output
+by the assembler.
+
+   Other options are passed on to one stage of processing.  Some options
+control the preprocessor and others the compiler itself.  Yet other
+options control the assembler and linker; most of these are not
+documented here, since you rarely need to use any of them.
+
+   Most of the command line options that you can use with GCC are useful
+for C programs; when an option is only useful with another language
+(usually C++), the explanation says so explicitly.  If the description
+for a particular option does not mention a source language, you can use
+that option with all supported languages.
+
+   *Note Compiling C++ Programs: Invoking G++, for a summary of special
+options for compiling C++ programs.
+
+   The `gcc' program accepts options and file names as operands.  Many
+options have multiletter names; therefore multiple single-letter options
+may *not* be grouped: `-dr' is very different from `-d -r'.
+
+   You can mix options and other arguments.  For the most part, the
+order you use doesn't matter.  Order does matter when you use several
+options of the same kind; for example, if you specify `-L' more than
+once, the directories are searched in the order specified.
+
+   Many options have long names starting with `-f' or with `-W'--for
+example, `-fforce-mem', `-fstrength-reduce', `-Wformat' and so on.
+Most of these have both positive and negative forms; the negative form
+of `-ffoo' would be `-fno-foo'.  This manual documents only one of
+these two forms, whichever one is not the default.
+
+* Menu:
+
+* Option Summary::	Brief list of all options, without explanations.
+* Overall Options::     Controlling the kind of output:
+                        an executable, object files, assembler files,
+                        or preprocessed source.
+* Invoking G++::	Compiling C++ programs.
+* C Dialect Options::   Controlling the variant of C language compiled.
+* C++ Dialect Options:: Variations on C++.
+* Warning Options::     How picky should the compiler be?
+* Debugging Options::   Symbol tables, measurements, and debugging dumps.
+* Optimize Options::    How much optimization?
+* Preprocessor Options:: Controlling header files and macro definitions.
+                         Also, getting dependency information for Make.
+* Assembler Options::   Passing options to the assembler.
+* Link Options::        Specifying libraries and so on.
+* Directory Options::   Where to find header files and libraries.
+                        Where to find the compiler executable files.
+* Target Options::      Running a cross-compiler, or an old version of GCC.
+* Submodel Options::    Specifying minor hardware or convention variations,
+                        such as 68010 vs 68020.
+* Code Gen Options::    Specifying conventions for function calls, data layout
+                        and register usage.
+* Environment Variables:: Env vars that affect GCC.
+* Running Protoize::    Automatically adding or removing function prototypes.
+
+
+File: gcc.info,  Node: Option Summary,  Next: Overall Options,  Up: Invoking GCC
+
+Option Summary
+==============
+
+   Here is a summary of all the options, grouped by type.  Explanations
+are in the following sections.
+
+*Overall Options*
+     *Note Options Controlling the Kind of Output: Overall Options.
+          -c  -S  -E  -o FILE  -pipe  -v  --help  -x LANGUAGE
+
+*C Language Options*
+     *Note Options Controlling C Dialect: C Dialect Options.
+          -ansi -flang-isoc9x -fallow-single-precision  -fcond-mismatch  -fno-asm
+          -fno-builtin  -ffreestanding  -fhosted  -fsigned-bitfields  -fsigned-char
+          -funsigned-bitfields  -funsigned-char  -fwritable-strings
+          -traditional  -traditional-cpp  -trigraphs
+
+*C++ Language Options*
+     *Note Options Controlling C++ Dialect: C++ Dialect Options.
+          -fno-access-control  -fcheck-new  -fconserve-space  -fdollars-in-identifiers
+          -fno-elide-constructors  -fexternal-templates  -ffor-scope
+          -fno-for-scope  -fno-gnu-keywords  -fguiding-decls  -fhandle-signatures
+          -fhonor-std -fhuge-objects  -fno-implicit-templates  -finit-priority
+          -fno-implement-inlines -fname-mangling-version-N  -fno-default-inline
+          -foperator-names  -fno-optional-diags  -fpermissive -frepo  -fstrict-prototype
+          -fsquangle  -ftemplate-depth-N  -fthis-is-variable  -fvtable-thunks
+          -nostdinc++  -Wctor-dtor-privacy -Wno-deprecated -Weffc++
+          -Wno-non-template-friend
+          -Wnon-virtual-dtor  -Wold-style-cast  -Woverloaded-virtual
+          -Wno-pmf-conversions  -Wreorder  -Wsign-promo  -Wsynth
+
+*Warning Options*
+     *Note Options to Request or Suppress Warnings: Warning Options.
+          -fsyntax-only  -pedantic  -pedantic-errors
+          -w  -W  -Wall  -Waggregate-return  -Wbad-function-cast
+          -Wcast-align  -Wcast-qual  -Wchar-subscripts  -Wcomment
+          -Wconversion  -Werror  -Wformat
+          -Wid-clash-LEN  -Wimplicit -Wimplicit-int
+          -Wimplicit-function-declaration  -Wimport
+          -Werror-implicit-function-declaration  -Winline
+          -Wlarger-than-LEN  -Wlong-long
+          -Wmain  -Wmissing-declarations  -Wmissing-noreturn
+          -Wmissing-prototypes  -Wmultichar  -Wnested-externs  -Wno-import
+          -Wparentheses -Wpointer-arith  -Wredundant-decls
+          -Wreturn-type -Wshadow  -Wsign-compare  -Wstrict-prototypes
+          -Wswitch  -Wtraditional
+          -Wtrigraphs -Wundef  -Wuninitialized  -Wunused  -Wwrite-strings
+          -Wunknown-pragmas
+
+*Debugging Options*
+     *Note Options for Debugging Your Program or GCC: Debugging Options.
+          -a  -ax  -dLETTERS  -fdump-unnumbered -fpretend-float
+          -fprofile-arcs  -ftest-coverage
+          -g  -gLEVEL  -gcoff  -gdwarf  -gdwarf-1  -gdwarf-1+  -gdwarf-2
+          -ggdb  -gstabs  -gstabs+  -gxcoff  -gxcoff+
+          -p  -pg  -print-file-name=LIBRARY  -print-libgcc-file-name
+          -print-prog-name=PROGRAM  -print-search-dirs  -save-temps
+
+*Optimization Options*
+     *Note Options that Control Optimization: Optimize Options.
+          -fbranch-probabilities  -foptimize-register-moves
+          -fcaller-saves  -fcse-follow-jumps  -fcse-skip-blocks
+          -fdelayed-branch   -fexpensive-optimizations
+          -ffast-math  -ffloat-store  -fforce-addr  -fforce-mem
+          -fdata-sections -ffunction-sections  -fgcse
+          -finline-functions -finline-limit-N -fkeep-inline-functions
+          -fno-default-inline -fno-defer-pop  -fno-function-cse
+          -fno-inline  -fno-peephole  -fomit-frame-pointer -fregmove
+          -frerun-cse-after-loop  -frerun-loop-opt -fschedule-insns
+          -fschedule-insns2  -fstrength-reduce  -fthread-jumps
+          -funroll-all-loops  -funroll-loops
+          -fmove-all-movables  -freduce-all-givs -fstrict-aliasing
+          -O  -O0  -O1  -O2  -O3 -Os
+
+*Preprocessor Options*
+     *Note Options Controlling the Preprocessor: Preprocessor Options.
+          -AQUESTION(ANSWER)  -C  -dD  -dM  -dN
+          -DMACRO[=DEFN]  -E  -H
+          -idirafter DIR
+          -include FILE  -imacros FILE
+          -iprefix FILE  -iwithprefix DIR
+          -iwithprefixbefore DIR  -isystem DIR -isystem-c++ DIR
+          -M  -MD  -MM  -MMD  -MG  -nostdinc  -P  -trigraphs
+          -undef  -UMACRO  -Wp,OPTION
+
+*Assembler Option*
+     *Note Passing Options to the Assembler: Assembler Options.
+          -Wa,OPTION
+
+*Linker Options*
+     *Note Options for Linking: Link Options.
+          OBJECT-FILE-NAME  -lLIBRARY
+          -nostartfiles  -nodefaultlibs  -nostdlib
+          -s  -static  -shared  -symbolic
+          -Wl,OPTION  -Xlinker OPTION
+          -u SYMBOL
+
+*Directory Options*
+     *Note Options for Directory Search: Directory Options.
+          -BPREFIX  -IDIR  -I-  -LDIR  -specs=FILE
+
+*Target Options*
+     *Note Target Options::.
+          -b MACHINE  -V VERSION
+
+*Machine Dependent Options*
+     *Note Hardware Models and Configurations: Submodel Options.
+          *M680x0 Options*
+          -m68000  -m68020  -m68020-40  -m68020-60  -m68030  -m68040
+          -m68060  -mcpu32 -m5200  -m68881  -mbitfield  -mc68000  -mc68020
+          -mfpa -mnobitfield  -mrtd  -mshort  -msoft-float
+          -malign-int
+          
+          *VAX Options*
+          -mg  -mgnu  -munix
+          
+          *SPARC Options*
+          -mcpu=CPU TYPE
+          -mtune=CPU TYPE
+          -mcmodel=CODE MODEL
+          -malign-jumps=NUM  -malign-loops=NUM
+          -malign-functions=NUM
+          -m32  -m64
+          -mapp-regs  -mbroken-saverestore  -mcypress  -mepilogue
+          -mflat  -mfpu  -mhard-float  -mhard-quad-float
+          -mimpure-text  -mlive-g0  -mno-app-regs  -mno-epilogue
+          -mno-flat  -mno-fpu  -mno-impure-text
+          -mno-stack-bias  -mno-unaligned-doubles
+          -msoft-float  -msoft-quad-float  -msparclite  -mstack-bias
+          -msupersparc  -munaligned-doubles  -mv8
+          
+          *Convex Options*
+          -mc1  -mc2  -mc32  -mc34  -mc38
+          -margcount  -mnoargcount
+          -mlong32  -mlong64
+          -mvolatile-cache  -mvolatile-nocache
+          
+          *AMD29K Options*
+          -m29000  -m29050  -mbw  -mnbw  -mdw  -mndw
+          -mlarge  -mnormal  -msmall
+          -mkernel-registers  -mno-reuse-arg-regs
+          -mno-stack-check  -mno-storem-bug
+          -mreuse-arg-regs  -msoft-float  -mstack-check
+          -mstorem-bug  -muser-registers
+          
+          *ARM Options*
+          -mapcs-frame -mno-apcs-frame
+          -mapcs-26 -mapcs-32
+          -mapcs-stack-check -mno-apcs-stack-check
+          -mapcs-float -mno-apcs-float
+          -mapcs-reentrant -mno-apcs-reentrant
+          -msched-prolog -mno-sched-prolog
+          -mlittle-endian -mbig-endian -mwords-little-endian
+          -mshort-load-bytes -mno-short-load-bytes -mshort-load-words -mno-short-load-words
+          -msoft-float -mhard-float -mfpe
+          -mthumb-interwork -mno-thumb-interwork
+          -mcpu= -march= -mfpe=
+          -mstructure-size-boundary=
+          -mbsd -mxopen -mno-symrename
+          -mabort-on-noreturn
+          -mno-sched-prolog
+          
+          *Thumb Options*
+          -mtpcs-frame -mno-tpcs-frame
+          -mtpcs-leaf-frame -mno-tpcs-leaf-frame
+          -mlittle-endian  -mbig-endian
+          -mthumb-interwork -mno-thumb-interwork
+          -mstructure-size-boundary=
+          
+          *MN10200 Options*
+          -mrelax
+          
+          *MN10300 Options*
+          -mmult-bug
+          -mno-mult-bug
+          -mrelax
+          
+          *M32R/D Options*
+          -mcode-model=MODEL TYPE  -msdata=SDATA TYPE
+          -G NUM
+          
+          *M88K Options*
+          -m88000  -m88100  -m88110  -mbig-pic
+          -mcheck-zero-division  -mhandle-large-shift
+          -midentify-revision  -mno-check-zero-division
+          -mno-ocs-debug-info  -mno-ocs-frame-position
+          -mno-optimize-arg-area  -mno-serialize-volatile
+          -mno-underscores  -mocs-debug-info
+          -mocs-frame-position  -moptimize-arg-area
+          -mserialize-volatile  -mshort-data-NUM  -msvr3
+          -msvr4  -mtrap-large-shift  -muse-div-instruction
+          -mversion-03.00  -mwarn-passed-structs
+          
+          *RS/6000 and PowerPC Options*
+          -mcpu=CPU TYPE
+          -mtune=CPU TYPE
+          -mpower  -mno-power  -mpower2  -mno-power2
+          -mpowerpc  -mno-powerpc
+          -mpowerpc-gpopt  -mno-powerpc-gpopt
+          -mpowerpc-gfxopt  -mno-powerpc-gfxopt
+          -mnew-mnemonics  -mno-new-mnemonics
+          -mfull-toc   -mminimal-toc  -mno-fop-in-toc  -mno-sum-in-toc
+          -maix64  -maix32  -mxl-call  -mno-xl-call  -mthreads  -mpe
+          -msoft-float  -mhard-float  -mmultiple  -mno-multiple
+          -mstring  -mno-string  -mupdate  -mno-update
+          -mfused-madd  -mno-fused-madd  -mbit-align  -mno-bit-align
+          -mstrict-align  -mno-strict-align  -mrelocatable
+          -mno-relocatable  -mrelocatable-lib  -mno-relocatable-lib
+          -mtoc  -mno-toc -mlittle  -mlittle-endian  -mbig  -mbig-endian
+          -mcall-aix  -mcall-sysv  -mprototype  -mno-prototype
+          -msim  -mmvme  -mads  -myellowknife  -memb -msdata
+          -msdata=OPT  -G NUM
+          
+          *RT Options*
+          -mcall-lib-mul  -mfp-arg-in-fpregs  -mfp-arg-in-gregs
+          -mfull-fp-blocks  -mhc-struct-return  -min-line-mul
+          -mminimum-fp-blocks  -mnohc-struct-return
+          
+          *MIPS Options*
+          -mabicalls  -mcpu=CPU TYPE  -membedded-data
+          -membedded-pic  -mfp32  -mfp64  -mgas  -mgp32  -mgp64
+          -mgpopt  -mhalf-pic  -mhard-float  -mint64  -mips1
+          -mips2  -mips3 -mips4 -mlong64  -mlong32 -mlong-calls  -mmemcpy
+          -mmips-as  -mmips-tfile  -mno-abicalls
+          -mno-embedded-data  -mno-embedded-pic
+          -mno-gpopt  -mno-long-calls
+          -mno-memcpy  -mno-mips-tfile  -mno-rnames  -mno-stats
+          -mrnames  -msoft-float
+          -m4650  -msingle-float  -mmad
+          -mstats  -EL  -EB  -G NUM  -nocpp
+          -mabi=32 -mabi=n32 -mabi=64 -mabi=eabi
+          
+          *i386 Options*
+          -mcpu=CPU TYPE
+          -march=CPU TYPE
+          -mieee-fp  -mno-fancy-math-387
+          -mno-fp-ret-in-387  -msoft-float  -msvr3-shlib
+          -mno-wide-multiply  -mrtd  -malign-double
+          -mreg-alloc=LIST  -mregparm=NUM
+          -malign-jumps=NUM  -malign-loops=NUM
+          -malign-functions=NUM -mpreferred-stack-boundary=NUM
+          
+          *HPPA Options*
+          -march=ARCHITECTURE TYPE
+          -mbig-switch  -mdisable-fpregs  -mdisable-indexing
+          -mfast-indirect-calls -mgas  -mjump-in-delay
+          -mlong-load-store  -mno-big-switch  -mno-disable-fpregs
+          -mno-disable-indexing  -mno-fast-indirect-calls  -mno-gas
+          -mno-jump-in-delay  -mno-long-load-store
+          -mno-portable-runtime  -mno-soft-float  -mno-space
+          -mno-space-regs  -msoft-float  -mpa-risc-1-0
+          -mpa-risc-1-1  -mpa-risc-2-0 -mportable-runtime
+          -mschedule=CPU TYPE  -mspace  -mspace-regs
+          
+          *Intel 960 Options*
+          -mCPU TYPE  -masm-compat  -mclean-linkage
+          -mcode-align  -mcomplex-addr  -mleaf-procedures
+          -mic-compat  -mic2.0-compat  -mic3.0-compat
+          -mintel-asm  -mno-clean-linkage  -mno-code-align
+          -mno-complex-addr  -mno-leaf-procedures
+          -mno-old-align  -mno-strict-align  -mno-tail-call
+          -mnumerics  -mold-align  -msoft-float  -mstrict-align
+          -mtail-call
+          
+          *DEC Alpha Options*
+          -mfp-regs  -mno-fp-regs -mno-soft-float  -msoft-float
+          -malpha-as -mgas
+          -mieee  -mieee-with-inexact  -mieee-conformant
+          -mfp-trap-mode=MODE  -mfp-rounding-mode=MODE
+          -mtrap-precision=MODE  -mbuild-constants
+          -mcpu=CPU TYPE
+          -mbwx -mno-bwx -mcix -mno-cix -mmax -mno-max
+          -mmemory-latency=TIME
+          
+          *Clipper Options*
+          -mc300  -mc400
+          
+          *H8/300 Options*
+          -mrelax  -mh -ms -mint32  -malign-300
+          
+          *SH Options*
+          -m1  -m2  -m3  -m3e  -mb  -ml  -mdalign -mrelax
+          
+          *System V Options*
+          -Qy  -Qn  -YP,PATHS  -Ym,DIR
+          
+          *ARC Options*
+          -EB  -EL
+          -mmangle-cpu  -mcpu=CPU  -mtext=TEXT SECTION
+          -mdata=DATA SECTION  -mrodata=READONLY DATA SECTION
+          
+          *TMS320C3x/C4x Options*
+          -mcpu=CPU -mbig -msmall -mregparm -mmemparm
+          -mfast-fix -mmpyi -mbk -mti -mdp-isr-reload
+          -mrpts=COUNT  -mrptb -mdb -mloop-unsigned
+          -mparallel-insns -mparallel-mpy -mpreserve-float
+          
+          *V850 Options*
+          -mlong-calls -mno-long-calls -mep -mno-ep
+          -mprolog-function -mno-prolog-function -mspace
+          -mtda=N -msda=N -mzda=N
+          -mv850 -mbig-switch
+          
+          *NS32K Options*
+          -m32032 -m32332 -m32532 -m32081 -m32381 -mmult-add -mnomult-add
+          -msoft-float -mrtd -mnortd -mregparam -mnoregparam -msb -mnosb
+          -mbitfield -mnobitfield -mhimem -mnohimem
+
+*Code Generation Options*
+     *Note Options for Code Generation Conventions: Code Gen Options.
+          -fcall-saved-REG  -fcall-used-REG
+          -fexceptions -ffixed-REG  -finhibit-size-directive
+          -fcheck-memory-usage  -fprefix-function-name
+          -fno-common  -fno-ident  -fno-gnu-linker
+          -fpcc-struct-return  -fpic  -fPIC
+          -freg-struct-return  -fshared-data  -fshort-enums
+          -fshort-double  -fvolatile  -fvolatile-global -fvolatile-static
+          -fverbose-asm -fpack-struct  -fstack-check
+          -fargument-alias  -fargument-noalias
+          -fargument-noalias-global
+          -fleading-underscore
+
+* Menu:
+
+* Overall Options::     Controlling the kind of output:
+                        an executable, object files, assembler files,
+                        or preprocessed source.
+* C Dialect Options::   Controlling the variant of C language compiled.
+* C++ Dialect Options:: Variations on C++.
+* Warning Options::     How picky should the compiler be?
+* Debugging Options::   Symbol tables, measurements, and debugging dumps.
+* Optimize Options::    How much optimization?
+* Preprocessor Options:: Controlling header files and macro definitions.
+                         Also, getting dependency information for Make.
+* Assembler Options::   Passing options to the assembler.
+* Link Options::        Specifying libraries and so on.
+* Directory Options::   Where to find header files and libraries.
+                        Where to find the compiler executable files.
+* Target Options::      Running a cross-compiler, or an old version of GCC.
+
+
+File: gcc.info,  Node: Overall Options,  Next: Invoking G++,  Prev: Option Summary,  Up: Invoking GCC
+
+Options Controlling the Kind of Output
+======================================
+
+   Compilation can involve up to four stages: preprocessing, compilation
+proper, assembly and linking, always in that order.  The first three
+stages apply to an individual source file, and end by producing an
+object file; linking combines all the object files (those newly
+compiled, and those specified as input) into an executable file.
+
+   For any given input file, the file name suffix determines what kind
+of compilation is done:
+
+`FILE.c'
+     C source code which must be preprocessed.
+
+`FILE.i'
+     C source code which should not be preprocessed.
+
+`FILE.ii'
+     C++ source code which should not be preprocessed.
+
+`FILE.m'
+     Objective-C source code.  Note that you must link with the library
+     `libobjc.a' to make an Objective-C program work.
+
+`FILE.h'
+     C header file (not to be compiled or linked).
+
+`FILE.cc'
+`FILE.cxx'
+`FILE.cpp'
+`FILE.C'
+     C++ source code which must be preprocessed.  Note that in `.cxx',
+     the last two letters must both be literally `x'.  Likewise, `.C'
+     refers to a literal capital C.
+
+`FILE.s'
+     Assembler code.
+
+`FILE.S'
+     Assembler code which must be preprocessed.
+
+`OTHER'
+     An object file to be fed straight into linking.  Any file name
+     with no recognized suffix is treated this way.
+
+   You can specify the input language explicitly with the `-x' option:
+
+`-x LANGUAGE'
+     Specify explicitly the LANGUAGE for the following input files
+     (rather than letting the compiler choose a default based on the
+     file name suffix).  This option applies to all following input
+     files until the next `-x' option.  Possible values for LANGUAGE
+     are:
+          c  objective-c  c++
+          c-header  cpp-output  c++-cpp-output
+          assembler  assembler-with-cpp
+
+`-x none'
+     Turn off any specification of a language, so that subsequent files
+     are handled according to their file name suffixes (as they are if
+     `-x' has not been used at all).
+
+   If you only want some of the stages of compilation, you can use `-x'
+(or filename suffixes) to tell `gcc' where to start, and one of the
+options `-c', `-S', or `-E' to say where `gcc' is to stop.  Note that
+some combinations (for example, `-x cpp-output -E' instruct `gcc' to do
+nothing at all.
+
+`-c'
+     Compile or assemble the source files, but do not link.  The linking
+     stage simply is not done.  The ultimate output is in the form of an
+     object file for each source file.
+
+     By default, the object file name for a source file is made by
+     replacing the suffix `.c', `.i', `.s', etc., with `.o'.
+
+     Unrecognized input files, not requiring compilation or assembly,
+     are ignored.
+
+`-S'
+     Stop after the stage of compilation proper; do not assemble.  The
+     output is in the form of an assembler code file for each
+     non-assembler input file specified.
+
+     By default, the assembler file name for a source file is made by
+     replacing the suffix `.c', `.i', etc., with `.s'.
+
+     Input files that don't require compilation are ignored.
+
+`-E'
+     Stop after the preprocessing stage; do not run the compiler
+     proper.  The output is in the form of preprocessed source code,
+     which is sent to the standard output.
+
+     Input files which don't require preprocessing are ignored.
+
+`-o FILE'
+     Place output in file FILE.  This applies regardless to whatever
+     sort of output is being produced, whether it be an executable file,
+     an object file, an assembler file or preprocessed C code.
+
+     Since only one output file can be specified, it does not make
+     sense to use `-o' when compiling more than one input file, unless
+     you are producing an executable file as output.
+
+     If `-o' is not specified, the default is to put an executable file
+     in `a.out', the object file for `SOURCE.SUFFIX' in `SOURCE.o', its
+     assembler file in `SOURCE.s', and all preprocessed C source on
+     standard output.
+
+`-v'
+     Print (on standard error output) the commands executed to run the
+     stages of compilation.  Also print the version number of the
+     compiler driver program and of the preprocessor and the compiler
+     proper.
+
+`-pipe'
+     Use pipes rather than temporary files for communication between the
+     various stages of compilation.  This fails to work on some systems
+     where the assembler is unable to read from a pipe; but the GNU
+     assembler has no trouble.
+
+`--help'
+     Print (on the standard output) a description of the command line
+     options understood by `gcc'.  If the `-v' option is also specified
+     then `--help' will also be passed on to the various processes
+     invoked by `gcc', so that they can display the command line options
+     they accept.  If the `-W' option is also specified then command
+     line options which have no documentation associated with them will
+     also be displayed.
+
+
+File: gcc.info,  Node: Invoking G++,  Next: C Dialect Options,  Prev: Overall Options,  Up: Invoking GCC
+
+Compiling C++ Programs
+======================
+
+   C++ source files conventionally use one of the suffixes `.C', `.cc',
+`.cpp', `.c++', `.cp', or `.cxx'; preprocessed C++ files use the suffix
+`.ii'.  GCC recognizes files with these names and compiles them as C++
+programs even if you call the compiler the same way as for compiling C
+programs (usually with the name `gcc').
+
+   However, C++ programs often require class libraries as well as a
+compiler that understands the C++ language--and under some
+circumstances, you might want to compile programs from standard input,
+or otherwise without a suffix that flags them as C++ programs.  `g++'
+is a program that calls GCC with the default language set to C++, and
+automatically specifies linking against the C++ library.  On many
+systems, the script `g++' is also installed with the name `c++'.
+
+   When you compile C++ programs, you may specify many of the same
+command-line options that you use for compiling programs in any
+language; or command-line options meaningful for C and related
+languages; or options that are meaningful only for C++ programs.  *Note
+Options Controlling C Dialect: C Dialect Options, for explanations of
+options for languages related to C.  *Note Options Controlling C++
+Dialect: C++ Dialect Options, for explanations of options that are
+meaningful only for C++ programs.
+
+
+File: gcc.info,  Node: C Dialect Options,  Next: C++ Dialect Options,  Prev: Invoking G++,  Up: Invoking GCC
+
+Options Controlling C Dialect
+=============================
+
+   The following options control the dialect of C (or languages derived
+from C, such as C++ and Objective C) that the compiler accepts:
+
+`-ansi'
+     In C mode, support all ANSI standard C programs.  In C++ mode,
+     remove GNU extensions that conflict with ANSI C++.
+
+     This turns off certain features of GCC that are incompatible with
+     ANSI C (when compiling C code), or of ANSI standard C++ (when
+     compiling C++ code), such as the `asm' and `typeof' keywords, and
+     predefined macros such as `unix' and `vax' that identify the type
+     of system you are using.  It also enables the undesirable and
+     rarely used ANSI trigraph feature.  For the C compiler, it
+     disables recognition of C++ style `//' comments as well as the
+     `inline' keyword.  For the C++ compiler, `-foperator-names' is
+     enabled as well.
+
+     The alternate keywords `__asm__', `__extension__', `__inline__'
+     and `__typeof__' continue to work despite `-ansi'.  You would not
+     want to use them in an ANSI C program, of course, but it is useful
+     to put them in header files that might be included in compilations
+     done with `-ansi'.  Alternate predefined macros such as `__unix__'
+     and `__vax__' are also available, with or without `-ansi'.
+
+     The `-ansi' option does not cause non-ANSI programs to be rejected
+     gratuitously.  For that, `-pedantic' is required in addition to
+     `-ansi'.  *Note Warning Options::.
+
+     The macro `__STRICT_ANSI__' is predefined when the `-ansi' option
+     is used.  Some header files may notice this macro and refrain from
+     declaring certain functions or defining certain macros that the
+     ANSI standard doesn't call for; this is to avoid interfering with
+     any programs that might use these names for other things.
+
+     The functions `alloca', `abort', `exit', and `_exit' are not
+     builtin functions when `-ansi' is used.
+
+`-flang-isoc9x'
+     Enable support for features found in the C9X standard.  In
+     particular, enable support for the C9X `restrict' keyword.
+
+     Even when this option is not specified, you can still use some C9X
+     features in so far as they do not conflict with previous C
+     standards.  For example, you may use `__restrict__' even when
+     -flang-isoc9x is not specified.
+
+`-fno-asm'
+     Do not recognize `asm', `inline' or `typeof' as a keyword, so that
+     code can use these words as identifiers.  You can use the keywords
+     `__asm__', `__inline__' and `__typeof__' instead.  `-ansi' implies
+     `-fno-asm'.
+
+     In C++, this switch only affects the `typeof' keyword, since `asm'
+     and `inline' are standard keywords.  You may want to use the
+     `-fno-gnu-keywords' flag instead, as it also disables the other,
+     C++-specific, extension keywords such as `headof'.
+
+`-fno-builtin'
+     Don't recognize builtin functions that do not begin with
+     `__builtin_' as prefix.  Currently, the functions affected include
+     `abort', `abs', `alloca', `cos', `exit', `fabs', `ffs', `labs',
+     `memcmp', `memcpy', `sin', `sqrt', `strcmp', `strcpy', and
+     `strlen'.
+
+     GCC normally generates special code to handle certain builtin
+     functions more efficiently; for instance, calls to `alloca' may
+     become single instructions that adjust the stack directly, and
+     calls to `memcpy' may become inline copy loops.  The resulting
+     code is often both smaller and faster, but since the function
+     calls no longer appear as such, you cannot set a breakpoint on
+     those calls, nor can you change the behavior of the functions by
+     linking with a different library.
+
+     The `-ansi' option prevents `alloca' and `ffs' from being builtin
+     functions, since these functions do not have an ANSI standard
+     meaning.
+
+`-fhosted'
+     Assert that compilation takes place in a hosted environment.  This
+     implies `-fbuiltin'.  A hosted environment is one in which the
+     entire standard library is available, and in which `main' has a
+     return type of `int'.  Examples are nearly everything except a
+     kernel.  This is equivalent to `-fno-freestanding'.
+
+`-ffreestanding'
+     Assert that compilation takes place in a freestanding environment.
+     This implies `-fno-builtin'.  A freestanding environment is one
+     in which the standard library may not exist, and program startup
+     may not necessarily be at `main'.  The most obvious example is an
+     OS kernel.  This is equivalent to `-fno-hosted'.
+
+`-trigraphs'
+     Support ANSI C trigraphs.  You don't want to know about this
+     brain-damage.  The `-ansi' option implies `-trigraphs'.
+
+`-traditional'
+     Attempt to support some aspects of traditional C compilers.
+     Specifically:
+
+        * All `extern' declarations take effect globally even if they
+          are written inside of a function definition.  This includes
+          implicit declarations of functions.
+
+        * The newer keywords `typeof', `inline', `signed', `const' and
+          `volatile' are not recognized.  (You can still use the
+          alternative keywords such as `__typeof__', `__inline__', and
+          so on.)
+
+        * Comparisons between pointers and integers are always allowed.
+
+        * Integer types `unsigned short' and `unsigned char' promote to
+          `unsigned int'.
+
+        * Out-of-range floating point literals are not an error.
+
+        * Certain constructs which ANSI regards as a single invalid
+          preprocessing number, such as `0xe-0xd', are treated as
+          expressions instead.
+
+        * String "constants" are not necessarily constant; they are
+          stored in writable space, and identical looking constants are
+          allocated separately.  (This is the same as the effect of
+          `-fwritable-strings'.)
+
+        * All automatic variables not declared `register' are preserved
+          by `longjmp'.  Ordinarily, GNU C follows ANSI C: automatic
+          variables not declared `volatile' may be clobbered.
+
+        * The character escape sequences `\x' and `\a' evaluate as the
+          literal characters `x' and `a' respectively.  Without
+          `-traditional', `\x' is a prefix for the hexadecimal
+          representation of a character, and `\a' produces a bell.
+
+     You may wish to use `-fno-builtin' as well as `-traditional' if
+     your program uses names that are normally GNU C builtin functions
+     for other purposes of its own.
+
+     You cannot use `-traditional' if you include any header files that
+     rely on ANSI C features.  Some vendors are starting to ship
+     systems with ANSI C header files and you cannot use `-traditional'
+     on such systems to compile files that include any system headers.
+
+     The `-traditional' option also enables `-traditional-cpp', which
+     is described next.
+
+`-traditional-cpp'
+     Attempt to support some aspects of traditional C preprocessors.
+     Specifically:
+
+        * Comments convert to nothing at all, rather than to a space.
+          This allows traditional token concatenation.
+
+        * In a preprocessing directive, the `#' symbol must appear as
+          the first character of a line.
+
+        * Macro arguments are recognized within string constants in a
+          macro definition (and their values are stringified, though
+          without additional quote marks, when they appear in such a
+          context).  The preprocessor always considers a string
+          constant to end at a newline.
+
+        * The predefined macro `__STDC__' is not defined when you use
+          `-traditional', but `__GNUC__' is (since the GNU extensions
+          which `__GNUC__' indicates are not affected by
+          `-traditional').  If you need to write header files that work
+          differently depending on whether `-traditional' is in use, by
+          testing both of these predefined macros you can distinguish
+          four situations: GNU C, traditional GNU C, other ANSI C
+          compilers, and other old C compilers.  The predefined macro
+          `__STDC_VERSION__' is also not defined when you use
+          `-traditional'.  *Note Standard Predefined Macros:
+          (cpp.info)Standard Predefined, for more discussion of these
+          and other predefined macros.
+
+        * The preprocessor considers a string constant to end at a
+          newline (unless the newline is escaped with `\').  (Without
+          `-traditional', string constants can contain the newline
+          character as typed.)
+
+`-fcond-mismatch'
+     Allow conditional expressions with mismatched types in the second
+     and third arguments.  The value of such an expression is void.
+
+`-funsigned-char'
+     Let the type `char' be unsigned, like `unsigned char'.
+
+     Each kind of machine has a default for what `char' should be.  It
+     is either like `unsigned char' by default or like `signed char' by
+     default.
+
+     Ideally, a portable program should always use `signed char' or
+     `unsigned char' when it depends on the signedness of an object.
+     But many programs have been written to use plain `char' and expect
+     it to be signed, or expect it to be unsigned, depending on the
+     machines they were written for.  This option, and its inverse, let
+     you make such a program work with the opposite default.
+
+     The type `char' is always a distinct type from each of `signed
+     char' or `unsigned char', even though its behavior is always just
+     like one of those two.
+
+`-fsigned-char'
+     Let the type `char' be signed, like `signed char'.
+
+     Note that this is equivalent to `-fno-unsigned-char', which is the
+     negative form of `-funsigned-char'.  Likewise, the option
+     `-fno-signed-char' is equivalent to `-funsigned-char'.
+
+     You may wish to use `-fno-builtin' as well as `-traditional' if
+     your program uses names that are normally GNU C builtin functions
+     for other purposes of its own.
+
+     You cannot use `-traditional' if you include any header files that
+     rely on ANSI C features.  Some vendors are starting to ship
+     systems with ANSI C header files and you cannot use `-traditional'
+     on such systems to compile files that include any system headers.
+
+`-fsigned-bitfields'
+`-funsigned-bitfields'
+`-fno-signed-bitfields'
+`-fno-unsigned-bitfields'
+     These options control whether a bitfield is signed or unsigned,
+     when the declaration does not use either `signed' or `unsigned'.
+     By default, such a bitfield is signed, because this is consistent:
+     the basic integer types such as `int' are signed types.
+
+     However, when `-traditional' is used, bitfields are all unsigned
+     no matter what.
+
+`-fwritable-strings'
+     Store string constants in the writable data segment and don't
+     uniquize them.  This is for compatibility with old programs which
+     assume they can write into string constants.  The option
+     `-traditional' also has this effect.
+
+     Writing into string constants is a very bad idea; "constants"
+     should be constant.
+
+`-fallow-single-precision'
+     Do not promote single precision math operations to double
+     precision, even when compiling with `-traditional'.
+
+     Traditional K&R C promotes all floating point operations to double
+     precision, regardless of the sizes of the operands.   On the
+     architecture for which you are compiling, single precision may be
+     faster than double precision.   If you must use `-traditional',
+     but want to use single precision operations when the operands are
+     single precision, use this option.   This option has no effect
+     when compiling with ANSI or GNU C conventions (the default).
+

usr/local/nachos/info/gcc.info-12

@@ -0,0 +1,965 @@
+This is Info file gcc.info, produced by Makeinfo version 1.68 from the
+input file ../../gcc-2.95.2/gcc/gcc.texi.
+
+INFO-DIR-SECTION Programming
+START-INFO-DIR-ENTRY
+* gcc: (gcc).                  The GNU Compiler Collection.
+END-INFO-DIR-ENTRY
+   This file documents the use and the internals of the GNU compiler.
+
+   Published by the Free Software Foundation 59 Temple Place - Suite 330
+Boston, MA 02111-1307 USA
+
+   Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
+1999 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 sections entitled "GNU General Public License" and "Funding
+for Free Software" are included exactly as in the original, and
+provided 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, except that the sections entitled "GNU General Public
+License" and "Funding for Free Software", and this permission notice,
+may be included in translations approved by the Free Software Foundation
+instead of in the original English.
+
+
+File: gcc.info,  Node: Naming Results,  Next: Min and Max,  Up: C++ Extensions
+
+Named Return Values in C++
+==========================
+
+   GNU C++ extends the function-definition syntax to allow you to
+specify a name for the result of a function outside the body of the
+definition, in C++ programs:
+
+     TYPE
+     FUNCTIONNAME (ARGS) return RESULTNAME;
+     {
+       ...
+       BODY
+       ...
+     }
+
+   You can use this feature to avoid an extra constructor call when a
+function result has a class type.  For example, consider a function
+`m', declared as `X v = m ();', whose result is of class `X':
+
+     X
+     m ()
+     {
+       X b;
+       b.a = 23;
+       return b;
+     }
+
+   Although `m' appears to have no arguments, in fact it has one
+implicit argument: the address of the return value.  At invocation, the
+address of enough space to hold `v' is sent in as the implicit argument.
+Then `b' is constructed and its `a' field is set to the value 23.
+Finally, a copy constructor (a constructor of the form `X(X&)') is
+applied to `b', with the (implicit) return value location as the
+target, so that `v' is now bound to the return value.
+
+   But this is wasteful.  The local `b' is declared just to hold
+something that will be copied right out.  While a compiler that
+combined an "elision" algorithm with interprocedural data flow analysis
+could conceivably eliminate all of this, it is much more practical to
+allow you to assist the compiler in generating efficient code by
+manipulating the return value explicitly, thus avoiding the local
+variable and copy constructor altogether.
+
+   Using the extended GNU C++ function-definition syntax, you can avoid
+the temporary allocation and copying by naming `r' as your return value
+at the outset, and assigning to its `a' field directly:
+
+     X
+     m () return r;
+     {
+       r.a = 23;
+     }
+
+The declaration of `r' is a standard, proper declaration, whose effects
+are executed *before* any of the body of `m'.
+
+   Functions of this type impose no additional restrictions; in
+particular, you can execute `return' statements, or return implicitly by
+reaching the end of the function body ("falling off the edge").  Cases
+like
+
+     X
+     m () return r (23);
+     {
+       return;
+     }
+
+(or even `X m () return r (23); { }') are unambiguous, since the return
+value `r' has been initialized in either case.  The following code may
+be hard to read, but also works predictably:
+
+     X
+     m () return r;
+     {
+       X b;
+       return b;
+     }
+
+   The return value slot denoted by `r' is initialized at the outset,
+but the statement `return b;' overrides this value.  The compiler deals
+with this by destroying `r' (calling the destructor if there is one, or
+doing nothing if there is not), and then reinitializing `r' with `b'.
+
+   This extension is provided primarily to help people who use
+overloaded operators, where there is a great need to control not just
+the arguments, but the return values of functions.  For classes where
+the copy constructor incurs a heavy performance penalty (especially in
+the common case where there is a quick default constructor), this is a
+major savings.  The disadvantage of this extension is that you do not
+control when the default constructor for the return value is called: it
+is always called at the beginning.
+
+
+File: gcc.info,  Node: Min and Max,  Next: Destructors and Goto,  Prev: Naming Results,  Up: C++ Extensions
+
+Minimum and Maximum Operators in C++
+====================================
+
+   It is very convenient to have operators which return the "minimum"
+or the "maximum" of two arguments.  In GNU C++ (but not in GNU C),
+
+`A <? B'
+     is the "minimum", returning the smaller of the numeric values A
+     and B;
+
+`A >? B'
+     is the "maximum", returning the larger of the numeric values A and
+     B.
+
+   These operations are not primitive in ordinary C++, since you can
+use a macro to return the minimum of two things in C++, as in the
+following example.
+
+     #define MIN(X,Y) ((X) < (Y) ? : (X) : (Y))
+
+You might then use `int min = MIN (i, j);' to set MIN to the minimum
+value of variables I and J.
+
+   However, side effects in `X' or `Y' may cause unintended behavior.
+For example, `MIN (i++, j++)' will fail, incrementing the smaller
+counter twice.  A GNU C extension allows you to write safe macros that
+avoid this kind of problem (*note Naming an Expression's Type: Naming
+Types.).  However, writing `MIN' and `MAX' as macros also forces you to
+use function-call notation for a fundamental arithmetic operation.
+Using GNU C++ extensions, you can write `int min = i <? j;' instead.
+
+   Since `<?' and `>?' are built into the compiler, they properly
+handle expressions with side-effects;  `int min = i++ <? j++;' works
+correctly.
+
+
+File: gcc.info,  Node: Destructors and Goto,  Next: C++ Interface,  Prev: Min and Max,  Up: C++ Extensions
+
+`goto' and Destructors in GNU C++
+=================================
+
+   In C++ programs, you can safely use the `goto' statement.  When you
+use it to exit a block which contains aggregates requiring destructors,
+the destructors will run before the `goto' transfers control.
+
+   The compiler still forbids using `goto' to *enter* a scope that
+requires constructors.
+
+
+File: gcc.info,  Node: C++ Interface,  Next: Template Instantiation,  Prev: Destructors and Goto,  Up: C++ Extensions
+
+Declarations and Definitions in One Header
+==========================================
+
+   C++ object definitions can be quite complex.  In principle, your
+source code will need two kinds of things for each object that you use
+across more than one source file.  First, you need an "interface"
+specification, describing its structure with type declarations and
+function prototypes.  Second, you need the "implementation" itself.  It
+can be tedious to maintain a separate interface description in a header
+file, in parallel to the actual implementation.  It is also dangerous,
+since separate interface and implementation definitions may not remain
+parallel.
+
+   With GNU C++, you can use a single header file for both purposes.
+
+     *Warning:* The mechanism to specify this is in transition.  For the
+     nonce, you must use one of two `#pragma' commands; in a future
+     release of GNU C++, an alternative mechanism will make these
+     `#pragma' commands unnecessary.
+
+   The header file contains the full definitions, but is marked with
+`#pragma interface' in the source code.  This allows the compiler to
+use the header file only as an interface specification when ordinary
+source files incorporate it with `#include'.  In the single source file
+where the full implementation belongs, you can use either a naming
+convention or `#pragma implementation' to indicate this alternate use
+of the header file.
+
+`#pragma interface'
+`#pragma interface "SUBDIR/OBJECTS.h"'
+     Use this directive in *header files* that define object classes,
+     to save space in most of the object files that use those classes.
+     Normally, local copies of certain information (backup copies of
+     inline member functions, debugging information, and the internal
+     tables that implement virtual functions) must be kept in each
+     object file that includes class definitions.  You can use this
+     pragma to avoid such duplication.  When a header file containing
+     `#pragma interface' is included in a compilation, this auxiliary
+     information will not be generated (unless the main input source
+     file itself uses `#pragma implementation').  Instead, the object
+     files will contain references to be resolved at link time.
+
+     The second form of this directive is useful for the case where you
+     have multiple headers with the same name in different directories.
+     If you use this form, you must specify the same string to `#pragma
+     implementation'.
+
+`#pragma implementation'
+`#pragma implementation "OBJECTS.h"'
+     Use this pragma in a *main input file*, when you want full output
+     from included header files to be generated (and made globally
+     visible).  The included header file, in turn, should use `#pragma
+     interface'.  Backup copies of inline member functions, debugging
+     information, and the internal tables used to implement virtual
+     functions are all generated in implementation files.
+
+     If you use `#pragma implementation' with no argument, it applies to
+     an include file with the same basename(1) as your source file.
+     For example, in `allclass.cc', giving just `#pragma implementation'
+     by itself is equivalent to `#pragma implementation "allclass.h"'.
+
+     In versions of GNU C++ prior to 2.6.0 `allclass.h' was treated as
+     an implementation file whenever you would include it from
+     `allclass.cc' even if you never specified `#pragma
+     implementation'.  This was deemed to be more trouble than it was
+     worth, however, and disabled.
+
+     If you use an explicit `#pragma implementation', it must appear in
+     your source file *before* you include the affected header files.
+
+     Use the string argument if you want a single implementation file to
+     include code from multiple header files.  (You must also use
+     `#include' to include the header file; `#pragma implementation'
+     only specifies how to use the file--it doesn't actually include
+     it.)
+
+     There is no way to split up the contents of a single header file
+     into multiple implementation files.
+
+   `#pragma implementation' and `#pragma interface' also have an effect
+on function inlining.
+
+   If you define a class in a header file marked with `#pragma
+interface', the effect on a function defined in that class is similar to
+an explicit `extern' declaration--the compiler emits no code at all to
+define an independent version of the function.  Its definition is used
+only for inlining with its callers.
+
+   Conversely, when you include the same header file in a main source
+file that declares it as `#pragma implementation', the compiler emits
+code for the function itself; this defines a version of the function
+that can be found via pointers (or by callers compiled without
+inlining).  If all calls to the function can be inlined, you can avoid
+emitting the function by compiling with `-fno-implement-inlines'.  If
+any calls were not inlined, you will get linker errors.
+
+   ---------- Footnotes ----------
+
+   (1) A file's "basename" was the name stripped of all leading path
+information and of trailing suffixes, such as `.h' or `.C' or `.cc'.
+
+
+File: gcc.info,  Node: Template Instantiation,  Next: Bound member functions,  Prev: C++ Interface,  Up: C++ Extensions
+
+Where's the Template?
+=====================
+
+   C++ templates are the first language feature to require more
+intelligence from the environment than one usually finds on a UNIX
+system.  Somehow the compiler and linker have to make sure that each
+template instance occurs exactly once in the executable if it is needed,
+and not at all otherwise.  There are two basic approaches to this
+problem, which I will refer to as the Borland model and the Cfront
+model.
+
+Borland model
+     Borland C++ solved the template instantiation problem by adding
+     the code equivalent of common blocks to their linker; the compiler
+     emits template instances in each translation unit that uses them,
+     and the linker collapses them together.  The advantage of this
+     model is that the linker only has to consider the object files
+     themselves; there is no external complexity to worry about.  This
+     disadvantage is that compilation time is increased because the
+     template code is being compiled repeatedly.  Code written for this
+     model tends to include definitions of all templates in the header
+     file, since they must be seen to be instantiated.
+
+Cfront model
+     The AT&T C++ translator, Cfront, solved the template instantiation
+     problem by creating the notion of a template repository, an
+     automatically maintained place where template instances are
+     stored.  A more modern version of the repository works as follows:
+     As individual object files are built, the compiler places any
+     template definitions and instantiations encountered in the
+     repository.  At link time, the link wrapper adds in the objects in
+     the repository and compiles any needed instances that were not
+     previously emitted.  The advantages of this model are more optimal
+     compilation speed and the ability to use the system linker; to
+     implement the Borland model a compiler vendor also needs to
+     replace the linker.  The disadvantages are vastly increased
+     complexity, and thus potential for error; for some code this can be
+     just as transparent, but in practice it can been very difficult to
+     build multiple programs in one directory and one program in
+     multiple directories.  Code written for this model tends to
+     separate definitions of non-inline member templates into a
+     separate file, which should be compiled separately.
+
+   When used with GNU ld version 2.8 or later on an ELF system such as
+Linux/GNU or Solaris 2, or on Microsoft Windows, g++ supports the
+Borland model.  On other systems, g++ implements neither automatic
+model.
+
+   A future version of g++ will support a hybrid model whereby the
+compiler will emit any instantiations for which the template definition
+is included in the compile, and store template definitions and
+instantiation context information into the object file for the rest.
+The link wrapper will extract that information as necessary and invoke
+the compiler to produce the remaining instantiations.  The linker will
+then combine duplicate instantiations.
+
+   In the mean time, you have the following options for dealing with
+template instantiations:
+
+  1. Compile your template-using code with `-frepo'.  The compiler will
+     generate files with the extension `.rpo' listing all of the
+     template instantiations used in the corresponding object files
+     which could be instantiated there; the link wrapper, `collect2',
+     will then update the `.rpo' files to tell the compiler where to
+     place those instantiations and rebuild any affected object files.
+     The link-time overhead is negligible after the first pass, as the
+     compiler will continue to place the instantiations in the same
+     files.
+
+     This is your best option for application code written for the
+     Borland model, as it will just work.  Code written for the Cfront
+     model will need to be modified so that the template definitions
+     are available at one or more points of instantiation; usually this
+     is as simple as adding `#include <tmethods.cc>' to the end of each
+     template header.
+
+     For library code, if you want the library to provide all of the
+     template instantiations it needs, just try to link all of its
+     object files together; the link will fail, but cause the
+     instantiations to be generated as a side effect.  Be warned,
+     however, that this may cause conflicts if multiple libraries try
+     to provide the same instantiations.  For greater control, use
+     explicit instantiation as described in the next option.
+
+  2. Compile your code with `-fno-implicit-templates' to disable the
+     implicit generation of template instances, and explicitly
+     instantiate all the ones you use.  This approach requires more
+     knowledge of exactly which instances you need than do the others,
+     but it's less mysterious and allows greater control.  You can
+     scatter the explicit instantiations throughout your program,
+     perhaps putting them in the translation units where the instances
+     are used or the translation units that define the templates
+     themselves; you can put all of the explicit instantiations you
+     need into one big file; or you can create small files like
+
+          #include "Foo.h"
+          #include "Foo.cc"
+          
+          template class Foo<int>;
+          template ostream& operator <<
+                          (ostream&, const Foo<int>&);
+
+     for each of the instances you need, and create a template
+     instantiation library from those.
+
+     If you are using Cfront-model code, you can probably get away with
+     not using `-fno-implicit-templates' when compiling files that don't
+     `#include' the member template definitions.
+
+     If you use one big file to do the instantiations, you may want to
+     compile it without `-fno-implicit-templates' so you get all of the
+     instances required by your explicit instantiations (but not by any
+     other files) without having to specify them as well.
+
+     g++ has extended the template instantiation syntax outlined in the
+     Working Paper to allow forward declaration of explicit
+     instantiations and instantiation of the compiler support data for
+     a template class (i.e. the vtable) without instantiating any of
+     its members:
+
+          extern template int max (int, int);
+          inline template class Foo<int>;
+
+  3. Do nothing.  Pretend g++ does implement automatic instantiation
+     management.  Code written for the Borland model will work fine, but
+     each translation unit will contain instances of each of the
+     templates it uses.  In a large program, this can lead to an
+     unacceptable amount of code duplication.
+
+  4. Add `#pragma interface' to all files containing template
+     definitions.  For each of these files, add `#pragma implementation
+     "FILENAME"' to the top of some `.C' file which `#include's it.
+     Then compile everything with `-fexternal-templates'.  The
+     templates will then only be expanded in the translation unit which
+     implements them (i.e. has a `#pragma implementation' line for the
+     file where they live); all other files will use external
+     references.  If you're lucky, everything should work properly.  If
+     you get undefined symbol errors, you need to make sure that each
+     template instance which is used in the program is used in the file
+     which implements that template.  If you don't have any use for a
+     particular instance in that file, you can just instantiate it
+     explicitly, using the syntax from the latest C++ working paper:
+
+          template class A<int>;
+          template ostream& operator << (ostream&, const A<int>&);
+
+     This strategy will work with code written for either model.  If
+     you are using code written for the Cfront model, the file
+     containing a class template and the file containing its member
+     templates should be implemented in the same translation unit.
+
+     A slight variation on this approach is to instead use the flag
+     `-falt-external-templates'; this flag causes template instances to
+     be emitted in the translation unit that implements the header
+     where they are first instantiated, rather than the one which
+     implements the file where the templates are defined.  This header
+     must be the same in all translation units, or things are likely to
+     break.
+
+     *Note Declarations and Definitions in One Header: C++ Interface,
+     for more discussion of these pragmas.
+
+
+File: gcc.info,  Node: Bound member functions,  Next: C++ Signatures,  Prev: Template Instantiation,  Up: C++ Extensions
+
+Extracting the function pointer from a bound pointer to member function
+=======================================================================
+
+   In C++, pointer to member functions (PMFs) are implemented using a
+wide pointer of sorts to handle all the possible call mechanisms; the
+PMF needs to store information about how to adjust the `this' pointer,
+and if the function pointed to is virtual, where to find the vtable, and
+where in the vtable to look for the member function.  If you are using
+PMFs in an inner loop, you should really reconsider that decision.  If
+that is not an option, you can extract the pointer to the function that
+would be called for a given object/PMF pair and call it directly inside
+the inner loop, to save a bit of time.
+
+   Note that you will still be paying the penalty for the call through a
+function pointer; on most modern architectures, such a call defeats the
+branch prediction features of the CPU.  This is also true of normal
+virtual function calls.
+
+   The syntax for this extension is
+
+     extern A a;
+     extern int (A::*fp)();
+     typedef int (*fptr)(A *);
+     
+     fptr p = (fptr)(a.*fp);
+
+   You must specify `-Wno-pmf-conversions' to use this extension.
+
+
+File: gcc.info,  Node: C++ Signatures,  Prev: Bound member functions,  Up: C++ Extensions
+
+Type Abstraction using Signatures
+=================================
+
+   In GNU C++, you can use the keyword `signature' to define a
+completely abstract class interface as a datatype.  You can connect this
+abstraction with actual classes using signature pointers.  If you want
+to use signatures, run the GNU compiler with the `-fhandle-signatures'
+command-line option.  (With this option, the compiler reserves a second
+keyword `sigof' as well, for a future extension.)
+
+   Roughly, signatures are type abstractions or interfaces of classes.
+Some other languages have similar facilities.  C++ signatures are
+related to ML's signatures, Haskell's type classes, definition modules
+in Modula-2, interface modules in Modula-3, abstract types in Emerald,
+type modules in Trellis/Owl, categories in Scratchpad II, and types in
+POOL-I.  For a more detailed discussion of signatures, see `Signatures:
+A Language Extension for Improving Type Abstraction and Subtype
+Polymorphism in C++' by Gerald Baumgartner and Vincent F. Russo (Tech
+report CSD-TR-95-051, Dept. of Computer Sciences, Purdue University,
+August 1995, a slightly improved version appeared in
+*Software--Practice & Experience*, 25(8), pp. 863-889, August 1995).
+You can get the tech report by anonymous FTP from `ftp.cs.purdue.edu'
+in `pub/gb/Signature-design.ps.gz'.
+
+   Syntactically, a signature declaration is a collection of member
+function declarations and nested type declarations.  For example, this
+signature declaration defines a new abstract type `S' with member
+functions `int foo ()' and `int bar (int)':
+
+     signature S
+     {
+       int foo ();
+       int bar (int);
+     };
+
+   Since signature types do not include implementation definitions, you
+cannot write an instance of a signature directly.  Instead, you can
+define a pointer to any class that contains the required interfaces as a
+"signature pointer".  Such a class "implements" the signature type.
+
+   To use a class as an implementation of `S', you must ensure that the
+class has public member functions `int foo ()' and `int bar (int)'.
+The class can have other member functions as well, public or not; as
+long as it offers what's declared in the signature, it is suitable as
+an implementation of that signature type.
+
+   For example, suppose that `C' is a class that meets the requirements
+of signature `S' (`C' "conforms to" `S').  Then
+
+     C obj;
+     S * p = &obj;
+
+defines a signature pointer `p' and initializes it to point to an
+object of type `C'.  The member function call `int i = p->foo ();'
+executes `obj.foo ()'.
+
+   Abstract virtual classes provide somewhat similar facilities in
+standard C++.  There are two main advantages to using signatures
+instead:
+
+  1. Subtyping becomes independent from inheritance.  A class or
+     signature type `T' is a subtype of a signature type `S'
+     independent of any inheritance hierarchy as long as all the member
+     functions declared in `S' are also found in `T'.  So you can
+     define a subtype hierarchy that is completely independent from any
+     inheritance (implementation) hierarchy, instead of being forced to
+     use types that mirror the class inheritance hierarchy.
+
+  2. Signatures allow you to work with existing class hierarchies as
+     implementations of a signature type.  If those class hierarchies
+     are only available in compiled form, you're out of luck with
+     abstract virtual classes, since an abstract virtual class cannot
+     be retrofitted on top of existing class hierarchies.  So you would
+     be required to write interface classes as subtypes of the abstract
+     virtual class.
+
+   There is one more detail about signatures.  A signature declaration
+can contain member function *definitions* as well as member function
+declarations.  A signature member function with a full definition is
+called a *default implementation*; classes need not contain that
+particular interface in order to conform.  For example, a class `C' can
+conform to the signature
+
+     signature T
+     {
+       int f (int);
+       int f0 () { return f (0); };
+     };
+
+whether or not `C' implements the member function `int f0 ()'.  If you
+define `C::f0', that definition takes precedence; otherwise, the
+default implementation `S::f0' applies.
+
+
+File: gcc.info,  Node: Gcov,  Next: Trouble,  Prev: C++ Extensions,  Up: Top
+
+`gcov': a Test Coverage Program
+*******************************
+
+   `gcov' is a tool you can use in conjunction with GNU CC to test code
+coverage in your programs.
+
+   This chapter describes version 1.5 of `gcov'.
+
+* Menu:
+
+* Gcov Intro::         	        Introduction to gcov.
+* Invoking Gcov::       	How to use gcov.
+* Gcov and Optimization::       Using gcov with GCC optimization.
+* Gcov Data Files::             The files used by gcov.
+
+
+File: gcc.info,  Node: Gcov Intro,  Next: Invoking Gcov,  Up: Gcov
+
+Introduction to `gcov'
+======================
+
+   `gcov' is a test coverage program.  Use it in concert with GNU CC to
+analyze your programs to help create more efficient, faster running
+code.  You can use `gcov' as a profiling tool to help discover where
+your optimization efforts will best affect your code.  You can also use
+`gcov' along with the other profiling tool, `gprof', to assess which
+parts of your code use the greatest amount of computing time.
+
+   Profiling tools help you analyze your code's performance.  Using a
+profiler such as `gcov' or `gprof', you can find out some basic
+performance statistics, such as:
+
+   * how often each line of code executes
+
+   * what lines of code are actually executed
+
+   * how much computing time each section of code uses
+
+   Once you know these things about how your code works when compiled,
+you can look at each module to see which modules should be optimized.
+`gcov' helps you determine where to work on optimization.
+
+   Software developers also use coverage testing in concert with
+testsuites, to make sure software is actually good enough for a release.
+Testsuites can verify that a program works as expected; a coverage
+program tests to see how much of the program is exercised by the
+testsuite.  Developers can then determine what kinds of test cases need
+to be added to the testsuites to create both better testing and a better
+final product.
+
+   You should compile your code without optimization if you plan to use
+`gcov' because the optimization, by combining some lines of code into
+one function, may not give you as much information as you need to look
+for `hot spots' where the code is using a great deal of computer time.
+Likewise, because `gcov' accumulates statistics by line (at the lowest
+resolution), it works best with a programming style that places only
+one statement on each line.  If you use complicated macros that expand
+to loops or to other control structures, the statistics are less
+helpful--they only report on the line where the macro call appears.  If
+your complex macros behave like functions, you can replace them with
+inline functions to solve this problem.
+
+   `gcov' creates a logfile called `SOURCEFILE.gcov' which indicates
+how many times each line of a source file `SOURCEFILE.c' has executed.
+You can use these logfiles along with `gprof' to aid in fine-tuning the
+performance of your programs.  `gprof' gives timing information you can
+use along with the information you get from `gcov'.
+
+   `gcov' works only on code compiled with GNU CC.  It is not
+compatible with any other profiling or test coverage mechanism.
+
+
+File: gcc.info,  Node: Invoking Gcov,  Next: Gcov and Optimization,  Prev: Gcov Intro,  Up: Gcov
+
+Invoking gcov
+=============
+
+     gcov [-b] [-v] [-n] [-l] [-f] [-o directory] SOURCEFILE
+
+`-b'
+     Write branch frequencies to the output file, and write branch
+     summary info to the standard output.  This option allows you to
+     see how often each branch in your program was taken.
+
+`-v'
+     Display the `gcov' version number (on the standard error stream).
+
+`-n'
+     Do not create the `gcov' output file.
+
+`-l'
+     Create long file names for included source files.  For example, if
+     the header file `x.h' contains code, and was included in the file
+     `a.c', then running `gcov' on the file `a.c' will produce an
+     output file called `a.c.x.h.gcov' instead of `x.h.gcov'.  This can
+     be useful if `x.h' is included in multiple source files.
+
+`-f'
+     Output summaries for each function in addition to the file level
+     summary.
+
+`-o'
+     The directory where the object files live.  Gcov will search for
+     `.bb', `.bbg', and `.da' files in this directory.
+
+   When using `gcov', you must first compile your program with two
+special GNU CC options: `-fprofile-arcs -ftest-coverage'.  This tells
+the compiler to generate additional information needed by gcov
+(basically a flow graph of the program) and also includes additional
+code in the object files for generating the extra profiling information
+needed by gcov.  These additional files are placed in the directory
+where the source code is located.
+
+   Running the program will cause profile output to be generated.  For
+each source file compiled with -fprofile-arcs, an accompanying `.da'
+file will be placed in the source directory.
+
+   Running `gcov' with your program's source file names as arguments
+will now produce a listing of the code along with frequency of execution
+for each line.  For example, if your program is called `tmp.c', this is
+what you see when you use the basic `gcov' facility:
+
+     $ gcc -fprofile-arcs -ftest-coverage tmp.c
+     $ a.out
+     $ gcov tmp.c
+      87.50% of 8 source lines executed in file tmp.c
+     Creating tmp.c.gcov.
+
+   The file `tmp.c.gcov' contains output from `gcov'.  Here is a sample:
+
+                     main()
+                     {
+                1      int i, total;
+     
+                1      total = 0;
+     
+               11      for (i = 0; i < 10; i++)
+               10        total += i;
+     
+                1      if (total != 45)
+           ######        printf ("Failure\n");
+                       else
+                1        printf ("Success\n");
+                1    }
+
+   When you use the `-b' option, your output looks like this:
+
+     $ gcov -b tmp.c
+      87.50% of 8 source lines executed in file tmp.c
+      80.00% of 5 branches executed in file tmp.c
+      80.00% of 5 branches taken at least once in file tmp.c
+      50.00% of 2 calls executed in file tmp.c
+     Creating tmp.c.gcov.
+
+   Here is a sample of a resulting `tmp.c.gcov' file:
+
+                     main()
+                     {
+                1      int i, total;
+     
+                1      total = 0;
+     
+               11      for (i = 0; i < 10; i++)
+     branch 0 taken = 91%
+     branch 1 taken = 100%
+     branch 2 taken = 100%
+               10        total += i;
+     
+                1      if (total != 45)
+     branch 0 taken = 100%
+           ######        printf ("Failure\n");
+     call 0 never executed
+     branch 1 never executed
+                       else
+                1        printf ("Success\n");
+     call 0 returns = 100%
+                1    }
+
+   For each basic block, a line is printed after the last line of the
+basic block describing the branch or call that ends the basic block.
+There can be multiple branches and calls listed for a single source
+line if there are multiple basic blocks that end on that line.  In this
+case, the branches and calls are each given a number.  There is no
+simple way to map these branches and calls back to source constructs.
+In general, though, the lowest numbered branch or call will correspond
+to the leftmost construct on the source line.
+
+   For a branch, if it was executed at least once, then a percentage
+indicating the number of times the branch was taken divided by the
+number of times the branch was executed will be printed.  Otherwise, the
+message "never executed" is printed.
+
+   For a call, if it was executed at least once, then a percentage
+indicating the number of times the call returned divided by the number
+of times the call was executed will be printed.  This will usually be
+100%, but may be less for functions call `exit' or `longjmp', and thus
+may not return everytime they are called.
+
+   The execution counts are cumulative.  If the example program were
+executed again without removing the `.da' file, the count for the
+number of times each line in the source was executed would be added to
+the results of the previous run(s).  This is potentially useful in
+several ways.  For example, it could be used to accumulate data over a
+number of program runs as part of a test verification suite, or to
+provide more accurate long-term information over a large number of
+program runs.
+
+   The data in the `.da' files is saved immediately before the program
+exits.  For each source file compiled with -fprofile-arcs, the profiling
+code first attempts to read in an existing `.da' file; if the file
+doesn't match the executable (differing number of basic block counts) it
+will ignore the contents of the file.  It then adds in the new execution
+counts and finally writes the data to the file.
+
+
+File: gcc.info,  Node: Gcov and Optimization,  Next: Gcov Data Files,  Prev: Invoking Gcov,  Up: Gcov
+
+Using `gcov' with GCC Optimization
+==================================
+
+   If you plan to use `gcov' to help optimize your code, you must first
+compile your program with two special GNU CC options: `-fprofile-arcs
+-ftest-coverage'.  Aside from that, you can use any other GNU CC
+options; but if you want to prove that every single line in your
+program was executed, you should not compile with optimization at the
+same time.  On some machines the optimizer can eliminate some simple
+code lines by combining them with other lines.  For example, code like
+this:
+
+     if (a != b)
+       c = 1;
+     else
+       c = 0;
+
+can be compiled into one instruction on some machines.  In this case,
+there is no way for `gcov' to calculate separate execution counts for
+each line because there isn't separate code for each line.  Hence the
+`gcov' output looks like this if you compiled the program with
+optimization:
+
+           100  if (a != b)
+           100    c = 1;
+           100  else
+           100    c = 0;
+
+   The output shows that this block of code, combined by optimization,
+executed 100 times.  In one sense this result is correct, because there
+was only one instruction representing all four of these lines.  However,
+the output does not indicate how many times the result was 0 and how
+many times the result was 1.
+
+
+File: gcc.info,  Node: Gcov Data Files,  Prev: Gcov and Optimization,  Up: Gcov
+
+Brief description of `gcov' data files
+======================================
+
+   `gcov' uses three files for doing profiling.  The names of these
+files are derived from the original *source* file by substituting the
+file suffix with either `.bb', `.bbg', or `.da'.  All of these files
+are placed in the same directory as the source file, and contain data
+stored in a platform-independent method.
+
+   The `.bb' and `.bbg' files are generated when the source file is
+compiled with the GNU CC `-ftest-coverage' option.  The `.bb' file
+contains a list of source files (including headers), functions within
+those files, and line numbers corresponding to each basic block in the
+source file.
+
+   The `.bb' file format consists of several lists of 4-byte integers
+which correspond to the line numbers of each basic block in the file.
+Each list is terminated by a line number of 0.  A line number of -1 is
+used to designate that the source file name (padded to a 4-byte
+boundary and followed by another -1) follows.  In addition, a line
+number of -2 is used to designate that the name of a function (also
+padded to a 4-byte boundary and followed by a -2) follows.
+
+   The `.bbg' file is used to reconstruct the program flow graph for
+the source file.  It contains a list of the program flow arcs (possible
+branches taken from one basic block to another) for each function which,
+in combination with the `.bb' file, enables gcov to reconstruct the
+program flow.
+
+   In the `.bbg' file, the format is:
+             number of basic blocks for function #0 (4-byte number)
+             total number of arcs for function #0 (4-byte number)
+             count of arcs in basic block #0 (4-byte number)
+             destination basic block of arc #0 (4-byte number)
+             flag bits (4-byte number)
+             destination basic block of arc #1 (4-byte number)
+             flag bits (4-byte number)
+             ...
+             destination basic block of arc #N (4-byte number)
+             flag bits (4-byte number)
+             count of arcs in basic block #1 (4-byte number)
+             destination basic block of arc #0 (4-byte number)
+             flag bits (4-byte number)
+             ...
+
+   A -1 (stored as a 4-byte number) is used to separate each function's
+list of basic blocks, and to verify that the file has been read
+correctly.
+
+   The `.da' file is generated when a program containing object files
+built with the GNU CC `-fprofile-arcs' option is executed.  A separate
+`.da' file is created for each source file compiled with this option,
+and the name of the `.da' file is stored as an absolute pathname in the
+resulting object file.  This path name is derived from the source file
+name by substituting a `.da' suffix.
+
+   The format of the `.da' file is fairly simple.  The first 8-byte
+number is the number of counts in the file, followed by the counts
+(stored as 8-byte numbers).  Each count corresponds to the number of
+times each arc in the program is executed.  The counts are cumulative;
+each time the program is executed, it attemps to combine the existing
+`.da' files with the new counts for this invocation of the program.  It
+ignores the contents of any `.da' files whose number of arcs doesn't
+correspond to the current program, and merely overwrites them instead.
+
+   All three of these files use the functions in `gcov-io.h' to store
+integers; the functions in this header provide a machine-independent
+mechanism for storing and retrieving data from a stream.
+
+
+File: gcc.info,  Node: Trouble,  Next: Bugs,  Prev: Gcov,  Up: Top
+
+Known Causes of Trouble with GCC
+********************************
+
+   This section describes known problems that affect users of GCC.  Most
+of these are not GCC bugs per se--if they were, we would fix them.  But
+the result for a user may be like the result of a bug.
+
+   Some of these problems are due to bugs in other software, some are
+missing features that are too much work to add, and some are places
+where people's opinions differ as to what is best.
+
+* Menu:
+
+* Actual Bugs::		      Bugs we will fix later.
+* Installation Problems::     Problems that manifest when you install GCC.
+* Cross-Compiler Problems::   Common problems of cross compiling with GCC.
+* Interoperation::      Problems using GCC with other compilers,
+			   and with certain linkers, assemblers and debuggers.
+* External Bugs::	Problems compiling certain programs.
+* Incompatibilities::   GCC is incompatible with traditional C.
+* Fixed Headers::       GNU C uses corrected versions of system header files.
+                           This is necessary, but doesn't always work smoothly.
+* Standard Libraries::  GNU C uses the system C library, which might not be
+                           compliant with the ISO/ANSI C standard.
+* Disappointments::     Regrettable things we can't change, but not quite bugs.
+* C++ Misunderstandings::     Common misunderstandings with GNU C++.
+* Protoize Caveats::    Things to watch out for when using `protoize'.
+* Non-bugs::		Things we think are right, but some others disagree.
+* Warnings and Errors:: Which problems in your code get warnings,
+                         and which get errors.
+
+
+File: gcc.info,  Node: Actual Bugs,  Next: Installation Problems,  Up: Trouble
+
+Actual Bugs We Haven't Fixed Yet
+================================
+
+   * The `fixincludes' script interacts badly with automounters; if the
+     directory of system header files is automounted, it tends to be
+     unmounted while `fixincludes' is running.  This would seem to be a
+     bug in the automounter.  We don't know any good way to work around
+     it.
+
+   * The `fixproto' script will sometimes add prototypes for the
+     `sigsetjmp' and `siglongjmp' functions that reference the
+     `jmp_buf' type before that type is defined.  To work around this,
+     edit the offending file and place the typedef in front of the
+     prototypes.
+
+   * There are several obscure case of mis-using struct, union, and
+     enum tags that are not detected as errors by the compiler.
+
+   * When `-pedantic-errors' is specified, GCC will incorrectly give an
+     error message when a function name is specified in an expression
+     involving the comma operator.
+
+   * Loop unrolling doesn't work properly for certain C++ programs.
+     This is a bug in the C++ front end.  It sometimes emits incorrect
+     debug info, and the loop unrolling code is unable to recover from
+     this error.
+

usr/local/nachos/info/gcc.info-2

@@ -0,0 +1,837 @@
+This is Info file gcc.info, produced by Makeinfo version 1.68 from the
+input file ../../gcc-2.95.2/gcc/gcc.texi.
+
+INFO-DIR-SECTION Programming
+START-INFO-DIR-ENTRY
+* gcc: (gcc).                  The GNU Compiler Collection.
+END-INFO-DIR-ENTRY
+   This file documents the use and the internals of the GNU compiler.
+
+   Published by the Free Software Foundation 59 Temple Place - Suite 330
+Boston, MA 02111-1307 USA
+
+   Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
+1999 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 sections entitled "GNU General Public License" and "Funding
+for Free Software" are included exactly as in the original, and
+provided 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, except that the sections entitled "GNU General Public
+License" and "Funding for Free Software", and this permission notice,
+may be included in translations approved by the Free Software Foundation
+instead of in the original English.
+
+
+File: gcc.info,  Node: C++ Dialect Options,  Next: Warning Options,  Prev: C Dialect Options,  Up: Invoking GCC
+
+Options Controlling C++ Dialect
+===============================
+
+   This section describes the command-line options that are only
+meaningful for C++ programs; but you can also use most of the GNU
+compiler options regardless of what language your program is in.  For
+example, you might compile a file `firstClass.C' like this:
+
+     g++ -g -frepo -O -c firstClass.C
+
+In this example, only `-frepo' is an option meant only for C++
+programs; you can use the other options with any language supported by
+GCC.
+
+   Here is a list of options that are *only* for compiling C++ programs:
+
+`-fno-access-control'
+     Turn off all access checking.  This switch is mainly useful for
+     working around bugs in the access control code.
+
+`-fcheck-new'
+     Check that the pointer returned by `operator new' is non-null
+     before attempting to modify the storage allocated.  The current
+     Working Paper requires that `operator new' never return a null
+     pointer, so this check is normally unnecessary.
+
+     An alternative to using this option is to specify that your
+     `operator new' does not throw any exceptions; if you declare it
+     `throw()', g++ will check the return value.  See also `new
+     (nothrow)'.
+
+`-fconserve-space'
+     Put uninitialized or runtime-initialized global variables into the
+     common segment, as C does.  This saves space in the executable at
+     the cost of not diagnosing duplicate definitions.  If you compile
+     with this flag and your program mysteriously crashes after
+     `main()' has completed, you may have an object that is being
+     destroyed twice because two definitions were merged.
+
+     This option is no longer useful on most targets, now that support
+     has been added for putting variables into BSS without making them
+     common.
+
+`-fdollars-in-identifiers'
+     Accept `$' in identifiers.  You can also explicitly prohibit use of
+     `$' with the option `-fno-dollars-in-identifiers'.  (GNU C allows
+     `$' by default on most target systems, but there are a few
+     exceptions.)  Traditional C allowed the character `$' to form part
+     of identifiers.  However, ANSI C and C++ forbid `$' in identifiers.
+
+`-fno-elide-constructors'
+     The C++ standard allows an implementation to omit creating a
+     temporary which is only used to initialize another object of the
+     same type.  Specifying this option disables that optimization, and
+     forces g++ to call the copy constructor in all cases.
+
+`-fexternal-templates'
+     Cause template instantiations to obey `#pragma interface' and
+     `implementation'; template instances are emitted or not according
+     to the location of the template definition.  *Note Template
+     Instantiation::, for more information.
+
+     This option is deprecated.
+
+`-falt-external-templates'
+     Similar to -fexternal-templates, but template instances are
+     emitted or not according to the place where they are first
+     instantiated.  *Note Template Instantiation::, for more
+     information.
+
+     This option is deprecated.
+
+`-ffor-scope'
+`-fno-for-scope'
+     If -ffor-scope is specified, the scope of variables declared in a
+     for-init-statement is limited to the `for' loop itself, as
+     specified by the draft C++ standard.  If -fno-for-scope is
+     specified, the scope of variables declared in a for-init-statement
+     extends to the end of the enclosing scope, as was the case in old
+     versions of gcc, and other (traditional) implementations of C++.
+
+     The default if neither flag is given to follow the standard, but
+     to allow and give a warning for old-style code that would
+     otherwise be invalid, or have different behavior.
+
+`-fno-gnu-keywords'
+     Do not recognize `classof', `headof', `signature', `sigof' or
+     `typeof' as a keyword, so that code can use these words as
+     identifiers.  You can use the keywords `__classof__',
+     `__headof__', `__signature__', `__sigof__', and `__typeof__'
+     instead.  `-ansi' implies `-fno-gnu-keywords'.
+
+`-fguiding-decls'
+     Treat a function declaration with the same type as a potential
+     function template instantiation as though it declares that
+     instantiation, not a normal function.  If a definition is given
+     for the function later in the translation unit (or another
+     translation unit if the target supports weak symbols), that
+     definition will be used; otherwise the template will be
+     instantiated.  This behavior reflects the C++ language prior to
+     September 1996, when guiding declarations were removed.
+
+     This option implies `-fname-mangling-version-0', and will not work
+     with other name mangling versions.  Like all options that change
+     the ABI, all C++ code, *including libgcc.a* must be built with the
+     same setting of this option.
+
+`-fhandle-signatures'
+     Recognize the `signature' and `sigof' keywords for specifying
+     abstract types.  The default (`-fno-handle-signatures') is not to
+     recognize them.  *Note Type Abstraction using Signatures: C++
+     Signatures.
+
+`-fhonor-std'
+     Treat the `namespace std' as a namespace, instead of ignoring it.
+     For compatibility with earlier versions of g++, the compiler will,
+     by default, ignore `namespace-declarations', `using-declarations',
+     `using-directives', and `namespace-names', if they involve `std'.
+
+`-fhuge-objects'
+     Support virtual function calls for objects that exceed the size
+     representable by a `short int'.  Users should not use this flag by
+     default; if you need to use it, the compiler will tell you so.
+
+     This flag is not useful when compiling with -fvtable-thunks.
+
+     Like all options that change the ABI, all C++ code, *including
+     libgcc* must be built with the same setting of this option.
+
+`-fno-implicit-templates'
+     Never emit code for non-inline templates which are instantiated
+     implicitly (i.e. by use); only emit code for explicit
+     instantiations.  *Note Template Instantiation::, for more
+     information.
+
+`-fno-implicit-inline-templates'
+     Don't emit code for implicit instantiations of inline templates,
+     either.  The default is to handle inlines differently so that
+     compiles with and without optimization will need the same set of
+     explicit instantiations.
+
+`-finit-priority'
+     Support `__attribute__ ((init_priority (n)))' for controlling the
+     order of initialization of file-scope objects.  On ELF targets,
+     this requires GNU ld 2.10 or later.
+
+`-fno-implement-inlines'
+     To save space, do not emit out-of-line copies of inline functions
+     controlled by `#pragma implementation'.  This will cause linker
+     errors if these functions are not inlined everywhere they are
+     called.
+
+`-fname-mangling-version-N'
+     Control the way in which names are mangled.  Version 0 is
+     compatible with versions of g++ before 2.8.  Version 1 is the
+     default.  Version 1 will allow correct mangling of function
+     templates.  For example, version 0 mangling does not mangle
+     foo<int, double> and foo<int, char> given this declaration:
+
+          template <class T, class U> void foo(T t);
+
+     Like all options that change the ABI, all C++ code, *including
+     libgcc* must be built with the same setting of this option.
+
+`-foperator-names'
+     Recognize the operator name keywords `and', `bitand', `bitor',
+     `compl', `not', `or' and `xor' as synonyms for the symbols they
+     refer to.  `-ansi' implies `-foperator-names'.
+
+`-fno-optional-diags'
+     Disable diagnostics that the standard says a compiler does not
+     need to issue.  Currently, the only such diagnostic issued by g++
+     is the one for a name having multiple meanings within a class.
+
+`-fpermissive'
+     Downgrade messages about nonconformant code from errors to
+     warnings.  By default, g++ effectively sets `-pedantic-errors'
+     without `-pedantic'; this option reverses that.  This behavior and
+     this option are superceded by `-pedantic', which works as it does
+     for GNU C.
+
+`-frepo'
+     Enable automatic template instantiation.  This option also implies
+     `-fno-implicit-templates'.  *Note Template Instantiation::, for
+     more information.
+
+`-fno-rtti'
+     Disable generation of the information used by C++ runtime type
+     identification features (`dynamic_cast' and `typeid').  If you
+     don't use those parts of the language (or exception handling,
+     which uses `dynamic_cast' internally), you can save some space by
+     using this flag.
+
+`-fstrict-prototype'
+     Within an `extern "C"' linkage specification, treat a function
+     declaration with no arguments, such as `int foo ();', as declaring
+     the function to take no arguments.  Normally, such a declaration
+     means that the function `foo' can take any combination of
+     arguments, as in C.  `-pedantic' implies `-fstrict-prototype'
+     unless overridden with `-fno-strict-prototype'.
+
+     Specifying this option will also suppress implicit declarations of
+     functions.
+
+     This flag no longer affects declarations with C++ linkage.
+
+`-fsquangle'
+`-fno-squangle'
+     `-fsquangle' will enable a compressed form of name mangling for
+     identifiers. In particular, it helps to shorten very long names by
+     recognizing types and class names which occur more than once,
+     replacing them with special short ID codes.  This option also
+     requires any C++ libraries being used to be compiled with this
+     option as well.  The compiler has this disabled (the equivalent of
+     `-fno-squangle') by default.
+
+     Like all options that change the ABI, all C++ code, *including
+     libgcc.a* must be built with the same setting of this option.
+
+`-ftemplate-depth-N'
+     Set the maximum instantiation depth for template classes to N.  A
+     limit on the template instantiation depth is needed to detect
+     endless recursions during template class instantiation. ANSI/ISO
+     C++ conforming programs must not rely on a maximum depth greater
+     than 17.
+
+`-fthis-is-variable'
+     Permit assignment to `this'.  The incorporation of user-defined
+     free store management into C++ has made assignment to `this' an
+     anachronism.  Therefore, by default it is invalid to assign to
+     `this' within a class member function; that is, GNU C++ treats
+     `this' in a member function of class `X' as a non-lvalue of type
+     `X *'.  However, for backwards compatibility, you can make it
+     valid with `-fthis-is-variable'.
+
+`-fvtable-thunks'
+     Use `thunks' to implement the virtual function dispatch table
+     (`vtable').  The traditional (cfront-style) approach to
+     implementing vtables was to store a pointer to the function and two
+     offsets for adjusting the `this' pointer at the call site.  Newer
+     implementations store a single pointer to a `thunk' function which
+     does any necessary adjustment and then calls the target function.
+
+     This option also enables a heuristic for controlling emission of
+     vtables; if a class has any non-inline virtual functions, the
+     vtable will be emitted in the translation unit containing the
+     first one of those.
+
+     Like all options that change the ABI, all C++ code, *including
+     libgcc.a* must be built with the same setting of this option.
+
+`-nostdinc++'
+     Do not search for header files in the standard directories
+     specific to C++, but do still search the other standard
+     directories.  (This option is used when building the C++ library.)
+
+   In addition, these optimization, warning, and code generation options
+have meanings only for C++ programs:
+
+`-fno-default-inline'
+     Do not assume `inline' for functions defined inside a class scope.
+     *Note Options That Control Optimization: Optimize Options.  Note
+     that these functions will have linkage like inline functions; they
+     just won't be inlined by default.
+
+`-Wctor-dtor-privacy (C++ only)'
+     Warn when a class seems unusable, because all the constructors or
+     destructors in a class are private and the class has no friends or
+     public static member functions.
+
+`-Wnon-virtual-dtor (C++ only)'
+     Warn when a class declares a non-virtual destructor that should
+     probably be virtual, because it looks like the class will be used
+     polymorphically.
+
+`-Wreorder (C++ only)'
+     Warn when the order of member initializers given in the code does
+     not match the order in which they must be executed.  For instance:
+
+          struct A {
+            int i;
+            int j;
+            A(): j (0), i (1) { }
+          };
+
+     Here the compiler will warn that the member initializers for `i'
+     and `j' will be rearranged to match the declaration order of the
+     members.
+
+   The following `-W...' options are not affected by `-Wall'.
+
+`-Weffc++ (C++ only)'
+     Warn about violations of various style guidelines from Scott
+     Meyers' `Effective C++' books.  If you use this option, you should
+     be aware that the standard library headers do not obey all of
+     these guidelines; you can use `grep -v' to filter out those
+     warnings.
+
+`-Wno-deprecated (C++ only)'
+     Do not warn about usage of deprecated features. *Note Deprecated
+     Features::.
+
+`-Wno-non-template-friend (C++ only)'
+     Disable warnings when non-templatized friend functions are declared
+     within a template. With the advent of explicit template
+     specification support in g++, if the name of the friend is an
+     unqualified-id (ie, `friend foo(int)'), the C++ language
+     specification demands that the friend declare or define an
+     ordinary, nontemplate function. (Section 14.5.3). Before g++
+     implemented explicit specification, unqualified-ids could be
+     interpreted as a particular specialization of a templatized
+     function. Because this non-conforming behavior is no longer the
+     default behavior for g++, `-Wnon-template-friend' allows the
+     compiler to check existing code for potential trouble spots, and
+     is on by default.  This new compiler behavior can also be turned
+     off with the flag `-fguiding-decls', which activates the older,
+     non-specification compiler code, or with
+     `-Wno-non-template-friend' which keeps the conformant compiler
+     code but disables the helpful warning.
+
+`-Wold-style-cast (C++ only)'
+     Warn if an old-style (C-style) cast is used within a C++ program.
+     The new-style casts (`static_cast', `reinterpret_cast', and
+     `const_cast') are less vulnerable to unintended effects.
+
+`-Woverloaded-virtual (C++ only)'
+     Warn when a derived class function declaration may be an error in
+     defining a virtual function.  In a derived class, the definitions
+     of virtual functions must match the type signature of a virtual
+     function declared in the base class.  With this option, the
+     compiler warns when you define a function with the same name as a
+     virtual function, but with a type signature that does not match any
+     declarations from the base class.
+
+`-Wno-pmf-conversions (C++ only)'
+     Disable the diagnostic for converting a bound pointer to member
+     function to a plain pointer.
+
+`-Wsign-promo (C++ only)'
+     Warn when overload resolution chooses a promotion from unsigned or
+     enumeral type to a signed type over a conversion to an unsigned
+     type of the same size.  Previous versions of g++ would try to
+     preserve unsignedness, but the standard mandates the current
+     behavior.
+
+`-Wsynth (C++ only)'
+     Warn when g++'s synthesis behavior does not match that of cfront.
+     For instance:
+
+          struct A {
+            operator int ();
+            A& operator = (int);
+          };
+          
+          main ()
+          {
+            A a,b;
+            a = b;
+          }
+
+     In this example, g++ will synthesize a default `A& operator =
+     (const A&);', while cfront will use the user-defined `operator ='.
+
+
+File: gcc.info,  Node: Warning Options,  Next: Debugging Options,  Prev: C++ Dialect Options,  Up: Invoking GCC
+
+Options to Request or Suppress Warnings
+=======================================
+
+   Warnings are diagnostic messages that report constructions which are
+not inherently erroneous but which are risky or suggest there may have
+been an error.
+
+   You can request many specific warnings with options beginning `-W',
+for example `-Wimplicit' to request warnings on implicit declarations.
+Each of these specific warning options also has a negative form
+beginning `-Wno-' to turn off warnings; for example, `-Wno-implicit'.
+This manual lists only one of the two forms, whichever is not the
+default.
+
+   These options control the amount and kinds of warnings produced by
+GCC:
+
+`-fsyntax-only'
+     Check the code for syntax errors, but don't do anything beyond
+     that.
+
+`-pedantic'
+     Issue all the warnings demanded by strict ANSI C and ISO C++;
+     reject all programs that use forbidden extensions.
+
+     Valid ANSI C and ISO C++ programs should compile properly with or
+     without this option (though a rare few will require `-ansi').
+     However, without this option, certain GNU extensions and
+     traditional C and C++ features are supported as well.  With this
+     option, they are rejected.
+
+     `-pedantic' does not cause warning messages for use of the
+     alternate keywords whose names begin and end with `__'.  Pedantic
+     warnings are also disabled in the expression that follows
+     `__extension__'.  However, only system header files should use
+     these escape routes; application programs should avoid them.
+     *Note Alternate Keywords::.
+
+     This option is not intended to be useful; it exists only to satisfy
+     pedants who would otherwise claim that GCC fails to support the
+     ANSI standard.
+
+     Some users try to use `-pedantic' to check programs for strict ANSI
+     C conformance.  They soon find that it does not do quite what they
+     want: it finds some non-ANSI practices, but not all--only those
+     for which ANSI C *requires* a diagnostic.
+
+     A feature to report any failure to conform to ANSI C might be
+     useful in some instances, but would require considerable
+     additional work and would be quite different from `-pedantic'.  We
+     don't have plans to support such a feature in the near future.
+
+`-pedantic-errors'
+     Like `-pedantic', except that errors are produced rather than
+     warnings.
+
+`-w'
+     Inhibit all warning messages.
+
+`-Wno-import'
+     Inhibit warning messages about the use of `#import'.
+
+`-Wchar-subscripts'
+     Warn if an array subscript has type `char'.  This is a common cause
+     of error, as programmers often forget that this type is signed on
+     some machines.
+
+`-Wcomment'
+     Warn whenever a comment-start sequence `/*' appears in a `/*'
+     comment, or whenever a Backslash-Newline appears in a `//' comment.
+
+`-Wformat'
+     Check calls to `printf' and `scanf', etc., to make sure that the
+     arguments supplied have types appropriate to the format string
+     specified.
+
+`-Wimplicit-int'
+     Warn when a declaration does not specify a type.
+
+`-Wimplicit-function-declaration'
+`-Werror-implicit-function-declaration'
+     Give a warning (or error) whenever a function is used before being
+     declared.
+
+`-Wimplicit'
+     Same as `-Wimplicit-int' and `-Wimplicit-function-'
+     `declaration'.
+
+`-Wmain'
+     Warn if the type of `main' is suspicious.  `main' should be a
+     function with external linkage, returning int, taking either zero
+     arguments, two, or three arguments of appropriate types.
+
+`-Wmultichar'
+     Warn if a multicharacter constant (`'FOOF'') is used.  Usually they
+     indicate a typo in the user's code, as they have
+     implementation-defined values, and should not be used in portable
+     code.
+
+`-Wparentheses'
+     Warn if parentheses are omitted in certain contexts, such as when
+     there is an assignment in a context where a truth value is
+     expected, or when operators are nested whose precedence people
+     often get confused about.
+
+     Also warn about constructions where there may be confusion to which
+     `if' statement an `else' branch belongs.  Here is an example of
+     such a case:
+
+          {
+            if (a)
+              if (b)
+                foo ();
+            else
+              bar ();
+          }
+
+     In C, every `else' branch belongs to the innermost possible `if'
+     statement, which in this example is `if (b)'.  This is often not
+     what the programmer expected, as illustrated in the above example
+     by indentation the programmer chose.  When there is the potential
+     for this confusion, GNU C will issue a warning when this flag is
+     specified.  To eliminate the warning, add explicit braces around
+     the innermost `if' statement so there is no way the `else' could
+     belong to the enclosing `if'.  The resulting code would look like
+     this:
+
+          {
+            if (a)
+              {
+                if (b)
+                  foo ();
+                else
+                  bar ();
+              }
+          }
+
+`-Wreturn-type'
+     Warn whenever a function is defined with a return-type that
+     defaults to `int'.  Also warn about any `return' statement with no
+     return-value in a function whose return-type is not `void'.
+
+`-Wswitch'
+     Warn whenever a `switch' statement has an index of enumeral type
+     and lacks a `case' for one or more of the named codes of that
+     enumeration.  (The presence of a `default' label prevents this
+     warning.)  `case' labels outside the enumeration range also
+     provoke warnings when this option is used.
+
+`-Wtrigraphs'
+     Warn if any trigraphs are encountered (assuming they are enabled).
+
+`-Wunused'
+     Warn whenever a variable is unused aside from its declaration,
+     whenever a function is declared static but never defined, whenever
+     a label is declared but not used, and whenever a statement
+     computes a result that is explicitly not used.
+
+     In order to get a warning about an unused function parameter, you
+     must specify both `-W' and `-Wunused'.
+
+     To suppress this warning for an expression, simply cast it to
+     void.  For unused variables, parameters and labels, use the
+     `unused' attribute (*note Variable Attributes::.).
+
+`-Wuninitialized'
+     An automatic variable is used without first being initialized.
+
+     These warnings are possible only in optimizing compilation,
+     because they require data flow information that is computed only
+     when optimizing.  If you don't specify `-O', you simply won't get
+     these warnings.
+
+     These warnings occur only for variables that are candidates for
+     register allocation.  Therefore, they do not occur for a variable
+     that is declared `volatile', or whose address is taken, or whose
+     size is other than 1, 2, 4 or 8 bytes.  Also, they do not occur for
+     structures, unions or arrays, even when they are in registers.
+
+     Note that there may be no warning about a variable that is used
+     only to compute a value that itself is never used, because such
+     computations may be deleted by data flow analysis before the
+     warnings are printed.
+
+     These warnings are made optional because GCC is not smart enough
+     to see all the reasons why the code might be correct despite
+     appearing to have an error.  Here is one example of how this can
+     happen:
+
+          {
+            int x;
+            switch (y)
+              {
+              case 1: x = 1;
+                break;
+              case 2: x = 4;
+                break;
+              case 3: x = 5;
+              }
+            foo (x);
+          }
+
+     If the value of `y' is always 1, 2 or 3, then `x' is always
+     initialized, but GCC doesn't know this.  Here is another common
+     case:
+
+          {
+            int save_y;
+            if (change_y) save_y = y, y = new_y;
+            ...
+            if (change_y) y = save_y;
+          }
+
+     This has no bug because `save_y' is used only if it is set.
+
+     Some spurious warnings can be avoided if you declare all the
+     functions you use that never return as `noreturn'.  *Note Function
+     Attributes::.
+
+`-Wunknown-pragmas'
+     Warn when a #pragma directive is encountered which is not
+     understood by GCC.  If this command line option is used, warnings
+     will even be issued for unknown pragmas in system header files.
+     This is not the case if the warnings were only enabled by the
+     `-Wall' command line option.
+
+`-Wall'
+     All of the above `-W' options combined.  This enables all the
+     warnings about constructions that some users consider
+     questionable, and that are easy to avoid (or modify to prevent the
+     warning), even in conjunction with macros.
+
+   The following `-W...' options are not implied by `-Wall'.  Some of
+them warn about constructions that users generally do not consider
+questionable, but which occasionally you might wish to check for;
+others warn about constructions that are necessary or hard to avoid in
+some cases, and there is no simple way to modify the code to suppress
+the warning.
+
+`-W'
+     Print extra warning messages for these events:
+
+        * A nonvolatile automatic variable might be changed by a call to
+          `longjmp'.  These warnings as well are possible only in
+          optimizing compilation.
+
+          The compiler sees only the calls to `setjmp'.  It cannot know
+          where `longjmp' will be called; in fact, a signal handler
+          could call it at any point in the code.  As a result, you may
+          get a warning even when there is in fact no problem because
+          `longjmp' cannot in fact be called at the place which would
+          cause a problem.
+
+        * A function can return either with or without a value.
+          (Falling off the end of the function body is considered
+          returning without a value.)  For example, this function would
+          evoke such a warning:
+
+               foo (a)
+               {
+                 if (a > 0)
+                   return a;
+               }
+
+        * An expression-statement or the left-hand side of a comma
+          expression contains no side effects.  To suppress the
+          warning, cast the unused expression to void.  For example, an
+          expression such as `x[i,j]' will cause a warning, but
+          `x[(void)i,j]' will not.
+
+        * An unsigned value is compared against zero with `<' or `<='.
+
+        * A comparison like `x<=y<=z' appears; this is equivalent to
+          `(x<=y ? 1 : 0) <= z', which is a different interpretation
+          from that of ordinary mathematical notation.
+
+        * Storage-class specifiers like `static' are not the first
+          things in a declaration.  According to the C Standard, this
+          usage is obsolescent.
+
+        * If `-Wall' or `-Wunused' is also specified, warn about unused
+          arguments.
+
+        * A comparison between signed and unsigned values could produce
+          an incorrect result when the signed value is converted to
+          unsigned.  (But don't warn if `-Wno-sign-compare' is also
+          specified.)
+
+        * An aggregate has a partly bracketed initializer.  For
+          example, the following code would evoke such a warning,
+          because braces are missing around the initializer for `x.h':
+
+               struct s { int f, g; };
+               struct t { struct s h; int i; };
+               struct t x = { 1, 2, 3 };
+
+        * An aggregate has an initializer which does not initialize all
+          members.  For example, the following code would cause such a
+          warning, because `x.h' would be implicitly initialized to
+          zero:
+
+               struct s { int f, g, h; };
+               struct s x = { 3, 4 };
+
+`-Wtraditional'
+     Warn about certain constructs that behave differently in
+     traditional and ANSI C.
+
+        * Macro arguments occurring within string constants in the
+          macro body.  These would substitute the argument in
+          traditional C, but are part of the constant in ANSI C.
+
+        * A function declared external in one block and then used after
+          the end of the block.
+
+        * A `switch' statement has an operand of type `long'.
+
+        * A non-`static' function declaration follows a `static' one.
+          This construct is not accepted by some traditional C
+          compilers.
+
+`-Wundef'
+     Warn if an undefined identifier is evaluated in an `#if' directive.
+
+`-Wshadow'
+     Warn whenever a local variable shadows another local variable.
+
+`-Wid-clash-LEN'
+     Warn whenever two distinct identifiers match in the first LEN
+     characters.  This may help you prepare a program that will compile
+     with certain obsolete, brain-damaged compilers.
+
+`-Wlarger-than-LEN'
+     Warn whenever an object of larger than LEN bytes is defined.
+
+`-Wpointer-arith'
+     Warn about anything that depends on the "size of" a function type
+     or of `void'.  GNU C assigns these types a size of 1, for
+     convenience in calculations with `void *' pointers and pointers to
+     functions.
+
+`-Wbad-function-cast'
+     Warn whenever a function call is cast to a non-matching type.  For
+     example, warn if `int malloc()' is cast to `anything *'.
+
+`-Wcast-qual'
+     Warn whenever a pointer is cast so as to remove a type qualifier
+     from the target type.  For example, warn if a `const char *' is
+     cast to an ordinary `char *'.
+
+`-Wcast-align'
+     Warn whenever a pointer is cast such that the required alignment
+     of the target is increased.  For example, warn if a `char *' is
+     cast to an `int *' on machines where integers can only be accessed
+     at two- or four-byte boundaries.
+
+`-Wwrite-strings'
+     Give string constants the type `const char[LENGTH]' so that
+     copying the address of one into a non-`const' `char *' pointer
+     will get a warning.  These warnings will help you find at compile
+     time code that can try to write into a string constant, but only
+     if you have been very careful about using `const' in declarations
+     and prototypes.  Otherwise, it will just be a nuisance; this is
+     why we did not make `-Wall' request these warnings.
+
+`-Wconversion'
+     Warn if a prototype causes a type conversion that is different
+     from what would happen to the same argument in the absence of a
+     prototype.  This includes conversions of fixed point to floating
+     and vice versa, and conversions changing the width or signedness
+     of a fixed point argument except when the same as the default
+     promotion.
+
+     Also, warn if a negative integer constant expression is implicitly
+     converted to an unsigned type.  For example, warn about the
+     assignment `x = -1' if `x' is unsigned.  But do not warn about
+     explicit casts like `(unsigned) -1'.
+
+`-Wsign-compare'
+     Warn when a comparison between signed and unsigned values could
+     produce an incorrect result when the signed value is converted to
+     unsigned.  This warning is also enabled by `-W'; to get the other
+     warnings of `-W' without this warning, use `-W -Wno-sign-compare'.
+
+`-Waggregate-return'
+     Warn if any functions that return structures or unions are defined
+     or called.  (In languages where you can return an array, this also
+     elicits a warning.)
+
+`-Wstrict-prototypes'
+     Warn if a function is declared or defined without specifying the
+     argument types.  (An old-style function definition is permitted
+     without a warning if preceded by a declaration which specifies the
+     argument types.)
+
+`-Wmissing-prototypes'
+     Warn if a global function is defined without a previous prototype
+     declaration.  This warning is issued even if the definition itself
+     provides a prototype.  The aim is to detect global functions that
+     fail to be declared in header files.
+
+`-Wmissing-declarations'
+     Warn if a global function is defined without a previous
+     declaration.  Do so even if the definition itself provides a
+     prototype.  Use this option to detect global functions that are
+     not declared in header files.
+
+`-Wmissing-noreturn'
+     Warn about functions which might be candidates for attribute
+     `noreturn'.  Note these are only possible candidates, not absolute
+     ones.  Care should be taken to manually verify functions actually
+     do not ever return before adding the `noreturn' attribute,
+     otherwise subtle code generation bugs could be introduced.
+
+`-Wredundant-decls'
+     Warn if anything is declared more than once in the same scope,
+     even in cases where multiple declaration is valid and changes
+     nothing.
+
+`-Wnested-externs'
+     Warn if an `extern' declaration is encountered within an function.
+
+`-Winline'
+     Warn if a function can not be inlined, and either it was declared
+     as inline, or else the `-finline-functions' option was given.
+
+`-Wlong-long'
+     Warn if `long long' type is used.  This is default.  To inhibit
+     the warning messages, use `-Wno-long-long'.  Flags `-Wlong-long'
+     and `-Wno-long-long' are taken into account only when `-pedantic'
+     flag is used.
+
+`-Werror'
+     Make all warnings into errors.
+

usr/local/nachos/info/gcc.info-21

@@ -0,0 +1,886 @@
+This is Info file gcc.info, produced by Makeinfo version 1.68 from the
+input file ../../gcc-2.95.2/gcc/gcc.texi.
+
+INFO-DIR-SECTION Programming
+START-INFO-DIR-ENTRY
+* gcc: (gcc).                  The GNU Compiler Collection.
+END-INFO-DIR-ENTRY
+   This file documents the use and the internals of the GNU compiler.
+
+   Published by the Free Software Foundation 59 Temple Place - Suite 330
+Boston, MA 02111-1307 USA
+
+   Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
+1999 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 sections entitled "GNU General Public License" and "Funding
+for Free Software" are included exactly as in the original, and
+provided 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, except that the sections entitled "GNU General Public
+License" and "Funding for Free Software", and this permission notice,
+may be included in translations approved by the Free Software Foundation
+instead of in the original English.
+
+
+File: gcc.info,  Node: Insn Lengths,  Next: Constant Attributes,  Prev: Attr Example,  Up: Insn Attributes
+
+Computing the Length of an Insn
+-------------------------------
+
+   For many machines, multiple types of branch instructions are
+provided, each for different length branch displacements.  In most
+cases, the assembler will choose the correct instruction to use.
+However, when the assembler cannot do so, GCC can when a special
+attribute, the `length' attribute, is defined.  This attribute must be
+defined to have numeric values by specifying a null string in its
+`define_attr'.
+
+   In the case of the `length' attribute, two additional forms of
+arithmetic terms are allowed in test expressions:
+
+`(match_dup N)'
+     This refers to the address of operand N of the current insn, which
+     must be a `label_ref'.
+
+`(pc)'
+     This refers to the address of the *current* insn.  It might have
+     been more consistent with other usage to make this the address of
+     the *next* insn but this would be confusing because the length of
+     the current insn is to be computed.
+
+   For normal insns, the length will be determined by value of the
+`length' attribute.  In the case of `addr_vec' and `addr_diff_vec' insn
+patterns, the length is computed as the number of vectors multiplied by
+the size of each vector.
+
+   Lengths are measured in addressable storage units (bytes).
+
+   The following macros can be used to refine the length computation:
+
+`FIRST_INSN_ADDRESS'
+     When the `length' insn attribute is used, this macro specifies the
+     value to be assigned to the address of the first insn in a
+     function.  If not specified, 0 is used.
+
+`ADJUST_INSN_LENGTH (INSN, LENGTH)'
+     If defined, modifies the length assigned to instruction INSN as a
+     function of the context in which it is used.  LENGTH is an lvalue
+     that contains the initially computed length of the insn and should
+     be updated with the correct length of the insn.
+
+     This macro will normally not be required.  A case in which it is
+     required is the ROMP.  On this machine, the size of an `addr_vec'
+     insn must be increased by two to compensate for the fact that
+     alignment may be required.
+
+   The routine that returns `get_attr_length' (the value of the
+`length' attribute) can be used by the output routine to determine the
+form of the branch instruction to be written, as the example below
+illustrates.
+
+   As an example of the specification of variable-length branches,
+consider the IBM 360.  If we adopt the convention that a register will
+be set to the starting address of a function, we can jump to labels
+within 4k of the start using a four-byte instruction.  Otherwise, we
+need a six-byte sequence to load the address from memory and then
+branch to it.
+
+   On such a machine, a pattern for a branch instruction might be
+specified as follows:
+
+     (define_insn "jump"
+       [(set (pc)
+             (label_ref (match_operand 0 "" "")))]
+       ""
+       "*
+     {
+        return (get_attr_length (insn) == 4
+                ? \"b %l0\" : \"l r15,=a(%l0); br r15\");
+     }"
+       [(set (attr "length") (if_then_else (lt (match_dup 0) (const_int 4096))
+                                           (const_int 4)
+                                           (const_int 6)))])
+
+
+File: gcc.info,  Node: Constant Attributes,  Next: Delay Slots,  Prev: Insn Lengths,  Up: Insn Attributes
+
+Constant Attributes
+-------------------
+
+   A special form of `define_attr', where the expression for the
+default value is a `const' expression, indicates an attribute that is
+constant for a given run of the compiler.  Constant attributes may be
+used to specify which variety of processor is used.  For example,
+
+     (define_attr "cpu" "m88100,m88110,m88000"
+      (const
+       (cond [(symbol_ref "TARGET_88100") (const_string "m88100")
+              (symbol_ref "TARGET_88110") (const_string "m88110")]
+             (const_string "m88000"))))
+     
+     (define_attr "memory" "fast,slow"
+      (const
+       (if_then_else (symbol_ref "TARGET_FAST_MEM")
+                     (const_string "fast")
+                     (const_string "slow"))))
+
+   The routine generated for constant attributes has no parameters as it
+does not depend on any particular insn.  RTL expressions used to define
+the value of a constant attribute may use the `symbol_ref' form, but
+may not use either the `match_operand' form or `eq_attr' forms
+involving insn attributes.
+
+
+File: gcc.info,  Node: Delay Slots,  Next: Function Units,  Prev: Constant Attributes,  Up: Insn Attributes
+
+Delay Slot Scheduling
+---------------------
+
+   The insn attribute mechanism can be used to specify the requirements
+for delay slots, if any, on a target machine.  An instruction is said to
+require a "delay slot" if some instructions that are physically after
+the instruction are executed as if they were located before it.
+Classic examples are branch and call instructions, which often execute
+the following instruction before the branch or call is performed.
+
+   On some machines, conditional branch instructions can optionally
+"annul" instructions in the delay slot.  This means that the
+instruction will not be executed for certain branch outcomes.  Both
+instructions that annul if the branch is true and instructions that
+annul if the branch is false are supported.
+
+   Delay slot scheduling differs from instruction scheduling in that
+determining whether an instruction needs a delay slot is dependent only
+on the type of instruction being generated, not on data flow between the
+instructions.  See the next section for a discussion of data-dependent
+instruction scheduling.
+
+   The requirement of an insn needing one or more delay slots is
+indicated via the `define_delay' expression.  It has the following form:
+
+     (define_delay TEST
+                   [DELAY-1 ANNUL-TRUE-1 ANNUL-FALSE-1
+                    DELAY-2 ANNUL-TRUE-2 ANNUL-FALSE-2
+                    ...])
+
+   TEST is an attribute test that indicates whether this `define_delay'
+applies to a particular insn.  If so, the number of required delay
+slots is determined by the length of the vector specified as the second
+argument.  An insn placed in delay slot N must satisfy attribute test
+DELAY-N.  ANNUL-TRUE-N is an attribute test that specifies which insns
+may be annulled if the branch is true.  Similarly, ANNUL-FALSE-N
+specifies which insns in the delay slot may be annulled if the branch
+is false.  If annulling is not supported for that delay slot, `(nil)'
+should be coded.
+
+   For example, in the common case where branch and call insns require
+a single delay slot, which may contain any insn other than a branch or
+call, the following would be placed in the `md' file:
+
+     (define_delay (eq_attr "type" "branch,call")
+                   [(eq_attr "type" "!branch,call") (nil) (nil)])
+
+   Multiple `define_delay' expressions may be specified.  In this case,
+each such expression specifies different delay slot requirements and
+there must be no insn for which tests in two `define_delay' expressions
+are both true.
+
+   For example, if we have a machine that requires one delay slot for
+branches but two for calls,  no delay slot can contain a branch or call
+insn, and any valid insn in the delay slot for the branch can be
+annulled if the branch is true, we might represent this as follows:
+
+     (define_delay (eq_attr "type" "branch")
+        [(eq_attr "type" "!branch,call")
+         (eq_attr "type" "!branch,call")
+         (nil)])
+     
+     (define_delay (eq_attr "type" "call")
+                   [(eq_attr "type" "!branch,call") (nil) (nil)
+                    (eq_attr "type" "!branch,call") (nil) (nil)])
+
+
+File: gcc.info,  Node: Function Units,  Prev: Delay Slots,  Up: Insn Attributes
+
+Specifying Function Units
+-------------------------
+
+   On most RISC machines, there are instructions whose results are not
+available for a specific number of cycles.  Common cases are
+instructions that load data from memory.  On many machines, a pipeline
+stall will result if the data is referenced too soon after the load
+instruction.
+
+   In addition, many newer microprocessors have multiple function
+units, usually one for integer and one for floating point, and often
+will incur pipeline stalls when a result that is needed is not yet
+ready.
+
+   The descriptions in this section allow the specification of how much
+time must elapse between the execution of an instruction and the time
+when its result is used.  It also allows specification of when the
+execution of an instruction will delay execution of similar instructions
+due to function unit conflicts.
+
+   For the purposes of the specifications in this section, a machine is
+divided into "function units", each of which execute a specific class
+of instructions in first-in-first-out order.  Function units that
+accept one instruction each cycle and allow a result to be used in the
+succeeding instruction (usually via forwarding) need not be specified.
+Classic RISC microprocessors will normally have a single function unit,
+which we can call `memory'.  The newer "superscalar" processors will
+often have function units for floating point operations, usually at
+least a floating point adder and multiplier.
+
+   Each usage of a function units by a class of insns is specified with
+a `define_function_unit' expression, which looks like this:
+
+     (define_function_unit NAME MULTIPLICITY SIMULTANEITY
+                           TEST READY-DELAY ISSUE-DELAY
+                          [CONFLICT-LIST])
+
+   NAME is a string giving the name of the function unit.
+
+   MULTIPLICITY is an integer specifying the number of identical units
+in the processor.  If more than one unit is specified, they will be
+scheduled independently.  Only truly independent units should be
+counted; a pipelined unit should be specified as a single unit.  (The
+only common example of a machine that has multiple function units for a
+single instruction class that are truly independent and not pipelined
+are the two multiply and two increment units of the CDC 6600.)
+
+   SIMULTANEITY specifies the maximum number of insns that can be
+executing in each instance of the function unit simultaneously or zero
+if the unit is pipelined and has no limit.
+
+   All `define_function_unit' definitions referring to function unit
+NAME must have the same name and values for MULTIPLICITY and
+SIMULTANEITY.
+
+   TEST is an attribute test that selects the insns we are describing
+in this definition.  Note that an insn may use more than one function
+unit and a function unit may be specified in more than one
+`define_function_unit'.
+
+   READY-DELAY is an integer that specifies the number of cycles after
+which the result of the instruction can be used without introducing any
+stalls.
+
+   ISSUE-DELAY is an integer that specifies the number of cycles after
+the instruction matching the TEST expression begins using this unit
+until a subsequent instruction can begin.  A cost of N indicates an N-1
+cycle delay.  A subsequent instruction may also be delayed if an
+earlier instruction has a longer READY-DELAY value.  This blocking
+effect is computed using the SIMULTANEITY, READY-DELAY, ISSUE-DELAY,
+and CONFLICT-LIST terms.  For a normal non-pipelined function unit,
+SIMULTANEITY is one, the unit is taken to block for the READY-DELAY
+cycles of the executing insn, and smaller values of ISSUE-DELAY are
+ignored.
+
+   CONFLICT-LIST is an optional list giving detailed conflict costs for
+this unit.  If specified, it is a list of condition test expressions to
+be applied to insns chosen to execute in NAME following the particular
+insn matching TEST that is already executing in NAME.  For each insn in
+the list, ISSUE-DELAY specifies the conflict cost; for insns not in the
+list, the cost is zero.  If not specified, CONFLICT-LIST defaults to
+all instructions that use the function unit.
+
+   Typical uses of this vector are where a floating point function unit
+can pipeline either single- or double-precision operations, but not
+both, or where a memory unit can pipeline loads, but not stores, etc.
+
+   As an example, consider a classic RISC machine where the result of a
+load instruction is not available for two cycles (a single "delay"
+instruction is required) and where only one load instruction can be
+executed simultaneously.  This would be specified as:
+
+     (define_function_unit "memory" 1 1 (eq_attr "type" "load") 2 0)
+
+   For the case of a floating point function unit that can pipeline
+either single or double precision, but not both, the following could be
+specified:
+
+     (define_function_unit
+        "fp" 1 0 (eq_attr "type" "sp_fp") 4 4 [(eq_attr "type" "dp_fp")])
+     (define_function_unit
+        "fp" 1 0 (eq_attr "type" "dp_fp") 4 4 [(eq_attr "type" "sp_fp")])
+
+   *Note:* The scheduler attempts to avoid function unit conflicts and
+uses all the specifications in the `define_function_unit' expression.
+It has recently come to our attention that these specifications may not
+allow modeling of some of the newer "superscalar" processors that have
+insns using multiple pipelined units.  These insns will cause a
+potential conflict for the second unit used during their execution and
+there is no way of representing that conflict.  We welcome any examples
+of how function unit conflicts work in such processors and suggestions
+for their representation.
+
+
+File: gcc.info,  Node: Target Macros,  Next: Config,  Prev: Machine Desc,  Up: Top
+
+Target Description Macros
+*************************
+
+   In addition to the file `MACHINE.md', a machine description includes
+a C header file conventionally given the name `MACHINE.h'.  This header
+file defines numerous macros that convey the information about the
+target machine that does not fit into the scheme of the `.md' file.
+The file `tm.h' should be a link to `MACHINE.h'.  The header file
+`config.h' includes `tm.h' and most compiler source files include
+`config.h'.
+
+* Menu:
+
+* Driver::              Controlling how the driver runs the compilation passes.
+* Run-time Target::     Defining `-m' options like `-m68000' and `-m68020'.
+* Storage Layout::      Defining sizes and alignments of data.
+* Type Layout::         Defining sizes and properties of basic user data types.
+* Registers::           Naming and describing the hardware registers.
+* Register Classes::    Defining the classes of hardware registers.
+* Stack and Calling::   Defining which way the stack grows and by how much.
+* Varargs::		Defining the varargs macros.
+* Trampolines::         Code set up at run time to enter a nested function.
+* Library Calls::       Controlling how library routines are implicitly called.
+* Addressing Modes::    Defining addressing modes valid for memory operands.
+* Condition Code::      Defining how insns update the condition code.
+* Costs::               Defining relative costs of different operations.
+* Sections::            Dividing storage into text, data, and other sections.
+* PIC::			Macros for position independent code.
+* Assembler Format::    Defining how to write insns and pseudo-ops to output.
+* Debugging Info::      Defining the format of debugging output.
+* Cross-compilation::   Handling floating point for cross-compilers.
+* Misc::                Everything else.
+
+
+File: gcc.info,  Node: Driver,  Next: Run-time Target,  Up: Target Macros
+
+Controlling the Compilation Driver, `gcc'
+=========================================
+
+   You can control the compilation driver.
+
+`SWITCH_TAKES_ARG (CHAR)'
+     A C expression which determines whether the option `-CHAR' takes
+     arguments.  The value should be the number of arguments that
+     option takes-zero, for many options.
+
+     By default, this macro is defined as `DEFAULT_SWITCH_TAKES_ARG',
+     which handles the standard options properly.  You need not define
+     `SWITCH_TAKES_ARG' unless you wish to add additional options which
+     take arguments.  Any redefinition should call
+     `DEFAULT_SWITCH_TAKES_ARG' and then check for additional options.
+
+`WORD_SWITCH_TAKES_ARG (NAME)'
+     A C expression which determines whether the option `-NAME' takes
+     arguments.  The value should be the number of arguments that
+     option takes-zero, for many options.  This macro rather than
+     `SWITCH_TAKES_ARG' is used for multi-character option names.
+
+     By default, this macro is defined as
+     `DEFAULT_WORD_SWITCH_TAKES_ARG', which handles the standard options
+     properly.  You need not define `WORD_SWITCH_TAKES_ARG' unless you
+     wish to add additional options which take arguments.  Any
+     redefinition should call `DEFAULT_WORD_SWITCH_TAKES_ARG' and then
+     check for additional options.
+
+`SWITCH_CURTAILS_COMPILATION (CHAR)'
+     A C expression which determines whether the option `-CHAR' stops
+     compilation before the generation of an executable.  The value is
+     boolean, non-zero if the option does stop an executable from being
+     generated, zero otherwise.
+
+     By default, this macro is defined as
+     `DEFAULT_SWITCH_CURTAILS_COMPILATION', which handles the standard
+     options properly.  You need not define
+     `SWITCH_CURTAILS_COMPILATION' unless you wish to add additional
+     options which affect the generation of an executable.  Any
+     redefinition should call `DEFAULT_SWITCH_CURTAILS_COMPILATION' and
+     then check for additional options.
+
+`SWITCHES_NEED_SPACES'
+     A string-valued C expression which enumerates the options for which
+     the linker needs a space between the option and its argument.
+
+     If this macro is not defined, the default value is `""'.
+
+`CPP_SPEC'
+     A C string constant that tells the GNU CC driver program options to
+     pass to CPP.  It can also specify how to translate options you
+     give to GNU CC into options for GNU CC to pass to the CPP.
+
+     Do not define this macro if it does not need to do anything.
+
+`NO_BUILTIN_SIZE_TYPE'
+     If this macro is defined, the preprocessor will not define the
+     builtin macro `__SIZE_TYPE__'.  The macro `__SIZE_TYPE__' must
+     then be defined by `CPP_SPEC' instead.
+
+     This should be defined if `SIZE_TYPE' depends on target dependent
+     flags which are not accessible to the preprocessor.  Otherwise, it
+     should not be defined.
+
+`NO_BUILTIN_PTRDIFF_TYPE'
+     If this macro is defined, the preprocessor will not define the
+     builtin macro `__PTRDIFF_TYPE__'.  The macro `__PTRDIFF_TYPE__'
+     must then be defined by `CPP_SPEC' instead.
+
+     This should be defined if `PTRDIFF_TYPE' depends on target
+     dependent flags which are not accessible to the preprocessor.
+     Otherwise, it should not be defined.
+
+`SIGNED_CHAR_SPEC'
+     A C string constant that tells the GNU CC driver program options to
+     pass to CPP.  By default, this macro is defined to pass the option
+     `-D__CHAR_UNSIGNED__' to CPP if `char' will be treated as
+     `unsigned char' by `cc1'.
+
+     Do not define this macro unless you need to override the default
+     definition.
+
+`CC1_SPEC'
+     A C string constant that tells the GNU CC driver program options to
+     pass to `cc1'.  It can also specify how to translate options you
+     give to GNU CC into options for GNU CC to pass to the `cc1'.
+
+     Do not define this macro if it does not need to do anything.
+
+`CC1PLUS_SPEC'
+     A C string constant that tells the GNU CC driver program options to
+     pass to `cc1plus'.  It can also specify how to translate options
+     you give to GNU CC into options for GNU CC to pass to the
+     `cc1plus'.
+
+     Do not define this macro if it does not need to do anything.
+
+`ASM_SPEC'
+     A C string constant that tells the GNU CC driver program options to
+     pass to the assembler.  It can also specify how to translate
+     options you give to GNU CC into options for GNU CC to pass to the
+     assembler.  See the file `sun3.h' for an example of this.
+
+     Do not define this macro if it does not need to do anything.
+
+`ASM_FINAL_SPEC'
+     A C string constant that tells the GNU CC driver program how to
+     run any programs which cleanup after the normal assembler.
+     Normally, this is not needed.  See the file `mips.h' for an
+     example of this.
+
+     Do not define this macro if it does not need to do anything.
+
+`LINK_SPEC'
+     A C string constant that tells the GNU CC driver program options to
+     pass to the linker.  It can also specify how to translate options
+     you give to GNU CC into options for GNU CC to pass to the linker.
+
+     Do not define this macro if it does not need to do anything.
+
+`LIB_SPEC'
+     Another C string constant used much like `LINK_SPEC'.  The
+     difference between the two is that `LIB_SPEC' is used at the end
+     of the command given to the linker.
+
+     If this macro is not defined, a default is provided that loads the
+     standard C library from the usual place.  See `gcc.c'.
+
+`LIBGCC_SPEC'
+     Another C string constant that tells the GNU CC driver program how
+     and when to place a reference to `libgcc.a' into the linker
+     command line.  This constant is placed both before and after the
+     value of `LIB_SPEC'.
+
+     If this macro is not defined, the GNU CC driver provides a default
+     that passes the string `-lgcc' to the linker unless the `-shared'
+     option is specified.
+
+`STARTFILE_SPEC'
+     Another C string constant used much like `LINK_SPEC'.  The
+     difference between the two is that `STARTFILE_SPEC' is used at the
+     very beginning of the command given to the linker.
+
+     If this macro is not defined, a default is provided that loads the
+     standard C startup file from the usual place.  See `gcc.c'.
+
+`ENDFILE_SPEC'
+     Another C string constant used much like `LINK_SPEC'.  The
+     difference between the two is that `ENDFILE_SPEC' is used at the
+     very end of the command given to the linker.
+
+     Do not define this macro if it does not need to do anything.
+
+`EXTRA_SPECS'
+     Define this macro to provide additional specifications to put in
+     the `specs' file that can be used in various specifications like
+     `CC1_SPEC'.
+
+     The definition should be an initializer for an array of structures,
+     containing a string constant, that defines the specification name,
+     and a string constant that provides the specification.
+
+     Do not define this macro if it does not need to do anything.
+
+     `EXTRA_SPECS' is useful when an architecture contains several
+     related targets, which have various `..._SPECS' which are similar
+     to each other, and the maintainer would like one central place to
+     keep these definitions.
+
+     For example, the PowerPC System V.4 targets use `EXTRA_SPECS' to
+     define either `_CALL_SYSV' when the System V calling sequence is
+     used or `_CALL_AIX' when the older AIX-based calling sequence is
+     used.
+
+     The `config/rs6000/rs6000.h' target file defines:
+
+          #define EXTRA_SPECS \
+            { "cpp_sysv_default", CPP_SYSV_DEFAULT },
+          
+          #define CPP_SYS_DEFAULT ""
+
+     The `config/rs6000/sysv.h' target file defines:
+          #undef CPP_SPEC
+          #define CPP_SPEC \
+          "%{posix: -D_POSIX_SOURCE } \
+          %{mcall-sysv: -D_CALL_SYSV } %{mcall-aix: -D_CALL_AIX } \
+          %{!mcall-sysv: %{!mcall-aix: %(cpp_sysv_default) }} \
+          %{msoft-float: -D_SOFT_FLOAT} %{mcpu=403: -D_SOFT_FLOAT}"
+          
+          #undef CPP_SYSV_DEFAULT
+          #define CPP_SYSV_DEFAULT "-D_CALL_SYSV"
+
+     while the `config/rs6000/eabiaix.h' target file defines
+     `CPP_SYSV_DEFAULT' as:
+
+          #undef CPP_SYSV_DEFAULT
+          #define CPP_SYSV_DEFAULT "-D_CALL_AIX"
+
+`LINK_LIBGCC_SPECIAL'
+     Define this macro if the driver program should find the library
+     `libgcc.a' itself and should not pass `-L' options to the linker.
+     If you do not define this macro, the driver program will pass the
+     argument `-lgcc' to tell the linker to do the search and will pass
+     `-L' options to it.
+
+`LINK_LIBGCC_SPECIAL_1'
+     Define this macro if the driver program should find the library
+     `libgcc.a'.  If you do not define this macro, the driver program
+     will pass the argument `-lgcc' to tell the linker to do the search.
+     This macro is similar to `LINK_LIBGCC_SPECIAL', except that it does
+     not affect `-L' options.
+
+`LINK_COMMAND_SPEC'
+     A C string constant giving the complete command line need to
+     execute the linker.  When you do this, you will need to update
+     your port each time a change is made to the link command line
+     within `gcc.c'.  Therefore, define this macro only if you need to
+     completely redefine the command line for invoking the linker and
+     there is no other way to accomplish the effect you need.
+
+`MULTILIB_DEFAULTS'
+     Define this macro as a C expression for the initializer of an
+     array of string to tell the driver program which options are
+     defaults for this target and thus do not need to be handled
+     specially when using `MULTILIB_OPTIONS'.
+
+     Do not define this macro if `MULTILIB_OPTIONS' is not defined in
+     the target makefile fragment or if none of the options listed in
+     `MULTILIB_OPTIONS' are set by default.  *Note Target Fragment::.
+
+`RELATIVE_PREFIX_NOT_LINKDIR'
+     Define this macro to tell `gcc' that it should only translate a
+     `-B' prefix into a `-L' linker option if the prefix indicates an
+     absolute file name.
+
+`STANDARD_EXEC_PREFIX'
+     Define this macro as a C string constant if you wish to override
+     the standard choice of `/usr/local/lib/gcc-lib/' as the default
+     prefix to try when searching for the executable files of the
+     compiler.
+
+`MD_EXEC_PREFIX'
+     If defined, this macro is an additional prefix to try after
+     `STANDARD_EXEC_PREFIX'.  `MD_EXEC_PREFIX' is not searched when the
+     `-b' option is used, or the compiler is built as a cross compiler.
+     If you define `MD_EXEC_PREFIX', then be sure to add it to the
+     list of directories used to find the assembler in `configure.in'.
+
+`STANDARD_STARTFILE_PREFIX'
+     Define this macro as a C string constant if you wish to override
+     the standard choice of `/usr/local/lib/' as the default prefix to
+     try when searching for startup files such as `crt0.o'.
+
+`MD_STARTFILE_PREFIX'
+     If defined, this macro supplies an additional prefix to try after
+     the standard prefixes.  `MD_EXEC_PREFIX' is not searched when the
+     `-b' option is used, or when the compiler is built as a cross
+     compiler.
+
+`MD_STARTFILE_PREFIX_1'
+     If defined, this macro supplies yet another prefix to try after the
+     standard prefixes.  It is not searched when the `-b' option is
+     used, or when the compiler is built as a cross compiler.
+
+`INIT_ENVIRONMENT'
+     Define this macro as a C string constant if you wish to set
+     environment variables for programs called by the driver, such as
+     the assembler and loader.  The driver passes the value of this
+     macro to `putenv' to initialize the necessary environment
+     variables.
+
+`LOCAL_INCLUDE_DIR'
+     Define this macro as a C string constant if you wish to override
+     the standard choice of `/usr/local/include' as the default prefix
+     to try when searching for local header files.  `LOCAL_INCLUDE_DIR'
+     comes before `SYSTEM_INCLUDE_DIR' in the search order.
+
+     Cross compilers do not use this macro and do not search either
+     `/usr/local/include' or its replacement.
+
+`SYSTEM_INCLUDE_DIR'
+     Define this macro as a C string constant if you wish to specify a
+     system-specific directory to search for header files before the
+     standard directory.  `SYSTEM_INCLUDE_DIR' comes before
+     `STANDARD_INCLUDE_DIR' in the search order.
+
+     Cross compilers do not use this macro and do not search the
+     directory specified.
+
+`STANDARD_INCLUDE_DIR'
+     Define this macro as a C string constant if you wish to override
+     the standard choice of `/usr/include' as the default prefix to try
+     when searching for header files.
+
+     Cross compilers do not use this macro and do not search either
+     `/usr/include' or its replacement.
+
+`STANDARD_INCLUDE_COMPONENT'
+     The "component" corresponding to `STANDARD_INCLUDE_DIR'.  See
+     `INCLUDE_DEFAULTS', below, for the description of components.  If
+     you do not define this macro, no component is used.
+
+`INCLUDE_DEFAULTS'
+     Define this macro if you wish to override the entire default
+     search path for include files.  For a native compiler, the default
+     search path usually consists of `GCC_INCLUDE_DIR',
+     `LOCAL_INCLUDE_DIR', `SYSTEM_INCLUDE_DIR',
+     `GPLUSPLUS_INCLUDE_DIR', and `STANDARD_INCLUDE_DIR'.  In addition,
+     `GPLUSPLUS_INCLUDE_DIR' and `GCC_INCLUDE_DIR' are defined
+     automatically by `Makefile', and specify private search areas for
+     GCC.  The directory `GPLUSPLUS_INCLUDE_DIR' is used only for C++
+     programs.
+
+     The definition should be an initializer for an array of structures.
+     Each array element should have four elements: the directory name (a
+     string constant), the component name, and flag for C++-only
+     directories, and a flag showing that the includes in the directory
+     don't need to be wrapped in `extern `C'' when compiling C++.  Mark
+     the end of the array with a null element.
+
+     The component name denotes what GNU package the include file is
+     part of, if any, in all upper-case letters.  For example, it might
+     be `GCC' or `BINUTILS'.  If the package is part of the a
+     vendor-supplied operating system, code the component name as `0'.
+
+     For example, here is the definition used for VAX/VMS:
+
+          #define INCLUDE_DEFAULTS \
+          {                                       \
+            { "GNU_GXX_INCLUDE:", "G++", 1, 1},   \
+            { "GNU_CC_INCLUDE:", "GCC", 0, 0},    \
+            { "SYS$SYSROOT:[SYSLIB.]", 0, 0, 0},  \
+            { ".", 0, 0, 0},                      \
+            { 0, 0, 0, 0}                         \
+          }
+
+   Here is the order of prefixes tried for exec files:
+
+  1. Any prefixes specified by the user with `-B'.
+
+  2. The environment variable `GCC_EXEC_PREFIX', if any.
+
+  3. The directories specified by the environment variable
+     `COMPILER_PATH'.
+
+  4. The macro `STANDARD_EXEC_PREFIX'.
+
+  5. `/usr/lib/gcc/'.
+
+  6. The macro `MD_EXEC_PREFIX', if any.
+
+   Here is the order of prefixes tried for startfiles:
+
+  1. Any prefixes specified by the user with `-B'.
+
+  2. The environment variable `GCC_EXEC_PREFIX', if any.
+
+  3. The directories specified by the environment variable
+     `LIBRARY_PATH' (native only, cross compilers do not use this).
+
+  4. The macro `STANDARD_EXEC_PREFIX'.
+
+  5. `/usr/lib/gcc/'.
+
+  6. The macro `MD_EXEC_PREFIX', if any.
+
+  7. The macro `MD_STARTFILE_PREFIX', if any.
+
+  8. The macro `STANDARD_STARTFILE_PREFIX'.
+
+  9. `/lib/'.
+
+ 10. `/usr/lib/'.
+
+
+File: gcc.info,  Node: Run-time Target,  Next: Storage Layout,  Prev: Driver,  Up: Target Macros
+
+Run-time Target Specification
+=============================
+
+   Here are run-time target specifications.
+
+`CPP_PREDEFINES'
+     Define this to be a string constant containing `-D' options to
+     define the predefined macros that identify this machine and system.
+     These macros will be predefined unless the `-ansi' option is
+     specified.
+
+     In addition, a parallel set of macros are predefined, whose names
+     are made by appending `__' at the beginning and at the end.  These
+     `__' macros are permitted by the ANSI standard, so they are
+     predefined regardless of whether `-ansi' is specified.
+
+     For example, on the Sun, one can use the following value:
+
+          "-Dmc68000 -Dsun -Dunix"
+
+     The result is to define the macros `__mc68000__', `__sun__' and
+     `__unix__' unconditionally, and the macros `mc68000', `sun' and
+     `unix' provided `-ansi' is not specified.
+
+`extern int target_flags;'
+     This declaration should be present.
+
+`TARGET_...'
+     This series of macros is to allow compiler command arguments to
+     enable or disable the use of optional features of the target
+     machine.  For example, one machine description serves both the
+     68000 and the 68020; a command argument tells the compiler whether
+     it should use 68020-only instructions or not.  This command
+     argument works by means of a macro `TARGET_68020' that tests a bit
+     in `target_flags'.
+
+     Define a macro `TARGET_FEATURENAME' for each such option.  Its
+     definition should test a bit in `target_flags'; for example:
+
+          #define TARGET_68020 (target_flags & 1)
+
+     One place where these macros are used is in the
+     condition-expressions of instruction patterns.  Note how
+     `TARGET_68020' appears frequently in the 68000 machine description
+     file, `m68k.md'.  Another place they are used is in the
+     definitions of the other macros in the `MACHINE.h' file.
+
+`TARGET_SWITCHES'
+     This macro defines names of command options to set and clear bits
+     in `target_flags'.  Its definition is an initializer with a
+     subgrouping for each command option.
+
+     Each subgrouping contains a string constant, that defines the
+     option name, a number, which contains the bits to set in
+     `target_flags', and a second string which is the description
+     displayed by -help.  If the number is negative then the bits
+     specified by the number are cleared instead of being set.  If the
+     description string is present but empty, then no help information
+     will be displayed for that option, but it will not count as an
+     undocumented option.  The actual option name is made by appending
+     `-m' to the specified name.
+
+     One of the subgroupings should have a null string.  The number in
+     this grouping is the default value for `target_flags'.  Any target
+     options act starting with that value.
+
+     Here is an example which defines `-m68000' and `-m68020' with
+     opposite meanings, and picks the latter as the default:
+
+          #define TARGET_SWITCHES \
+            { { "68020", 1, "" },      \
+              { "68000", -1, "Compile for the 68000" }, \
+              { "", 1, "" }}
+
+`TARGET_OPTIONS'
+     This macro is similar to `TARGET_SWITCHES' but defines names of
+     command options that have values.  Its definition is an
+     initializer with a subgrouping for each command option.
+
+     Each subgrouping contains a string constant, that defines the
+     fixed part of the option name, the address of a variable, and a
+     description string.  The variable, type `char *', is set to the
+     variable part of the given option if the fixed part matches.  The
+     actual option name is made by appending `-m' to the specified name.
+
+     Here is an example which defines `-mshort-data-NUMBER'.  If the
+     given option is `-mshort-data-512', the variable `m88k_short_data'
+     will be set to the string `"512"'.
+
+          extern char *m88k_short_data;
+          #define TARGET_OPTIONS \
+           { { "short-data-", &m88k_short_data, "Specify the size of the short data section" } }
+
+`TARGET_VERSION'
+     This macro is a C statement to print on `stderr' a string
+     describing the particular machine description choice.  Every
+     machine description should define `TARGET_VERSION'.  For example:
+
+          #ifdef MOTOROLA
+          #define TARGET_VERSION \
+            fprintf (stderr, " (68k, Motorola syntax)");
+          #else
+          #define TARGET_VERSION \
+            fprintf (stderr, " (68k, MIT syntax)");
+          #endif
+
+`OVERRIDE_OPTIONS'
+     Sometimes certain combinations of command options do not make
+     sense on a particular target machine.  You can define a macro
+     `OVERRIDE_OPTIONS' to take account of this.  This macro, if
+     defined, is executed once just after all the command options have
+     been parsed.
+
+     Don't use this macro to turn on various extra optimizations for
+     `-O'.  That is what `OPTIMIZATION_OPTIONS' is for.
+
+`OPTIMIZATION_OPTIONS (LEVEL, SIZE)'
+     Some machines may desire to change what optimizations are
+     performed for various optimization levels.   This macro, if
+     defined, is executed once just after the optimization level is
+     determined and before the remainder of the command options have
+     been parsed.  Values set in this macro are used as the default
+     values for the other command line options.
+
+     LEVEL is the optimization level specified; 2 if `-O2' is
+     specified, 1 if `-O' is specified, and 0 if neither is specified.
+
+     SIZE is non-zero if `-Os' is specified and zero otherwise.
+
+     You should not use this macro to change options that are not
+     machine-specific.  These should uniformly selected by the same
+     optimization level on all supported machines.  Use this macro to
+     enable machine-specific optimizations.
+
+     *Do not examine `write_symbols' in this macro!* The debugging
+     options are not supposed to alter the generated code.
+
+`CAN_DEBUG_WITHOUT_FP'
+     Define this macro if debugging can be performed even without a
+     frame pointer.  If this macro is defined, GNU CC will turn on the
+     `-fomit-frame-pointer' option whenever `-O' is specified.
+

usr/local/nachos/info/gcc.info-23

@@ -0,0 +1,989 @@
+This is Info file gcc.info, produced by Makeinfo version 1.68 from the
+input file ../../gcc-2.95.2/gcc/gcc.texi.
+
+INFO-DIR-SECTION Programming
+START-INFO-DIR-ENTRY
+* gcc: (gcc).                  The GNU Compiler Collection.
+END-INFO-DIR-ENTRY
+   This file documents the use and the internals of the GNU compiler.
+
+   Published by the Free Software Foundation 59 Temple Place - Suite 330
+Boston, MA 02111-1307 USA
+
+   Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
+1999 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 sections entitled "GNU General Public License" and "Funding
+for Free Software" are included exactly as in the original, and
+provided 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, except that the sections entitled "GNU General Public
+License" and "Funding for Free Software", and this permission notice,
+may be included in translations approved by the Free Software Foundation
+instead of in the original English.
+
+
+File: gcc.info,  Node: Register Classes,  Next: Stack and Calling,  Prev: Registers,  Up: Target Macros
+
+Register Classes
+================
+
+   On many machines, the numbered registers are not all equivalent.
+For example, certain registers may not be allowed for indexed
+addressing; certain registers may not be allowed in some instructions.
+These machine restrictions are described to the compiler using
+"register classes".
+
+   You define a number of register classes, giving each one a name and
+saying which of the registers belong to it.  Then you can specify
+register classes that are allowed as operands to particular instruction
+patterns.
+
+   In general, each register will belong to several classes.  In fact,
+one class must be named `ALL_REGS' and contain all the registers.
+Another class must be named `NO_REGS' and contain no registers.  Often
+the union of two classes will be another class; however, this is not
+required.
+
+   One of the classes must be named `GENERAL_REGS'.  There is nothing
+terribly special about the name, but the operand constraint letters `r'
+and `g' specify this class.  If `GENERAL_REGS' is the same as
+`ALL_REGS', just define it as a macro which expands to `ALL_REGS'.
+
+   Order the classes so that if class X is contained in class Y then X
+has a lower class number than Y.
+
+   The way classes other than `GENERAL_REGS' are specified in operand
+constraints is through machine-dependent operand constraint letters.
+You can define such letters to correspond to various classes, then use
+them in operand constraints.
+
+   You should define a class for the union of two classes whenever some
+instruction allows both classes.  For example, if an instruction allows
+either a floating point (coprocessor) register or a general register
+for a certain operand, you should define a class `FLOAT_OR_GENERAL_REGS'
+which includes both of them.  Otherwise you will get suboptimal code.
+
+   You must also specify certain redundant information about the
+register classes: for each class, which classes contain it and which
+ones are contained in it; for each pair of classes, the largest class
+contained in their union.
+
+   When a value occupying several consecutive registers is expected in a
+certain class, all the registers used must belong to that class.
+Therefore, register classes cannot be used to enforce a requirement for
+a register pair to start with an even-numbered register.  The way to
+specify this requirement is with `HARD_REGNO_MODE_OK'.
+
+   Register classes used for input-operands of bitwise-and or shift
+instructions have a special requirement: each such class must have, for
+each fixed-point machine mode, a subclass whose registers can transfer
+that mode to or from memory.  For example, on some machines, the
+operations for single-byte values (`QImode') are limited to certain
+registers.  When this is so, each register class that is used in a
+bitwise-and or shift instruction must have a subclass consisting of
+registers from which single-byte values can be loaded or stored.  This
+is so that `PREFERRED_RELOAD_CLASS' can always have a possible value to
+return.
+
+`enum reg_class'
+     An enumeral type that must be defined with all the register class
+     names as enumeral values.  `NO_REGS' must be first.  `ALL_REGS'
+     must be the last register class, followed by one more enumeral
+     value, `LIM_REG_CLASSES', which is not a register class but rather
+     tells how many classes there are.
+
+     Each register class has a number, which is the value of casting
+     the class name to type `int'.  The number serves as an index in
+     many of the tables described below.
+
+`N_REG_CLASSES'
+     The number of distinct register classes, defined as follows:
+
+          #define N_REG_CLASSES (int) LIM_REG_CLASSES
+
+`REG_CLASS_NAMES'
+     An initializer containing the names of the register classes as C
+     string constants.  These names are used in writing some of the
+     debugging dumps.
+
+`REG_CLASS_CONTENTS'
+     An initializer containing the contents of the register classes, as
+     integers which are bit masks.  The Nth integer specifies the
+     contents of class N.  The way the integer MASK is interpreted is
+     that register R is in the class if `MASK & (1 << R)' is 1.
+
+     When the machine has more than 32 registers, an integer does not
+     suffice.  Then the integers are replaced by sub-initializers,
+     braced groupings containing several integers.  Each
+     sub-initializer must be suitable as an initializer for the type
+     `HARD_REG_SET' which is defined in `hard-reg-set.h'.
+
+`REGNO_REG_CLASS (REGNO)'
+     A C expression whose value is a register class containing hard
+     register REGNO.  In general there is more than one such class;
+     choose a class which is "minimal", meaning that no smaller class
+     also contains the register.
+
+`BASE_REG_CLASS'
+     A macro whose definition is the name of the class to which a valid
+     base register must belong.  A base register is one used in an
+     address which is the register value plus a displacement.
+
+`INDEX_REG_CLASS'
+     A macro whose definition is the name of the class to which a valid
+     index register must belong.  An index register is one used in an
+     address where its value is either multiplied by a scale factor or
+     added to another register (as well as added to a displacement).
+
+`REG_CLASS_FROM_LETTER (CHAR)'
+     A C expression which defines the machine-dependent operand
+     constraint letters for register classes.  If CHAR is such a
+     letter, the value should be the register class corresponding to
+     it.  Otherwise, the value should be `NO_REGS'.  The register
+     letter `r', corresponding to class `GENERAL_REGS', will not be
+     passed to this macro; you do not need to handle it.
+
+`REGNO_OK_FOR_BASE_P (NUM)'
+     A C expression which is nonzero if register number NUM is suitable
+     for use as a base register in operand addresses.  It may be either
+     a suitable hard register or a pseudo register that has been
+     allocated such a hard register.
+
+`REGNO_MODE_OK_FOR_BASE_P (NUM, MODE)'
+     A C expression that is just like `REGNO_OK_FOR_BASE_P', except that
+     that expression may examine the mode of the memory reference in
+     MODE.  You should define this macro if the mode of the memory
+     reference affects whether a register may be used as a base
+     register.  If you define this macro, the compiler will use it
+     instead of `REGNO_OK_FOR_BASE_P'.
+
+`REGNO_OK_FOR_INDEX_P (NUM)'
+     A C expression which is nonzero if register number NUM is suitable
+     for use as an index register in operand addresses.  It may be
+     either a suitable hard register or a pseudo register that has been
+     allocated such a hard register.
+
+     The difference between an index register and a base register is
+     that the index register may be scaled.  If an address involves the
+     sum of two registers, neither one of them scaled, then either one
+     may be labeled the "base" and the other the "index"; but whichever
+     labeling is used must fit the machine's constraints of which
+     registers may serve in each capacity.  The compiler will try both
+     labelings, looking for one that is valid, and will reload one or
+     both registers only if neither labeling works.
+
+`PREFERRED_RELOAD_CLASS (X, CLASS)'
+     A C expression that places additional restrictions on the register
+     class to use when it is necessary to copy value X into a register
+     in class CLASS.  The value is a register class; perhaps CLASS, or
+     perhaps another, smaller class.  On many machines, the following
+     definition is safe:
+
+          #define PREFERRED_RELOAD_CLASS(X,CLASS) CLASS
+
+     Sometimes returning a more restrictive class makes better code.
+     For example, on the 68000, when X is an integer constant that is
+     in range for a `moveq' instruction, the value of this macro is
+     always `DATA_REGS' as long as CLASS includes the data registers.
+     Requiring a data register guarantees that a `moveq' will be used.
+
+     If X is a `const_double', by returning `NO_REGS' you can force X
+     into a memory constant.  This is useful on certain machines where
+     immediate floating values cannot be loaded into certain kinds of
+     registers.
+
+`PREFERRED_OUTPUT_RELOAD_CLASS (X, CLASS)'
+     Like `PREFERRED_RELOAD_CLASS', but for output reloads instead of
+     input reloads.  If you don't define this macro, the default is to
+     use CLASS, unchanged.
+
+`LIMIT_RELOAD_CLASS (MODE, CLASS)'
+     A C expression that places additional restrictions on the register
+     class to use when it is necessary to be able to hold a value of
+     mode MODE in a reload register for which class CLASS would
+     ordinarily be used.
+
+     Unlike `PREFERRED_RELOAD_CLASS', this macro should be used when
+     there are certain modes that simply can't go in certain reload
+     classes.
+
+     The value is a register class; perhaps CLASS, or perhaps another,
+     smaller class.
+
+     Don't define this macro unless the target machine has limitations
+     which require the macro to do something nontrivial.
+
+`SECONDARY_RELOAD_CLASS (CLASS, MODE, X)'
+`SECONDARY_INPUT_RELOAD_CLASS (CLASS, MODE, X)'
+`SECONDARY_OUTPUT_RELOAD_CLASS (CLASS, MODE, X)'
+     Many machines have some registers that cannot be copied directly
+     to or from memory or even from other types of registers.  An
+     example is the `MQ' register, which on most machines, can only be
+     copied to or from general registers, but not memory.  Some
+     machines allow copying all registers to and from memory, but
+     require a scratch register for stores to some memory locations
+     (e.g., those with symbolic address on the RT, and those with
+     certain symbolic address on the Sparc when compiling PIC).  In
+     some cases, both an intermediate and a scratch register are
+     required.
+
+     You should define these macros to indicate to the reload phase
+     that it may need to allocate at least one register for a reload in
+     addition to the register to contain the data.  Specifically, if
+     copying X to a register CLASS in MODE requires an intermediate
+     register, you should define `SECONDARY_INPUT_RELOAD_CLASS' to
+     return the largest register class all of whose registers can be
+     used as intermediate registers or scratch registers.
+
+     If copying a register CLASS in MODE to X requires an intermediate
+     or scratch register, `SECONDARY_OUTPUT_RELOAD_CLASS' should be
+     defined to return the largest register class required.  If the
+     requirements for input and output reloads are the same, the macro
+     `SECONDARY_RELOAD_CLASS' should be used instead of defining both
+     macros identically.
+
+     The values returned by these macros are often `GENERAL_REGS'.
+     Return `NO_REGS' if no spare register is needed; i.e., if X can be
+     directly copied to or from a register of CLASS in MODE without
+     requiring a scratch register.  Do not define this macro if it
+     would always return `NO_REGS'.
+
+     If a scratch register is required (either with or without an
+     intermediate register), you should define patterns for
+     `reload_inM' or `reload_outM', as required (*note Standard
+     Names::..  These patterns, which will normally be implemented with
+     a `define_expand', should be similar to the `movM' patterns,
+     except that operand 2 is the scratch register.
+
+     Define constraints for the reload register and scratch register
+     that contain a single register class.  If the original reload
+     register (whose class is CLASS) can meet the constraint given in
+     the pattern, the value returned by these macros is used for the
+     class of the scratch register.  Otherwise, two additional reload
+     registers are required.  Their classes are obtained from the
+     constraints in the insn pattern.
+
+     X might be a pseudo-register or a `subreg' of a pseudo-register,
+     which could either be in a hard register or in memory.  Use
+     `true_regnum' to find out; it will return -1 if the pseudo is in
+     memory and the hard register number if it is in a register.
+
+     These macros should not be used in the case where a particular
+     class of registers can only be copied to memory and not to another
+     class of registers.  In that case, secondary reload registers are
+     not needed and would not be helpful.  Instead, a stack location
+     must be used to perform the copy and the `movM' pattern should use
+     memory as a intermediate storage.  This case often occurs between
+     floating-point and general registers.
+
+`SECONDARY_MEMORY_NEEDED (CLASS1, CLASS2, M)'
+     Certain machines have the property that some registers cannot be
+     copied to some other registers without using memory.  Define this
+     macro on those machines to be a C expression that is non-zero if
+     objects of mode M in registers of CLASS1 can only be copied to
+     registers of class CLASS2 by storing a register of CLASS1 into
+     memory and loading that memory location into a register of CLASS2.
+
+     Do not define this macro if its value would always be zero.
+
+`SECONDARY_MEMORY_NEEDED_RTX (MODE)'
+     Normally when `SECONDARY_MEMORY_NEEDED' is defined, the compiler
+     allocates a stack slot for a memory location needed for register
+     copies.  If this macro is defined, the compiler instead uses the
+     memory location defined by this macro.
+
+     Do not define this macro if you do not define
+     `SECONDARY_MEMORY_NEEDED'.
+
+`SECONDARY_MEMORY_NEEDED_MODE (MODE)'
+     When the compiler needs a secondary memory location to copy
+     between two registers of mode MODE, it normally allocates
+     sufficient memory to hold a quantity of `BITS_PER_WORD' bits and
+     performs the store and load operations in a mode that many bits
+     wide and whose class is the same as that of MODE.
+
+     This is right thing to do on most machines because it ensures that
+     all bits of the register are copied and prevents accesses to the
+     registers in a narrower mode, which some machines prohibit for
+     floating-point registers.
+
+     However, this default behavior is not correct on some machines,
+     such as the DEC Alpha, that store short integers in floating-point
+     registers differently than in integer registers.  On those
+     machines, the default widening will not work correctly and you
+     must define this macro to suppress that widening in some cases.
+     See the file `alpha.h' for details.
+
+     Do not define this macro if you do not define
+     `SECONDARY_MEMORY_NEEDED' or if widening MODE to a mode that is
+     `BITS_PER_WORD' bits wide is correct for your machine.
+
+`SMALL_REGISTER_CLASSES'
+     On some machines, it is risky to let hard registers live across
+     arbitrary insns.  Typically, these machines have instructions that
+     require values to be in specific registers (like an accumulator),
+     and reload will fail if the required hard register is used for
+     another purpose across such an insn.
+
+     Define `SMALL_REGISTER_CLASSES' to be an expression with a non-zero
+     value on these machines.  When this macro has a non-zero value, the
+     compiler will try to minimize the lifetime of hard registers.
+
+     It is always safe to define this macro with a non-zero value, but
+     if you unnecessarily define it, you will reduce the amount of
+     optimizations that can be performed in some cases.  If you do not
+     define this macro with a non-zero value when it is required, the
+     compiler will run out of spill registers and print a fatal error
+     message.  For most machines, you should not define this macro at
+     all.
+
+`CLASS_LIKELY_SPILLED_P (CLASS)'
+     A C expression whose value is nonzero if pseudos that have been
+     assigned to registers of class CLASS would likely be spilled
+     because registers of CLASS are needed for spill registers.
+
+     The default value of this macro returns 1 if CLASS has exactly one
+     register and zero otherwise.  On most machines, this default
+     should be used.  Only define this macro to some other expression
+     if pseudos allocated by `local-alloc.c' end up in memory because
+     their hard registers were needed for spill registers.  If this
+     macro returns nonzero for those classes, those pseudos will only
+     be allocated by `global.c', which knows how to reallocate the
+     pseudo to another register.  If there would not be another
+     register available for reallocation, you should not change the
+     definition of this macro since the only effect of such a
+     definition would be to slow down register allocation.
+
+`CLASS_MAX_NREGS (CLASS, MODE)'
+     A C expression for the maximum number of consecutive registers of
+     class CLASS needed to hold a value of mode MODE.
+
+     This is closely related to the macro `HARD_REGNO_NREGS'.  In fact,
+     the value of the macro `CLASS_MAX_NREGS (CLASS, MODE)' should be
+     the maximum value of `HARD_REGNO_NREGS (REGNO, MODE)' for all
+     REGNO values in the class CLASS.
+
+     This macro helps control the handling of multiple-word values in
+     the reload pass.
+
+`CLASS_CANNOT_CHANGE_SIZE'
+     If defined, a C expression for a class that contains registers
+     which the compiler must always access in a mode that is the same
+     size as the mode in which it loaded the register.
+
+     For the example, loading 32-bit integer or floating-point objects
+     into floating-point registers on the Alpha extends them to 64-bits.
+     Therefore loading a 64-bit object and then storing it as a 32-bit
+     object does not store the low-order 32-bits, as would be the case
+     for a normal register.  Therefore, `alpha.h' defines this macro as
+     `FLOAT_REGS'.
+
+   Three other special macros describe which operands fit which
+constraint letters.
+
+`CONST_OK_FOR_LETTER_P (VALUE, C)'
+     A C expression that defines the machine-dependent operand
+     constraint letters (`I', `J', `K', ... `P') that specify
+     particular ranges of integer values.  If C is one of those
+     letters, the expression should check that VALUE, an integer, is in
+     the appropriate range and return 1 if so, 0 otherwise.  If C is
+     not one of those letters, the value should be 0 regardless of
+     VALUE.
+
+`CONST_DOUBLE_OK_FOR_LETTER_P (VALUE, C)'
+     A C expression that defines the machine-dependent operand
+     constraint letters that specify particular ranges of
+     `const_double' values (`G' or `H').
+
+     If C is one of those letters, the expression should check that
+     VALUE, an RTX of code `const_double', is in the appropriate range
+     and return 1 if so, 0 otherwise.  If C is not one of those
+     letters, the value should be 0 regardless of VALUE.
+
+     `const_double' is used for all floating-point constants and for
+     `DImode' fixed-point constants.  A given letter can accept either
+     or both kinds of values.  It can use `GET_MODE' to distinguish
+     between these kinds.
+
+`EXTRA_CONSTRAINT (VALUE, C)'
+     A C expression that defines the optional machine-dependent
+     constraint letters (`Q', `R', `S', `T', `U') that can be used to
+     segregate specific types of operands, usually memory references,
+     for the target machine.  Normally this macro will not be defined.
+     If it is required for a particular target machine, it should
+     return 1 if VALUE corresponds to the operand type represented by
+     the constraint letter C.  If C is not defined as an extra
+     constraint, the value returned should be 0 regardless of VALUE.
+
+     For example, on the ROMP, load instructions cannot have their
+     output in r0 if the memory reference contains a symbolic address.
+     Constraint letter `Q' is defined as representing a memory address
+     that does *not* contain a symbolic address.  An alternative is
+     specified with a `Q' constraint on the input and `r' on the
+     output.  The next alternative specifies `m' on the input and a
+     register class that does not include r0 on the output.
+
+
+File: gcc.info,  Node: Stack and Calling,  Next: Varargs,  Prev: Register Classes,  Up: Target Macros
+
+Stack Layout and Calling Conventions
+====================================
+
+   This describes the stack layout and calling conventions.
+
+* Menu:
+
+* Frame Layout::
+* Stack Checking::
+* Frame Registers::
+* Elimination::
+* Stack Arguments::
+* Register Arguments::
+* Scalar Return::
+* Aggregate Return::
+* Caller Saves::
+* Function Entry::
+* Profiling::
+
+
+File: gcc.info,  Node: Frame Layout,  Next: Stack Checking,  Up: Stack and Calling
+
+Basic Stack Layout
+------------------
+
+   Here is the basic stack layout.
+
+`STACK_GROWS_DOWNWARD'
+     Define this macro if pushing a word onto the stack moves the stack
+     pointer to a smaller address.
+
+     When we say, "define this macro if ...," it means that the
+     compiler checks this macro only with `#ifdef' so the precise
+     definition used does not matter.
+
+`FRAME_GROWS_DOWNWARD'
+     Define this macro if the addresses of local variable slots are at
+     negative offsets from the frame pointer.
+
+`ARGS_GROW_DOWNWARD'
+     Define this macro if successive arguments to a function occupy
+     decreasing addresses on the stack.
+
+`STARTING_FRAME_OFFSET'
+     Offset from the frame pointer to the first local variable slot to
+     be allocated.
+
+     If `FRAME_GROWS_DOWNWARD', find the next slot's offset by
+     subtracting the first slot's length from `STARTING_FRAME_OFFSET'.
+     Otherwise, it is found by adding the length of the first slot to
+     the value `STARTING_FRAME_OFFSET'.
+
+`STACK_POINTER_OFFSET'
+     Offset from the stack pointer register to the first location at
+     which outgoing arguments are placed.  If not specified, the
+     default value of zero is used.  This is the proper value for most
+     machines.
+
+     If `ARGS_GROW_DOWNWARD', this is the offset to the location above
+     the first location at which outgoing arguments are placed.
+
+`FIRST_PARM_OFFSET (FUNDECL)'
+     Offset from the argument pointer register to the first argument's
+     address.  On some machines it may depend on the data type of the
+     function.
+
+     If `ARGS_GROW_DOWNWARD', this is the offset to the location above
+     the first argument's address.
+
+`STACK_DYNAMIC_OFFSET (FUNDECL)'
+     Offset from the stack pointer register to an item dynamically
+     allocated on the stack, e.g., by `alloca'.
+
+     The default value for this macro is `STACK_POINTER_OFFSET' plus the
+     length of the outgoing arguments.  The default is correct for most
+     machines.  See `function.c' for details.
+
+`DYNAMIC_CHAIN_ADDRESS (FRAMEADDR)'
+     A C expression whose value is RTL representing the address in a
+     stack frame where the pointer to the caller's frame is stored.
+     Assume that FRAMEADDR is an RTL expression for the address of the
+     stack frame itself.
+
+     If you don't define this macro, the default is to return the value
+     of FRAMEADDR--that is, the stack frame address is also the address
+     of the stack word that points to the previous frame.
+
+`SETUP_FRAME_ADDRESSES'
+     If defined, a C expression that produces the machine-specific code
+     to setup the stack so that arbitrary frames can be accessed.  For
+     example, on the Sparc, we must flush all of the register windows
+     to the stack before we can access arbitrary stack frames.  You
+     will seldom need to define this macro.
+
+`BUILTIN_SETJMP_FRAME_VALUE'
+     If defined, a C expression that contains an rtx that is used to
+     store the address of the current frame into the built in `setjmp'
+     buffer.  The default value, `virtual_stack_vars_rtx', is correct
+     for most machines.  One reason you may need to define this macro
+     is if `hard_frame_pointer_rtx' is the appropriate value on your
+     machine.
+
+`RETURN_ADDR_RTX (COUNT, FRAMEADDR)'
+     A C expression whose value is RTL representing the value of the
+     return address for the frame COUNT steps up from the current
+     frame, after the prologue.  FRAMEADDR is the frame pointer of the
+     COUNT frame, or the frame pointer of the COUNT - 1 frame if
+     `RETURN_ADDR_IN_PREVIOUS_FRAME' is defined.
+
+     The value of the expression must always be the correct address when
+     COUNT is zero, but may be `NULL_RTX' if there is not way to
+     determine the return address of other frames.
+
+`RETURN_ADDR_IN_PREVIOUS_FRAME'
+     Define this if the return address of a particular stack frame is
+     accessed from the frame pointer of the previous stack frame.
+
+`INCOMING_RETURN_ADDR_RTX'
+     A C expression whose value is RTL representing the location of the
+     incoming return address at the beginning of any function, before
+     the prologue.  This RTL is either a `REG', indicating that the
+     return value is saved in `REG', or a `MEM' representing a location
+     in the stack.
+
+     You only need to define this macro if you want to support call
+     frame debugging information like that provided by DWARF 2.
+
+`INCOMING_FRAME_SP_OFFSET'
+     A C expression whose value is an integer giving the offset, in
+     bytes, from the value of the stack pointer register to the top of
+     the stack frame at the beginning of any function, before the
+     prologue.  The top of the frame is defined to be the value of the
+     stack pointer in the previous frame, just before the call
+     instruction.
+
+     You only need to define this macro if you want to support call
+     frame debugging information like that provided by DWARF 2.
+
+`ARG_POINTER_CFA_OFFSET'
+     A C expression whose value is an integer giving the offset, in
+     bytes, from the argument pointer to the canonical frame address
+     (cfa).  The final value should coincide with that calculated by
+     `INCOMING_FRAME_SP_OFFSET'.  Which is unfortunately not usable
+     during virtual register instantiation.
+
+     You only need to define this macro if you want to support call
+     frame debugging information like that provided by DWARF 2.
+
+
+File: gcc.info,  Node: Stack Checking,  Next: Frame Registers,  Prev: Frame Layout,  Up: Stack and Calling
+
+Specifying How Stack Checking is Done
+-------------------------------------
+
+   GNU CC will check that stack references are within the boundaries of
+the stack, if the `-fstack-check' is specified, in one of three ways:
+
+  1. If the value of the `STACK_CHECK_BUILTIN' macro is nonzero, GNU CC
+     will assume that you have arranged for stack checking to be done at
+     appropriate places in the configuration files, e.g., in
+     `FUNCTION_PROLOGUE'.  GNU CC will do not other special processing.
+
+  2. If `STACK_CHECK_BUILTIN' is zero and you defined a named pattern
+     called `check_stack' in your `md' file, GNU CC will call that
+     pattern with one argument which is the address to compare the stack
+     value against.  You must arrange for this pattern to report an
+     error if the stack pointer is out of range.
+
+  3. If neither of the above are true, GNU CC will generate code to
+     periodically "probe" the stack pointer using the values of the
+     macros defined below.
+
+   Normally, you will use the default values of these macros, so GNU CC
+will use the third approach.
+
+`STACK_CHECK_BUILTIN'
+     A nonzero value if stack checking is done by the configuration
+     files in a machine-dependent manner.  You should define this macro
+     if stack checking is require by the ABI of your machine or if you
+     would like to have to stack checking in some more efficient way
+     than GNU CC's portable approach.  The default value of this macro
+     is zero.
+
+`STACK_CHECK_PROBE_INTERVAL'
+     An integer representing the interval at which GNU CC must generate
+     stack probe instructions.  You will normally define this macro to
+     be no larger than the size of the "guard pages" at the end of a
+     stack area.  The default value of 4096 is suitable for most
+     systems.
+
+`STACK_CHECK_PROBE_LOAD'
+     A integer which is nonzero if GNU CC should perform the stack probe
+     as a load instruction and zero if GNU CC should use a store
+     instruction.  The default is zero, which is the most efficient
+     choice on most systems.
+
+`STACK_CHECK_PROTECT'
+     The number of bytes of stack needed to recover from a stack
+     overflow, for languages where such a recovery is supported.  The
+     default value of 75 words should be adequate for most machines.
+
+`STACK_CHECK_MAX_FRAME_SIZE'
+     The maximum size of a stack frame, in bytes.  GNU CC will generate
+     probe instructions in non-leaf functions to ensure at least this
+     many bytes of stack are available.  If a stack frame is larger
+     than this size, stack checking will not be reliable and GNU CC
+     will issue a warning.  The default is chosen so that GNU CC only
+     generates one instruction on most systems.  You should normally
+     not change the default value of this macro.
+
+`STACK_CHECK_FIXED_FRAME_SIZE'
+     GNU CC uses this value to generate the above warning message.  It
+     represents the amount of fixed frame used by a function, not
+     including space for any callee-saved registers, temporaries and
+     user variables.  You need only specify an upper bound for this
+     amount and will normally use the default of four words.
+
+`STACK_CHECK_MAX_VAR_SIZE'
+     The maximum size, in bytes, of an object that GNU CC will place in
+     the fixed area of the stack frame when the user specifies
+     `-fstack-check'.  GNU CC computed the default from the values of
+     the above macros and you will normally not need to override that
+     default.
+
+
+File: gcc.info,  Node: Frame Registers,  Next: Elimination,  Prev: Stack Checking,  Up: Stack and Calling
+
+Registers That Address the Stack Frame
+--------------------------------------
+
+   This discusses registers that address the stack frame.
+
+`STACK_POINTER_REGNUM'
+     The register number of the stack pointer register, which must also
+     be a fixed register according to `FIXED_REGISTERS'.  On most
+     machines, the hardware determines which register this is.
+
+`FRAME_POINTER_REGNUM'
+     The register number of the frame pointer register, which is used to
+     access automatic variables in the stack frame.  On some machines,
+     the hardware determines which register this is.  On other
+     machines, you can choose any register you wish for this purpose.
+
+`HARD_FRAME_POINTER_REGNUM'
+     On some machines the offset between the frame pointer and starting
+     offset of the automatic variables is not known until after register
+     allocation has been done (for example, because the saved registers
+     are between these two locations).  On those machines, define
+     `FRAME_POINTER_REGNUM' the number of a special, fixed register to
+     be used internally until the offset is known, and define
+     `HARD_FRAME_POINTER_REGNUM' to be the actual hard register number
+     used for the frame pointer.
+
+     You should define this macro only in the very rare circumstances
+     when it is not possible to calculate the offset between the frame
+     pointer and the automatic variables until after register
+     allocation has been completed.  When this macro is defined, you
+     must also indicate in your definition of `ELIMINABLE_REGS' how to
+     eliminate `FRAME_POINTER_REGNUM' into either
+     `HARD_FRAME_POINTER_REGNUM' or `STACK_POINTER_REGNUM'.
+
+     Do not define this macro if it would be the same as
+     `FRAME_POINTER_REGNUM'.
+
+`ARG_POINTER_REGNUM'
+     The register number of the arg pointer register, which is used to
+     access the function's argument list.  On some machines, this is
+     the same as the frame pointer register.  On some machines, the
+     hardware determines which register this is.  On other machines,
+     you can choose any register you wish for this purpose.  If this is
+     not the same register as the frame pointer register, then you must
+     mark it as a fixed register according to `FIXED_REGISTERS', or
+     arrange to be able to eliminate it (*note Elimination::.).
+
+`RETURN_ADDRESS_POINTER_REGNUM'
+     The register number of the return address pointer register, which
+     is used to access the current function's return address from the
+     stack.  On some machines, the return address is not at a fixed
+     offset from the frame pointer or stack pointer or argument
+     pointer.  This register can be defined to point to the return
+     address on the stack, and then be converted by `ELIMINABLE_REGS'
+     into either the frame pointer or stack pointer.
+
+     Do not define this macro unless there is no other way to get the
+     return address from the stack.
+
+`STATIC_CHAIN_REGNUM'
+`STATIC_CHAIN_INCOMING_REGNUM'
+     Register numbers used for passing a function's static chain
+     pointer.  If register windows are used, the register number as
+     seen by the called function is `STATIC_CHAIN_INCOMING_REGNUM',
+     while the register number as seen by the calling function is
+     `STATIC_CHAIN_REGNUM'.  If these registers are the same,
+     `STATIC_CHAIN_INCOMING_REGNUM' need not be defined.
+
+     The static chain register need not be a fixed register.
+
+     If the static chain is passed in memory, these macros should not be
+     defined; instead, the next two macros should be defined.
+
+`STATIC_CHAIN'
+`STATIC_CHAIN_INCOMING'
+     If the static chain is passed in memory, these macros provide rtx
+     giving `mem' expressions that denote where they are stored.
+     `STATIC_CHAIN' and `STATIC_CHAIN_INCOMING' give the locations as
+     seen by the calling and called functions, respectively.  Often the
+     former will be at an offset from the stack pointer and the latter
+     at an offset from the frame pointer.
+
+     The variables `stack_pointer_rtx', `frame_pointer_rtx', and
+     `arg_pointer_rtx' will have been initialized prior to the use of
+     these macros and should be used to refer to those items.
+
+     If the static chain is passed in a register, the two previous
+     macros should be defined instead.
+
+
+File: gcc.info,  Node: Elimination,  Next: Stack Arguments,  Prev: Frame Registers,  Up: Stack and Calling
+
+Eliminating Frame Pointer and Arg Pointer
+-----------------------------------------
+
+   This is about eliminating the frame pointer and arg pointer.
+
+`FRAME_POINTER_REQUIRED'
+     A C expression which is nonzero if a function must have and use a
+     frame pointer.  This expression is evaluated  in the reload pass.
+     If its value is nonzero the function will have a frame pointer.
+
+     The expression can in principle examine the current function and
+     decide according to the facts, but on most machines the constant 0
+     or the constant 1 suffices.  Use 0 when the machine allows code to
+     be generated with no frame pointer, and doing so saves some time
+     or space.  Use 1 when there is no possible advantage to avoiding a
+     frame pointer.
+
+     In certain cases, the compiler does not know how to produce valid
+     code without a frame pointer.  The compiler recognizes those cases
+     and automatically gives the function a frame pointer regardless of
+     what `FRAME_POINTER_REQUIRED' says.  You don't need to worry about
+     them.
+
+     In a function that does not require a frame pointer, the frame
+     pointer register can be allocated for ordinary usage, unless you
+     mark it as a fixed register.  See `FIXED_REGISTERS' for more
+     information.
+
+`INITIAL_FRAME_POINTER_OFFSET (DEPTH-VAR)'
+     A C statement to store in the variable DEPTH-VAR the difference
+     between the frame pointer and the stack pointer values immediately
+     after the function prologue.  The value would be computed from
+     information such as the result of `get_frame_size ()' and the
+     tables of registers `regs_ever_live' and `call_used_regs'.
+
+     If `ELIMINABLE_REGS' is defined, this macro will be not be used and
+     need not be defined.  Otherwise, it must be defined even if
+     `FRAME_POINTER_REQUIRED' is defined to always be true; in that
+     case, you may set DEPTH-VAR to anything.
+
+`ELIMINABLE_REGS'
+     If defined, this macro specifies a table of register pairs used to
+     eliminate unneeded registers that point into the stack frame.  If
+     it is not defined, the only elimination attempted by the compiler
+     is to replace references to the frame pointer with references to
+     the stack pointer.
+
+     The definition of this macro is a list of structure
+     initializations, each of which specifies an original and
+     replacement register.
+
+     On some machines, the position of the argument pointer is not
+     known until the compilation is completed.  In such a case, a
+     separate hard register must be used for the argument pointer.
+     This register can be eliminated by replacing it with either the
+     frame pointer or the argument pointer, depending on whether or not
+     the frame pointer has been eliminated.
+
+     In this case, you might specify:
+          #define ELIMINABLE_REGS  \
+          {{ARG_POINTER_REGNUM, STACK_POINTER_REGNUM}, \
+           {ARG_POINTER_REGNUM, FRAME_POINTER_REGNUM}, \
+           {FRAME_POINTER_REGNUM, STACK_POINTER_REGNUM}}
+
+     Note that the elimination of the argument pointer with the stack
+     pointer is specified first since that is the preferred elimination.
+
+`CAN_ELIMINATE (FROM-REG, TO-REG)'
+     A C expression that returns non-zero if the compiler is allowed to
+     try to replace register number FROM-REG with register number
+     TO-REG.  This macro need only be defined if `ELIMINABLE_REGS' is
+     defined, and will usually be the constant 1, since most of the
+     cases preventing register elimination are things that the compiler
+     already knows about.
+
+`INITIAL_ELIMINATION_OFFSET (FROM-REG, TO-REG, OFFSET-VAR)'
+     This macro is similar to `INITIAL_FRAME_POINTER_OFFSET'.  It
+     specifies the initial difference between the specified pair of
+     registers.  This macro must be defined if `ELIMINABLE_REGS' is
+     defined.
+
+`LONGJMP_RESTORE_FROM_STACK'
+     Define this macro if the `longjmp' function restores registers from
+     the stack frames, rather than from those saved specifically by
+     `setjmp'.  Certain quantities must not be kept in registers across
+     a call to `setjmp' on such machines.
+
+
+File: gcc.info,  Node: Stack Arguments,  Next: Register Arguments,  Prev: Elimination,  Up: Stack and Calling
+
+Passing Function Arguments on the Stack
+---------------------------------------
+
+   The macros in this section control how arguments are passed on the
+stack.  See the following section for other macros that control passing
+certain arguments in registers.
+
+`PROMOTE_PROTOTYPES'
+     Define this macro if an argument declared in a prototype as an
+     integral type smaller than `int' should actually be passed as an
+     `int'.  In addition to avoiding errors in certain cases of
+     mismatch, it also makes for better code on certain machines.
+
+`PUSH_ROUNDING (NPUSHED)'
+     A C expression that is the number of bytes actually pushed onto the
+     stack when an instruction attempts to push NPUSHED bytes.
+
+     If the target machine does not have a push instruction, do not
+     define this macro.  That directs GNU CC to use an alternate
+     strategy: to allocate the entire argument block and then store the
+     arguments into it.
+
+     On some machines, the definition
+
+          #define PUSH_ROUNDING(BYTES) (BYTES)
+
+     will suffice.  But on other machines, instructions that appear to
+     push one byte actually push two bytes in an attempt to maintain
+     alignment.  Then the definition should be
+
+          #define PUSH_ROUNDING(BYTES) (((BYTES) + 1) & ~1)
+
+`ACCUMULATE_OUTGOING_ARGS'
+     If defined, the maximum amount of space required for outgoing
+     arguments will be computed and placed into the variable
+     `current_function_outgoing_args_size'.  No space will be pushed
+     onto the stack for each call; instead, the function prologue should
+     increase the stack frame size by this amount.
+
+     Defining both `PUSH_ROUNDING' and `ACCUMULATE_OUTGOING_ARGS' is
+     not proper.
+
+`REG_PARM_STACK_SPACE (FNDECL)'
+     Define this macro if functions should assume that stack space has
+     been allocated for arguments even when their values are passed in
+     registers.
+
+     The value of this macro is the size, in bytes, of the area
+     reserved for arguments passed in registers for the function
+     represented by FNDECL, which can be zero if GNU CC is calling a
+     library function.
+
+     This space can be allocated by the caller, or be a part of the
+     machine-dependent stack frame: `OUTGOING_REG_PARM_STACK_SPACE' says
+     which.
+
+`MAYBE_REG_PARM_STACK_SPACE'
+`FINAL_REG_PARM_STACK_SPACE (CONST_SIZE, VAR_SIZE)'
+     Define these macros in addition to the one above if functions might
+     allocate stack space for arguments even when their values are
+     passed in registers.  These should be used when the stack space
+     allocated for arguments in registers is not a simple constant
+     independent of the function declaration.
+
+     The value of the first macro is the size, in bytes, of the area
+     that we should initially assume would be reserved for arguments
+     passed in registers.
+
+     The value of the second macro is the actual size, in bytes, of the
+     area that will be reserved for arguments passed in registers.
+     This takes two arguments: an integer representing the number of
+     bytes of fixed sized arguments on the stack, and a tree
+     representing the number of bytes of variable sized arguments on
+     the stack.
+
+     When these macros are defined, `REG_PARM_STACK_SPACE' will only be
+     called for libcall functions, the current function, or for a
+     function being called when it is known that such stack space must
+     be allocated.  In each case this value can be easily computed.
+
+     When deciding whether a called function needs such stack space,
+     and how much space to reserve, GNU CC uses these two macros
+     instead of `REG_PARM_STACK_SPACE'.
+
+`OUTGOING_REG_PARM_STACK_SPACE'
+     Define this if it is the responsibility of the caller to allocate
+     the area reserved for arguments passed in registers.
+
+     If `ACCUMULATE_OUTGOING_ARGS' is defined, this macro controls
+     whether the space for these arguments counts in the value of
+     `current_function_outgoing_args_size'.
+
+`STACK_PARMS_IN_REG_PARM_AREA'
+     Define this macro if `REG_PARM_STACK_SPACE' is defined, but the
+     stack parameters don't skip the area specified by it.
+
+     Normally, when a parameter is not passed in registers, it is
+     placed on the stack beyond the `REG_PARM_STACK_SPACE' area.
+     Defining this macro suppresses this behavior and causes the
+     parameter to be passed on the stack in its natural location.
+
+`RETURN_POPS_ARGS (FUNDECL, FUNTYPE, STACK-SIZE)'
+     A C expression that should indicate the number of bytes of its own
+     arguments that a function pops on returning, or 0 if the function
+     pops no arguments and the caller must therefore pop them all after
+     the function returns.
+
+     FUNDECL is a C variable whose value is a tree node that describes
+     the function in question.  Normally it is a node of type
+     `FUNCTION_DECL' that describes the declaration of the function.
+     From this you can obtain the DECL_MACHINE_ATTRIBUTES of the
+     function.
+
+     FUNTYPE is a C variable whose value is a tree node that describes
+     the function in question.  Normally it is a node of type
+     `FUNCTION_TYPE' that describes the data type of the function.
+     From this it is possible to obtain the data types of the value and
+     arguments (if known).
+
+     When a call to a library function is being considered, FUNDECL
+     will contain an identifier node for the library function.  Thus, if
+     you need to distinguish among various library functions, you can
+     do so by their names.  Note that "library function" in this
+     context means a function used to perform arithmetic, whose name is
+     known specially in the compiler and was not mentioned in the C
+     code being compiled.
+
+     STACK-SIZE is the number of bytes of arguments passed on the
+     stack.  If a variable number of bytes is passed, it is zero, and
+     argument popping will always be the responsibility of the calling
+     function.
+
+     On the Vax, all functions always pop their arguments, so the
+     definition of this macro is STACK-SIZE.  On the 68000, using the
+     standard calling convention, no functions pop their arguments, so
+     the value of the macro is always 0 in this case.  But an
+     alternative calling convention is available in which functions
+     that take a fixed number of arguments pop them but other functions
+     (such as `printf') pop nothing (the caller pops all).  When this
+     convention is in use, FUNTYPE is examined to determine whether a
+     function takes a fixed number of arguments.
+

usr/local/nachos/info/gcc.info-24

@@ -0,0 +1,982 @@
+This is Info file gcc.info, produced by Makeinfo version 1.68 from the
+input file ../../gcc-2.95.2/gcc/gcc.texi.
+
+INFO-DIR-SECTION Programming
+START-INFO-DIR-ENTRY
+* gcc: (gcc).                  The GNU Compiler Collection.
+END-INFO-DIR-ENTRY
+   This file documents the use and the internals of the GNU compiler.
+
+   Published by the Free Software Foundation 59 Temple Place - Suite 330
+Boston, MA 02111-1307 USA
+
+   Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
+1999 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 sections entitled "GNU General Public License" and "Funding
+for Free Software" are included exactly as in the original, and
+provided 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, except that the sections entitled "GNU General Public
+License" and "Funding for Free Software", and this permission notice,
+may be included in translations approved by the Free Software Foundation
+instead of in the original English.
+
+
+File: gcc.info,  Node: Register Arguments,  Next: Scalar Return,  Prev: Stack Arguments,  Up: Stack and Calling
+
+Passing Arguments in Registers
+------------------------------
+
+   This section describes the macros which let you control how various
+types of arguments are passed in registers or how they are arranged in
+the stack.
+
+`FUNCTION_ARG (CUM, MODE, TYPE, NAMED)'
+     A C expression that controls whether a function argument is passed
+     in a register, and which register.
+
+     The arguments are CUM, which summarizes all the previous
+     arguments; MODE, the machine mode of the argument; TYPE, the data
+     type of the argument as a tree node or 0 if that is not known
+     (which happens for C support library functions); and NAMED, which
+     is 1 for an ordinary argument and 0 for nameless arguments that
+     correspond to `...' in the called function's prototype.
+
+     The value of the expression is usually either a `reg' RTX for the
+     hard register in which to pass the argument, or zero to pass the
+     argument on the stack.
+
+     For machines like the Vax and 68000, where normally all arguments
+     are pushed, zero suffices as a definition.
+
+     The value of the expression can also be a `parallel' RTX.  This is
+     used when an argument is passed in multiple locations.  The mode
+     of the of the `parallel' should be the mode of the entire
+     argument.  The `parallel' holds any number of `expr_list' pairs;
+     each one describes where part of the argument is passed.  In each
+     `expr_list' the first operand must be a `reg' RTX for the hard
+     register in which to pass this part of the argument, and the mode
+     of the register RTX indicates how large this part of the argument
+     is.  The second operand of the `expr_list' is a `const_int' which
+     gives the offset in bytes into the entire argument of where this
+     part starts.  As a special exception the first `expr_list' in the
+     `parallel' RTX may have a first operand of zero.  This indicates
+     that the bytes starting from the second operand of that
+     `expr_list' are stored on the stack and not held in a register.
+
+     The usual way to make the ANSI library `stdarg.h' work on a machine
+     where some arguments are usually passed in registers, is to cause
+     nameless arguments to be passed on the stack instead.  This is done
+     by making `FUNCTION_ARG' return 0 whenever NAMED is 0.
+
+     You may use the macro `MUST_PASS_IN_STACK (MODE, TYPE)' in the
+     definition of this macro to determine if this argument is of a
+     type that must be passed in the stack.  If `REG_PARM_STACK_SPACE'
+     is not defined and `FUNCTION_ARG' returns non-zero for such an
+     argument, the compiler will abort.  If `REG_PARM_STACK_SPACE' is
+     defined, the argument will be computed in the stack and then
+     loaded into a register.
+
+`MUST_PASS_IN_STACK (MODE, TYPE)'
+     Define as a C expression that evaluates to nonzero if we do not
+     know how to pass TYPE solely in registers.  The file `expr.h'
+     defines a definition that is usually appropriate, refer to
+     `expr.h' for additional documentation.
+
+`FUNCTION_INCOMING_ARG (CUM, MODE, TYPE, NAMED)'
+     Define this macro if the target machine has "register windows", so
+     that the register in which a function sees an arguments is not
+     necessarily the same as the one in which the caller passed the
+     argument.
+
+     For such machines, `FUNCTION_ARG' computes the register in which
+     the caller passes the value, and `FUNCTION_INCOMING_ARG' should be
+     defined in a similar fashion to tell the function being called
+     where the arguments will arrive.
+
+     If `FUNCTION_INCOMING_ARG' is not defined, `FUNCTION_ARG' serves
+     both purposes.
+
+`FUNCTION_ARG_PARTIAL_NREGS (CUM, MODE, TYPE, NAMED)'
+     A C expression for the number of words, at the beginning of an
+     argument, must be put in registers.  The value must be zero for
+     arguments that are passed entirely in registers or that are
+     entirely pushed on the stack.
+
+     On some machines, certain arguments must be passed partially in
+     registers and partially in memory.  On these machines, typically
+     the first N words of arguments are passed in registers, and the
+     rest on the stack.  If a multi-word argument (a `double' or a
+     structure) crosses that boundary, its first few words must be
+     passed in registers and the rest must be pushed.  This macro tells
+     the compiler when this occurs, and how many of the words should go
+     in registers.
+
+     `FUNCTION_ARG' for these arguments should return the first
+     register to be used by the caller for this argument; likewise
+     `FUNCTION_INCOMING_ARG', for the called function.
+
+`FUNCTION_ARG_PASS_BY_REFERENCE (CUM, MODE, TYPE, NAMED)'
+     A C expression that indicates when an argument must be passed by
+     reference.  If nonzero for an argument, a copy of that argument is
+     made in memory and a pointer to the argument is passed instead of
+     the argument itself.  The pointer is passed in whatever way is
+     appropriate for passing a pointer to that type.
+
+     On machines where `REG_PARM_STACK_SPACE' is not defined, a suitable
+     definition of this macro might be
+          #define FUNCTION_ARG_PASS_BY_REFERENCE\
+          (CUM, MODE, TYPE, NAMED)  \
+            MUST_PASS_IN_STACK (MODE, TYPE)
+
+`FUNCTION_ARG_CALLEE_COPIES (CUM, MODE, TYPE, NAMED)'
+     If defined, a C expression that indicates when it is the called
+     function's responsibility to make a copy of arguments passed by
+     invisible reference.  Normally, the caller makes a copy and passes
+     the address of the copy to the routine being called.  When
+     FUNCTION_ARG_CALLEE_COPIES is defined and is nonzero, the caller
+     does not make a copy.  Instead, it passes a pointer to the "live"
+     value.  The called function must not modify this value.  If it can
+     be determined that the value won't be modified, it need not make a
+     copy; otherwise a copy must be made.
+
+`CUMULATIVE_ARGS'
+     A C type for declaring a variable that is used as the first
+     argument of `FUNCTION_ARG' and other related values.  For some
+     target machines, the type `int' suffices and can hold the number
+     of bytes of argument so far.
+
+     There is no need to record in `CUMULATIVE_ARGS' anything about the
+     arguments that have been passed on the stack.  The compiler has
+     other variables to keep track of that.  For target machines on
+     which all arguments are passed on the stack, there is no need to
+     store anything in `CUMULATIVE_ARGS'; however, the data structure
+     must exist and should not be empty, so use `int'.
+
+`INIT_CUMULATIVE_ARGS (CUM, FNTYPE, LIBNAME, INDIRECT)'
+     A C statement (sans semicolon) for initializing the variable CUM
+     for the state at the beginning of the argument list.  The variable
+     has type `CUMULATIVE_ARGS'.  The value of FNTYPE is the tree node
+     for the data type of the function which will receive the args, or 0
+     if the args are to a compiler support library function.  The value
+     of INDIRECT is nonzero when processing an indirect call, for
+     example a call through a function pointer.  The value of INDIRECT
+     is zero for a call to an explicitly named function, a library
+     function call, or when `INIT_CUMULATIVE_ARGS' is used to find
+     arguments for the function being compiled.
+
+     When processing a call to a compiler support library function,
+     LIBNAME identifies which one.  It is a `symbol_ref' rtx which
+     contains the name of the function, as a string.  LIBNAME is 0 when
+     an ordinary C function call is being processed.  Thus, each time
+     this macro is called, either LIBNAME or FNTYPE is nonzero, but
+     never both of them at once.
+
+`INIT_CUMULATIVE_INCOMING_ARGS (CUM, FNTYPE, LIBNAME)'
+     Like `INIT_CUMULATIVE_ARGS' but overrides it for the purposes of
+     finding the arguments for the function being compiled.  If this
+     macro is undefined, `INIT_CUMULATIVE_ARGS' is used instead.
+
+     The value passed for LIBNAME is always 0, since library routines
+     with special calling conventions are never compiled with GNU CC.
+     The argument LIBNAME exists for symmetry with
+     `INIT_CUMULATIVE_ARGS'.
+
+`FUNCTION_ARG_ADVANCE (CUM, MODE, TYPE, NAMED)'
+     A C statement (sans semicolon) to update the summarizer variable
+     CUM to advance past an argument in the argument list.  The values
+     MODE, TYPE and NAMED describe that argument.  Once this is done,
+     the variable CUM is suitable for analyzing the *following*
+     argument with `FUNCTION_ARG', etc.
+
+     This macro need not do anything if the argument in question was
+     passed on the stack.  The compiler knows how to track the amount
+     of stack space used for arguments without any special help.
+
+`FUNCTION_ARG_PADDING (MODE, TYPE)'
+     If defined, a C expression which determines whether, and in which
+     direction, to pad out an argument with extra space.  The value
+     should be of type `enum direction': either `upward' to pad above
+     the argument, `downward' to pad below, or `none' to inhibit
+     padding.
+
+     The *amount* of padding is always just enough to reach the next
+     multiple of `FUNCTION_ARG_BOUNDARY'; this macro does not control
+     it.
+
+     This macro has a default definition which is right for most
+     systems.  For little-endian machines, the default is to pad
+     upward.  For big-endian machines, the default is to pad downward
+     for an argument of constant size shorter than an `int', and upward
+     otherwise.
+
+`FUNCTION_ARG_BOUNDARY (MODE, TYPE)'
+     If defined, a C expression that gives the alignment boundary, in
+     bits, of an argument with the specified mode and type.  If it is
+     not defined, `PARM_BOUNDARY' is used for all arguments.
+
+`FUNCTION_ARG_REGNO_P (REGNO)'
+     A C expression that is nonzero if REGNO is the number of a hard
+     register in which function arguments are sometimes passed.  This
+     does *not* include implicit arguments such as the static chain and
+     the structure-value address.  On many machines, no registers can be
+     used for this purpose since all function arguments are pushed on
+     the stack.
+
+`LOAD_ARGS_REVERSED'
+     If defined, the order in which arguments are loaded into their
+     respective argument registers is reversed so that the last
+     argument is loaded first.  This macro only effects arguments
+     passed in registers.
+
+
+File: gcc.info,  Node: Scalar Return,  Next: Aggregate Return,  Prev: Register Arguments,  Up: Stack and Calling
+
+How Scalar Function Values Are Returned
+---------------------------------------
+
+   This section discusses the macros that control returning scalars as
+values--values that can fit in registers.
+
+`TRADITIONAL_RETURN_FLOAT'
+     Define this macro if `-traditional' should not cause functions
+     declared to return `float' to convert the value to `double'.
+
+`FUNCTION_VALUE (VALTYPE, FUNC)'
+     A C expression to create an RTX representing the place where a
+     function returns a value of data type VALTYPE.  VALTYPE is a tree
+     node representing a data type.  Write `TYPE_MODE (VALTYPE)' to get
+     the machine mode used to represent that type.  On many machines,
+     only the mode is relevant.  (Actually, on most machines, scalar
+     values are returned in the same place regardless of mode).
+
+     The value of the expression is usually a `reg' RTX for the hard
+     register where the return value is stored.  The value can also be a
+     `parallel' RTX, if the return value is in multiple places.  See
+     `FUNCTION_ARG' for an explanation of the `parallel' form.
+
+     If `PROMOTE_FUNCTION_RETURN' is defined, you must apply the same
+     promotion rules specified in `PROMOTE_MODE' if VALTYPE is a scalar
+     type.
+
+     If the precise function being called is known, FUNC is a tree node
+     (`FUNCTION_DECL') for it; otherwise, FUNC is a null pointer.  This
+     makes it possible to use a different value-returning convention
+     for specific functions when all their calls are known.
+
+     `FUNCTION_VALUE' is not used for return vales with aggregate data
+     types, because these are returned in another way.  See
+     `STRUCT_VALUE_REGNUM' and related macros, below.
+
+`FUNCTION_OUTGOING_VALUE (VALTYPE, FUNC)'
+     Define this macro if the target machine has "register windows" so
+     that the register in which a function returns its value is not the
+     same as the one in which the caller sees the value.
+
+     For such machines, `FUNCTION_VALUE' computes the register in which
+     the caller will see the value.  `FUNCTION_OUTGOING_VALUE' should be
+     defined in a similar fashion to tell the function where to put the
+     value.
+
+     If `FUNCTION_OUTGOING_VALUE' is not defined, `FUNCTION_VALUE'
+     serves both purposes.
+
+     `FUNCTION_OUTGOING_VALUE' is not used for return vales with
+     aggregate data types, because these are returned in another way.
+     See `STRUCT_VALUE_REGNUM' and related macros, below.
+
+`LIBCALL_VALUE (MODE)'
+     A C expression to create an RTX representing the place where a
+     library function returns a value of mode MODE.  If the precise
+     function being called is known, FUNC is a tree node
+     (`FUNCTION_DECL') for it; otherwise, FUNC is a null pointer.  This
+     makes it possible to use a different value-returning convention
+     for specific functions when all their calls are known.
+
+     Note that "library function" in this context means a compiler
+     support routine, used to perform arithmetic, whose name is known
+     specially by the compiler and was not mentioned in the C code being
+     compiled.
+
+     The definition of `LIBRARY_VALUE' need not be concerned aggregate
+     data types, because none of the library functions returns such
+     types.
+
+`FUNCTION_VALUE_REGNO_P (REGNO)'
+     A C expression that is nonzero if REGNO is the number of a hard
+     register in which the values of called function may come back.
+
+     A register whose use for returning values is limited to serving as
+     the second of a pair (for a value of type `double', say) need not
+     be recognized by this macro.  So for most machines, this definition
+     suffices:
+
+          #define FUNCTION_VALUE_REGNO_P(N) ((N) == 0)
+
+     If the machine has register windows, so that the caller and the
+     called function use different registers for the return value, this
+     macro should recognize only the caller's register numbers.
+
+`APPLY_RESULT_SIZE'
+     Define this macro if `untyped_call' and `untyped_return' need more
+     space than is implied by `FUNCTION_VALUE_REGNO_P' for saving and
+     restoring an arbitrary return value.
+
+
+File: gcc.info,  Node: Aggregate Return,  Next: Caller Saves,  Prev: Scalar Return,  Up: Stack and Calling
+
+How Large Values Are Returned
+-----------------------------
+
+   When a function value's mode is `BLKmode' (and in some other cases),
+the value is not returned according to `FUNCTION_VALUE' (*note Scalar
+Return::.).  Instead, the caller passes the address of a block of
+memory in which the value should be stored.  This address is called the
+"structure value address".
+
+   This section describes how to control returning structure values in
+memory.
+
+`RETURN_IN_MEMORY (TYPE)'
+     A C expression which can inhibit the returning of certain function
+     values in registers, based on the type of value.  A nonzero value
+     says to return the function value in memory, just as large
+     structures are always returned.  Here TYPE will be a C expression
+     of type `tree', representing the data type of the value.
+
+     Note that values of mode `BLKmode' must be explicitly handled by
+     this macro.  Also, the option `-fpcc-struct-return' takes effect
+     regardless of this macro.  On most systems, it is possible to
+     leave the macro undefined; this causes a default definition to be
+     used, whose value is the constant 1 for `BLKmode' values, and 0
+     otherwise.
+
+     Do not use this macro to indicate that structures and unions
+     should always be returned in memory.  You should instead use
+     `DEFAULT_PCC_STRUCT_RETURN' to indicate this.
+
+`DEFAULT_PCC_STRUCT_RETURN'
+     Define this macro to be 1 if all structure and union return values
+     must be in memory.  Since this results in slower code, this should
+     be defined only if needed for compatibility with other compilers
+     or with an ABI.  If you define this macro to be 0, then the
+     conventions used for structure and union return values are decided
+     by the `RETURN_IN_MEMORY' macro.
+
+     If not defined, this defaults to the value 1.
+
+`STRUCT_VALUE_REGNUM'
+     If the structure value address is passed in a register, then
+     `STRUCT_VALUE_REGNUM' should be the number of that register.
+
+`STRUCT_VALUE'
+     If the structure value address is not passed in a register, define
+     `STRUCT_VALUE' as an expression returning an RTX for the place
+     where the address is passed.  If it returns 0, the address is
+     passed as an "invisible" first argument.
+
+`STRUCT_VALUE_INCOMING_REGNUM'
+     On some architectures the place where the structure value address
+     is found by the called function is not the same place that the
+     caller put it.  This can be due to register windows, or it could
+     be because the function prologue moves it to a different place.
+
+     If the incoming location of the structure value address is in a
+     register, define this macro as the register number.
+
+`STRUCT_VALUE_INCOMING'
+     If the incoming location is not a register, then you should define
+     `STRUCT_VALUE_INCOMING' as an expression for an RTX for where the
+     called function should find the value.  If it should find the
+     value on the stack, define this to create a `mem' which refers to
+     the frame pointer.  A definition of 0 means that the address is
+     passed as an "invisible" first argument.
+
+`PCC_STATIC_STRUCT_RETURN'
+     Define this macro if the usual system convention on the target
+     machine for returning structures and unions is for the called
+     function to return the address of a static variable containing the
+     value.
+
+     Do not define this if the usual system convention is for the
+     caller to pass an address to the subroutine.
+
+     This macro has effect in `-fpcc-struct-return' mode, but it does
+     nothing when you use `-freg-struct-return' mode.
+
+
+File: gcc.info,  Node: Caller Saves,  Next: Function Entry,  Prev: Aggregate Return,  Up: Stack and Calling
+
+Caller-Saves Register Allocation
+--------------------------------
+
+   If you enable it, GNU CC can save registers around function calls.
+This makes it possible to use call-clobbered registers to hold
+variables that must live across calls.
+
+`DEFAULT_CALLER_SAVES'
+     Define this macro if function calls on the target machine do not
+     preserve any registers; in other words, if `CALL_USED_REGISTERS'
+     has 1 for all registers.  When defined, this macro enables
+     `-fcaller-saves' by default for all optimization levels.  It has
+     no effect for optimization levels 2 and higher, where
+     `-fcaller-saves' is the default.
+
+`CALLER_SAVE_PROFITABLE (REFS, CALLS)'
+     A C expression to determine whether it is worthwhile to consider
+     placing a pseudo-register in a call-clobbered hard register and
+     saving and restoring it around each function call.  The expression
+     should be 1 when this is worth doing, and 0 otherwise.
+
+     If you don't define this macro, a default is used which is good on
+     most machines: `4 * CALLS < REFS'.
+
+`HARD_REGNO_CALLER_SAVE_MODE (REGNO, NREGS)'
+     A C expression specifying which mode is required for saving NREGS
+     of a pseudo-register in call-clobbered hard register REGNO.  If
+     REGNO is unsuitable for caller save, `VOIDmode' should be
+     returned.  For most machines this macro need not be defined since
+     GCC will select the smallest suitable mode.
+
+
+File: gcc.info,  Node: Function Entry,  Next: Profiling,  Prev: Caller Saves,  Up: Stack and Calling
+
+Function Entry and Exit
+-----------------------
+
+   This section describes the macros that output function entry
+("prologue") and exit ("epilogue") code.
+
+`FUNCTION_PROLOGUE (FILE, SIZE)'
+     A C compound statement that outputs the assembler code for entry
+     to a function.  The prologue is responsible for setting up the
+     stack frame, initializing the frame pointer register, saving
+     registers that must be saved, and allocating SIZE additional bytes
+     of storage for the local variables.  SIZE is an integer.  FILE is
+     a stdio stream to which the assembler code should be output.
+
+     The label for the beginning of the function need not be output by
+     this macro.  That has already been done when the macro is run.
+
+     To determine which registers to save, the macro can refer to the
+     array `regs_ever_live': element R is nonzero if hard register R is
+     used anywhere within the function.  This implies the function
+     prologue should save register R, provided it is not one of the
+     call-used registers.  (`FUNCTION_EPILOGUE' must likewise use
+     `regs_ever_live'.)
+
+     On machines that have "register windows", the function entry code
+     does not save on the stack the registers that are in the windows,
+     even if they are supposed to be preserved by function calls;
+     instead it takes appropriate steps to "push" the register stack,
+     if any non-call-used registers are used in the function.
+
+     On machines where functions may or may not have frame-pointers, the
+     function entry code must vary accordingly; it must set up the frame
+     pointer if one is wanted, and not otherwise.  To determine whether
+     a frame pointer is in wanted, the macro can refer to the variable
+     `frame_pointer_needed'.  The variable's value will be 1 at run
+     time in a function that needs a frame pointer.  *Note
+     Elimination::.
+
+     The function entry code is responsible for allocating any stack
+     space required for the function.  This stack space consists of the
+     regions listed below.  In most cases, these regions are allocated
+     in the order listed, with the last listed region closest to the
+     top of the stack (the lowest address if `STACK_GROWS_DOWNWARD' is
+     defined, and the highest address if it is not defined).  You can
+     use a different order for a machine if doing so is more convenient
+     or required for compatibility reasons.  Except in cases where
+     required by standard or by a debugger, there is no reason why the
+     stack layout used by GCC need agree with that used by other
+     compilers for a machine.
+
+        * A region of `current_function_pretend_args_size' bytes of
+          uninitialized space just underneath the first argument
+          arriving on the stack.  (This may not be at the very start of
+          the allocated stack region if the calling sequence has pushed
+          anything else since pushing the stack arguments.  But
+          usually, on such machines, nothing else has been pushed yet,
+          because the function prologue itself does all the pushing.)
+          This region is used on machines where an argument may be
+          passed partly in registers and partly in memory, and, in some
+          cases to support the features in `varargs.h' and `stdargs.h'.
+
+        * An area of memory used to save certain registers used by the
+          function.  The size of this area, which may also include
+          space for such things as the return address and pointers to
+          previous stack frames, is machine-specific and usually
+          depends on which registers have been used in the function.
+          Machines with register windows often do not require a save
+          area.
+
+        * A region of at least SIZE bytes, possibly rounded up to an
+          allocation boundary, to contain the local variables of the
+          function.  On some machines, this region and the save area
+          may occur in the opposite order, with the save area closer to
+          the top of the stack.
+
+        * Optionally, when `ACCUMULATE_OUTGOING_ARGS' is defined, a
+          region of `current_function_outgoing_args_size' bytes to be
+          used for outgoing argument lists of the function.  *Note
+          Stack Arguments::.
+
+     Normally, it is necessary for the macros `FUNCTION_PROLOGUE' and
+     `FUNCTION_EPILOGUE' to treat leaf functions specially.  The C
+     variable `current_function_is_leaf' is nonzero for such a function.
+
+`EXIT_IGNORE_STACK'
+     Define this macro as a C expression that is nonzero if the return
+     instruction or the function epilogue ignores the value of the stack
+     pointer; in other words, if it is safe to delete an instruction to
+     adjust the stack pointer before a return from the function.
+
+     Note that this macro's value is relevant only for functions for
+     which frame pointers are maintained.  It is never safe to delete a
+     final stack adjustment in a function that has no frame pointer,
+     and the compiler knows this regardless of `EXIT_IGNORE_STACK'.
+
+`EPILOGUE_USES (REGNO)'
+     Define this macro as a C expression that is nonzero for registers
+     are used by the epilogue or the `return' pattern.  The stack and
+     frame pointer registers are already be assumed to be used as
+     needed.
+
+`FUNCTION_EPILOGUE (FILE, SIZE)'
+     A C compound statement that outputs the assembler code for exit
+     from a function.  The epilogue is responsible for restoring the
+     saved registers and stack pointer to their values when the
+     function was called, and returning control to the caller.  This
+     macro takes the same arguments as the macro `FUNCTION_PROLOGUE',
+     and the registers to restore are determined from `regs_ever_live'
+     and `CALL_USED_REGISTERS' in the same way.
+
+     On some machines, there is a single instruction that does all the
+     work of returning from the function.  On these machines, give that
+     instruction the name `return' and do not define the macro
+     `FUNCTION_EPILOGUE' at all.
+
+     Do not define a pattern named `return' if you want the
+     `FUNCTION_EPILOGUE' to be used.  If you want the target switches
+     to control whether return instructions or epilogues are used,
+     define a `return' pattern with a validity condition that tests the
+     target switches appropriately.  If the `return' pattern's validity
+     condition is false, epilogues will be used.
+
+     On machines where functions may or may not have frame-pointers, the
+     function exit code must vary accordingly.  Sometimes the code for
+     these two cases is completely different.  To determine whether a
+     frame pointer is wanted, the macro can refer to the variable
+     `frame_pointer_needed'.  The variable's value will be 1 when
+     compiling a function that needs a frame pointer.
+
+     Normally, `FUNCTION_PROLOGUE' and `FUNCTION_EPILOGUE' must treat
+     leaf functions specially.  The C variable
+     `current_function_is_leaf' is nonzero for such a function.  *Note
+     Leaf Functions::.
+
+     On some machines, some functions pop their arguments on exit while
+     others leave that for the caller to do.  For example, the 68020
+     when given `-mrtd' pops arguments in functions that take a fixed
+     number of arguments.
+
+     Your definition of the macro `RETURN_POPS_ARGS' decides which
+     functions pop their own arguments.  `FUNCTION_EPILOGUE' needs to
+     know what was decided.  The variable that is called
+     `current_function_pops_args' is the number of bytes of its
+     arguments that a function should pop.  *Note Scalar Return::.
+
+`DELAY_SLOTS_FOR_EPILOGUE'
+     Define this macro if the function epilogue contains delay slots to
+     which instructions from the rest of the function can be "moved".
+     The definition should be a C expression whose value is an integer
+     representing the number of delay slots there.
+
+`ELIGIBLE_FOR_EPILOGUE_DELAY (INSN, N)'
+     A C expression that returns 1 if INSN can be placed in delay slot
+     number N of the epilogue.
+
+     The argument N is an integer which identifies the delay slot now
+     being considered (since different slots may have different rules of
+     eligibility).  It is never negative and is always less than the
+     number of epilogue delay slots (what `DELAY_SLOTS_FOR_EPILOGUE'
+     returns).  If you reject a particular insn for a given delay slot,
+     in principle, it may be reconsidered for a subsequent delay slot.
+     Also, other insns may (at least in principle) be considered for
+     the so far unfilled delay slot.
+
+     The insns accepted to fill the epilogue delay slots are put in an
+     RTL list made with `insn_list' objects, stored in the variable
+     `current_function_epilogue_delay_list'.  The insn for the first
+     delay slot comes first in the list.  Your definition of the macro
+     `FUNCTION_EPILOGUE' should fill the delay slots by outputting the
+     insns in this list, usually by calling `final_scan_insn'.
+
+     You need not define this macro if you did not define
+     `DELAY_SLOTS_FOR_EPILOGUE'.
+
+`ASM_OUTPUT_MI_THUNK (FILE, THUNK_FNDECL, DELTA, FUNCTION)'
+     A C compound statement that outputs the assembler code for a thunk
+     function, used to implement C++ virtual function calls with
+     multiple inheritance.  The thunk acts as a wrapper around a
+     virtual function, adjusting the implicit object parameter before
+     handing control off to the real function.
+
+     First, emit code to add the integer DELTA to the location that
+     contains the incoming first argument.  Assume that this argument
+     contains a pointer, and is the one used to pass the `this' pointer
+     in C++.  This is the incoming argument *before* the function
+     prologue, e.g. `%o0' on a sparc.  The addition must preserve the
+     values of all other incoming arguments.
+
+     After the addition, emit code to jump to FUNCTION, which is a
+     `FUNCTION_DECL'.  This is a direct pure jump, not a call, and does
+     not touch the return address.  Hence returning from FUNCTION will
+     return to whoever called the current `thunk'.
+
+     The effect must be as if FUNCTION had been called directly with
+     the adjusted first argument.  This macro is responsible for
+     emitting all of the code for a thunk function; `FUNCTION_PROLOGUE'
+     and `FUNCTION_EPILOGUE' are not invoked.
+
+     The THUNK_FNDECL is redundant.  (DELTA and FUNCTION have already
+     been extracted from it.)  It might possibly be useful on some
+     targets, but probably not.
+
+     If you do not define this macro, the target-independent code in
+     the C++ frontend will generate a less efficient heavyweight thunk
+     that calls FUNCTION instead of jumping to it.  The generic
+     approach does not support varargs.
+
+
+File: gcc.info,  Node: Profiling,  Prev: Function Entry,  Up: Stack and Calling
+
+Generating Code for Profiling
+-----------------------------
+
+   These macros will help you generate code for profiling.
+
+`FUNCTION_PROFILER (FILE, LABELNO)'
+     A C statement or compound statement to output to FILE some
+     assembler code to call the profiling subroutine `mcount'.  Before
+     calling, the assembler code must load the address of a counter
+     variable into a register where `mcount' expects to find the
+     address.  The name of this variable is `LP' followed by the number
+     LABELNO, so you would generate the name using `LP%d' in a
+     `fprintf'.
+
+     The details of how the address should be passed to `mcount' are
+     determined by your operating system environment, not by GNU CC.  To
+     figure them out, compile a small program for profiling using the
+     system's installed C compiler and look at the assembler code that
+     results.
+
+`PROFILE_BEFORE_PROLOGUE'
+     Define this macro if the code for function profiling should come
+     before the function prologue.  Normally, the profiling code comes
+     after.
+
+`FUNCTION_BLOCK_PROFILER (FILE, LABELNO)'
+     A C statement or compound statement to output to FILE some
+     assembler code to initialize basic-block profiling for the current
+     object module.  The global compile flag `profile_block_flag'
+     distinguishes two profile modes.
+
+    `profile_block_flag != 2'
+          Output code to call the subroutine `__bb_init_func' once per
+          object module, passing it as its sole argument the address of
+          a block allocated in the object module.
+
+          The name of the block is a local symbol made with this
+          statement:
+
+               ASM_GENERATE_INTERNAL_LABEL (BUFFER, "LPBX", 0);
+
+          Of course, since you are writing the definition of
+          `ASM_GENERATE_INTERNAL_LABEL' as well as that of this macro,
+          you can take a short cut in the definition of this macro and
+          use the name that you know will result.
+
+          The first word of this block is a flag which will be nonzero
+          if the object module has already been initialized.  So test
+          this word first, and do not call `__bb_init_func' if the flag
+          is nonzero.  BLOCK_OR_LABEL contains a unique number which
+          may be used to generate a label as a branch destination when
+          `__bb_init_func' will not be called.
+
+          Described in assembler language, the code to be output looks
+          like:
+
+                 cmp (LPBX0),0
+                 bne local_label
+                 parameter1 <- LPBX0
+                 call __bb_init_func
+               local_label:
+
+    `profile_block_flag == 2'
+          Output code to call the subroutine `__bb_init_trace_func' and
+          pass two parameters to it.  The first parameter is the same as
+          for `__bb_init_func'.  The second parameter is the number of
+          the first basic block of the function as given by
+          BLOCK_OR_LABEL.  Note that `__bb_init_trace_func' has to be
+          called, even if the object module has been initialized
+          already.
+
+          Described in assembler language, the code to be output looks
+          like:
+               parameter1 <- LPBX0
+               parameter2 <- BLOCK_OR_LABEL
+               call __bb_init_trace_func
+
+`BLOCK_PROFILER (FILE, BLOCKNO)'
+     A C statement or compound statement to output to FILE some
+     assembler code to increment the count associated with the basic
+     block number BLOCKNO.  The global compile flag
+     `profile_block_flag' distinguishes two profile modes.
+
+    `profile_block_flag != 2'
+          Output code to increment the counter directly.  Basic blocks
+          are numbered separately from zero within each compilation.
+          The count associated with block number BLOCKNO is at index
+          BLOCKNO in a vector of words; the name of this array is a
+          local symbol made with this statement:
+
+               ASM_GENERATE_INTERNAL_LABEL (BUFFER, "LPBX", 2);
+
+          Of course, since you are writing the definition of
+          `ASM_GENERATE_INTERNAL_LABEL' as well as that of this macro,
+          you can take a short cut in the definition of this macro and
+          use the name that you know will result.
+
+          Described in assembler language, the code to be output looks
+          like:
+
+               inc (LPBX2+4*BLOCKNO)
+
+    `profile_block_flag == 2'
+          Output code to initialize the global structure `__bb' and
+          call the function `__bb_trace_func', which will increment the
+          counter.
+
+          `__bb' consists of two words.  In the first word, the current
+          basic block number, as given by BLOCKNO, has to be stored.  In
+          the second word, the address of a block allocated in the
+          object module has to be stored.  The address is given by the
+          label created with this statement:
+
+               ASM_GENERATE_INTERNAL_LABEL (BUFFER, "LPBX", 0);
+
+          Described in assembler language, the code to be output looks
+          like:
+               move BLOCKNO -> (__bb)
+               move LPBX0 -> (__bb+4)
+               call __bb_trace_func
+
+`FUNCTION_BLOCK_PROFILER_EXIT (FILE)'
+     A C statement or compound statement to output to FILE assembler
+     code to call function `__bb_trace_ret'.  The assembler code should
+     only be output if the global compile flag `profile_block_flag' ==
+     2.  This macro has to be used at every place where code for
+     returning from a function is generated (e.g. `FUNCTION_EPILOGUE').
+     Although you have to write the definition of `FUNCTION_EPILOGUE'
+     as well, you have to define this macro to tell the compiler, that
+     the proper call to `__bb_trace_ret' is produced.
+
+`MACHINE_STATE_SAVE (ID)'
+     A C statement or compound statement to save all registers, which
+     may be clobbered by a function call, including condition codes.
+     The `asm' statement will be mostly likely needed to handle this
+     task.  Local labels in the assembler code can be concatenated with
+     the string ID, to obtain a unique lable name.
+
+     Registers or condition codes clobbered by `FUNCTION_PROLOGUE' or
+     `FUNCTION_EPILOGUE' must be saved in the macros
+     `FUNCTION_BLOCK_PROFILER', `FUNCTION_BLOCK_PROFILER_EXIT' and
+     `BLOCK_PROFILER' prior calling `__bb_init_trace_func',
+     `__bb_trace_ret' and `__bb_trace_func' respectively.
+
+`MACHINE_STATE_RESTORE (ID)'
+     A C statement or compound statement to restore all registers,
+     including condition codes, saved by `MACHINE_STATE_SAVE'.
+
+     Registers or condition codes clobbered by `FUNCTION_PROLOGUE' or
+     `FUNCTION_EPILOGUE' must be restored in the macros
+     `FUNCTION_BLOCK_PROFILER', `FUNCTION_BLOCK_PROFILER_EXIT' and
+     `BLOCK_PROFILER' after calling `__bb_init_trace_func',
+     `__bb_trace_ret' and `__bb_trace_func' respectively.
+
+`BLOCK_PROFILER_CODE'
+     A C function or functions which are needed in the library to
+     support block profiling.
+
+
+File: gcc.info,  Node: Varargs,  Next: Trampolines,  Prev: Stack and Calling,  Up: Target Macros
+
+Implementing the Varargs Macros
+===============================
+
+   GNU CC comes with an implementation of `varargs.h' and `stdarg.h'
+that work without change on machines that pass arguments on the stack.
+Other machines require their own implementations of varargs, and the
+two machine independent header files must have conditionals to include
+it.
+
+   ANSI `stdarg.h' differs from traditional `varargs.h' mainly in the
+calling convention for `va_start'.  The traditional implementation
+takes just one argument, which is the variable in which to store the
+argument pointer.  The ANSI implementation of `va_start' takes an
+additional second argument.  The user is supposed to write the last
+named argument of the function here.
+
+   However, `va_start' should not use this argument.  The way to find
+the end of the named arguments is with the built-in functions described
+below.
+
+`__builtin_saveregs ()'
+     Use this built-in function to save the argument registers in
+     memory so that the varargs mechanism can access them.  Both ANSI
+     and traditional versions of `va_start' must use
+     `__builtin_saveregs', unless you use `SETUP_INCOMING_VARARGS' (see
+     below) instead.
+
+     On some machines, `__builtin_saveregs' is open-coded under the
+     control of the macro `EXPAND_BUILTIN_SAVEREGS'.  On other machines,
+     it calls a routine written in assembler language, found in
+     `libgcc2.c'.
+
+     Code generated for the call to `__builtin_saveregs' appears at the
+     beginning of the function, as opposed to where the call to
+     `__builtin_saveregs' is written, regardless of what the code is.
+     This is because the registers must be saved before the function
+     starts to use them for its own purposes.
+
+`__builtin_args_info (CATEGORY)'
+     Use this built-in function to find the first anonymous arguments in
+     registers.
+
+     In general, a machine may have several categories of registers
+     used for arguments, each for a particular category of data types.
+     (For example, on some machines, floating-point registers are used
+     for floating-point arguments while other arguments are passed in
+     the general registers.)  To make non-varargs functions use the
+     proper calling convention, you have defined the `CUMULATIVE_ARGS'
+     data type to record how many registers in each category have been
+     used so far
+
+     `__builtin_args_info' accesses the same data structure of type
+     `CUMULATIVE_ARGS' after the ordinary argument layout is finished
+     with it, with CATEGORY specifying which word to access.  Thus, the
+     value indicates the first unused register in a given category.
+
+     Normally, you would use `__builtin_args_info' in the implementation
+     of `va_start', accessing each category just once and storing the
+     value in the `va_list' object.  This is because `va_list' will
+     have to update the values, and there is no way to alter the values
+     accessed by `__builtin_args_info'.
+
+`__builtin_next_arg (LASTARG)'
+     This is the equivalent of `__builtin_args_info', for stack
+     arguments.  It returns the address of the first anonymous stack
+     argument, as type `void *'. If `ARGS_GROW_DOWNWARD', it returns
+     the address of the location above the first anonymous stack
+     argument.  Use it in `va_start' to initialize the pointer for
+     fetching arguments from the stack.  Also use it in `va_start' to
+     verify that the second parameter LASTARG is the last named argument
+     of the current function.
+
+`__builtin_classify_type (OBJECT)'
+     Since each machine has its own conventions for which data types are
+     passed in which kind of register, your implementation of `va_arg'
+     has to embody these conventions.  The easiest way to categorize the
+     specified data type is to use `__builtin_classify_type' together
+     with `sizeof' and `__alignof__'.
+
+     `__builtin_classify_type' ignores the value of OBJECT, considering
+     only its data type.  It returns an integer describing what kind of
+     type that is--integer, floating, pointer, structure, and so on.
+
+     The file `typeclass.h' defines an enumeration that you can use to
+     interpret the values of `__builtin_classify_type'.
+
+   These machine description macros help implement varargs:
+
+`EXPAND_BUILTIN_SAVEREGS (ARGS)'
+     If defined, is a C expression that produces the machine-specific
+     code for a call to `__builtin_saveregs'.  This code will be moved
+     to the very beginning of the function, before any parameter access
+     are made.  The return value of this function should be an RTX that
+     contains the value to use as the return of `__builtin_saveregs'.
+
+     The argument ARGS is a `tree_list' containing the arguments that
+     were passed to `__builtin_saveregs'.
+
+     If this macro is not defined, the compiler will output an ordinary
+     call to the library function `__builtin_saveregs'.
+
+`SETUP_INCOMING_VARARGS (ARGS_SO_FAR, MODE, TYPE, PRETEND_ARGS_SIZE, SECOND_TIME)'
+     This macro offers an alternative to using `__builtin_saveregs' and
+     defining the macro `EXPAND_BUILTIN_SAVEREGS'.  Use it to store the
+     anonymous register arguments into the stack so that all the
+     arguments appear to have been passed consecutively on the stack.
+     Once this is done, you can use the standard implementation of
+     varargs that works for machines that pass all their arguments on
+     the stack.
+
+     The argument ARGS_SO_FAR is the `CUMULATIVE_ARGS' data structure,
+     containing the values that obtain after processing of the named
+     arguments.  The arguments MODE and TYPE describe the last named
+     argument--its machine mode and its data type as a tree node.
+
+     The macro implementation should do two things: first, push onto the
+     stack all the argument registers *not* used for the named
+     arguments, and second, store the size of the data thus pushed into
+     the `int'-valued variable whose name is supplied as the argument
+     PRETEND_ARGS_SIZE.  The value that you store here will serve as
+     additional offset for setting up the stack frame.
+
+     Because you must generate code to push the anonymous arguments at
+     compile time without knowing their data types,
+     `SETUP_INCOMING_VARARGS' is only useful on machines that have just
+     a single category of argument register and use it uniformly for
+     all data types.
+
+     If the argument SECOND_TIME is nonzero, it means that the
+     arguments of the function are being analyzed for the second time.
+     This happens for an inline function, which is not actually
+     compiled until the end of the source file.  The macro
+     `SETUP_INCOMING_VARARGS' should not generate any instructions in
+     this case.
+
+`STRICT_ARGUMENT_NAMING'
+     Define this macro to be a nonzero value if the location where a
+     function argument is passed depends on whether or not it is a
+     named argument.
+
+     This macro controls how the NAMED argument to `FUNCTION_ARG' is
+     set for varargs and stdarg functions.  If this macro returns a
+     nonzero value, the NAMED argument is always true for named
+     arguments, and false for unnamed arguments.  If it returns a value
+     of zero, but `SETUP_INCOMING_VARARGS' is defined, then all
+     arguments are treated as named.  Otherwise, all named arguments
+     except the last are treated as named.
+
+     You need not define this macro if it always returns zero.
+
+`PRETEND_OUTGOING_VARARGS_NAMED'
+     If you need to conditionally change ABIs so that one works with
+     `SETUP_INCOMING_VARARGS', but the other works like neither
+     `SETUP_INCOMING_VARARGS' nor `STRICT_ARGUMENT_NAMING' was defined,
+     then define this macro to return nonzero if
+     `SETUP_INCOMING_VARARGS' is used, zero otherwise.  Otherwise, you
+     should not define this macro.
+

usr/local/nachos/info/gcc.info-25

@@ -0,0 +1,980 @@
+This is Info file gcc.info, produced by Makeinfo version 1.68 from the
+input file ../../gcc-2.95.2/gcc/gcc.texi.
+
+INFO-DIR-SECTION Programming
+START-INFO-DIR-ENTRY
+* gcc: (gcc).                  The GNU Compiler Collection.
+END-INFO-DIR-ENTRY
+   This file documents the use and the internals of the GNU compiler.
+
+   Published by the Free Software Foundation 59 Temple Place - Suite 330
+Boston, MA 02111-1307 USA
+
+   Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
+1999 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 sections entitled "GNU General Public License" and "Funding
+for Free Software" are included exactly as in the original, and
+provided 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, except that the sections entitled "GNU General Public
+License" and "Funding for Free Software", and this permission notice,
+may be included in translations approved by the Free Software Foundation
+instead of in the original English.
+
+
+File: gcc.info,  Node: Trampolines,  Next: Library Calls,  Prev: Varargs,  Up: Target Macros
+
+Trampolines for Nested Functions
+================================
+
+   A "trampoline" is a small piece of code that is created at run time
+when the address of a nested function is taken.  It normally resides on
+the stack, in the stack frame of the containing function.  These macros
+tell GNU CC how to generate code to allocate and initialize a
+trampoline.
+
+   The instructions in the trampoline must do two things: load a
+constant address into the static chain register, and jump to the real
+address of the nested function.  On CISC machines such as the m68k,
+this requires two instructions, a move immediate and a jump.  Then the
+two addresses exist in the trampoline as word-long immediate operands.
+On RISC machines, it is often necessary to load each address into a
+register in two parts.  Then pieces of each address form separate
+immediate operands.
+
+   The code generated to initialize the trampoline must store the
+variable parts--the static chain value and the function address--into
+the immediate operands of the instructions.  On a CISC machine, this is
+simply a matter of copying each address to a memory reference at the
+proper offset from the start of the trampoline.  On a RISC machine, it
+may be necessary to take out pieces of the address and store them
+separately.
+
+`TRAMPOLINE_TEMPLATE (FILE)'
+     A C statement to output, on the stream FILE, assembler code for a
+     block of data that contains the constant parts of a trampoline.
+     This code should not include a label--the label is taken care of
+     automatically.
+
+     If you do not define this macro, it means no template is needed
+     for the target.  Do not define this macro on systems where the
+     block move code to copy the trampoline into place would be larger
+     than the code to generate it on the spot.
+
+`TRAMPOLINE_SECTION'
+     The name of a subroutine to switch to the section in which the
+     trampoline template is to be placed (*note Sections::.).  The
+     default is a value of `readonly_data_section', which places the
+     trampoline in the section containing read-only data.
+
+`TRAMPOLINE_SIZE'
+     A C expression for the size in bytes of the trampoline, as an
+     integer.
+
+`TRAMPOLINE_ALIGNMENT'
+     Alignment required for trampolines, in bits.
+
+     If you don't define this macro, the value of `BIGGEST_ALIGNMENT'
+     is used for aligning trampolines.
+
+`INITIALIZE_TRAMPOLINE (ADDR, FNADDR, STATIC_CHAIN)'
+     A C statement to initialize the variable parts of a trampoline.
+     ADDR is an RTX for the address of the trampoline; FNADDR is an RTX
+     for the address of the nested function; STATIC_CHAIN is an RTX for
+     the static chain value that should be passed to the function when
+     it is called.
+
+`ALLOCATE_TRAMPOLINE (FP)'
+     A C expression to allocate run-time space for a trampoline.  The
+     expression value should be an RTX representing a memory reference
+     to the space for the trampoline.
+
+     If this macro is not defined, by default the trampoline is
+     allocated as a stack slot.  This default is right for most
+     machines.  The exceptions are machines where it is impossible to
+     execute instructions in the stack area.  On such machines, you may
+     have to implement a separate stack, using this macro in
+     conjunction with `FUNCTION_PROLOGUE' and `FUNCTION_EPILOGUE'.
+
+     FP points to a data structure, a `struct function', which
+     describes the compilation status of the immediate containing
+     function of the function which the trampoline is for.  Normally
+     (when `ALLOCATE_TRAMPOLINE' is not defined), the stack slot for the
+     trampoline is in the stack frame of this containing function.
+     Other allocation strategies probably must do something analogous
+     with this information.
+
+   Implementing trampolines is difficult on many machines because they
+have separate instruction and data caches.  Writing into a stack
+location fails to clear the memory in the instruction cache, so when
+the program jumps to that location, it executes the old contents.
+
+   Here are two possible solutions.  One is to clear the relevant parts
+of the instruction cache whenever a trampoline is set up.  The other is
+to make all trampolines identical, by having them jump to a standard
+subroutine.  The former technique makes trampoline execution faster; the
+latter makes initialization faster.
+
+   To clear the instruction cache when a trampoline is initialized,
+define the following macros which describe the shape of the cache.
+
+`INSN_CACHE_SIZE'
+     The total size in bytes of the cache.
+
+`INSN_CACHE_LINE_WIDTH'
+     The length in bytes of each cache line.  The cache is divided into
+     cache lines which are disjoint slots, each holding a contiguous
+     chunk of data fetched from memory.  Each time data is brought into
+     the cache, an entire line is read at once.  The data loaded into a
+     cache line is always aligned on a boundary equal to the line size.
+
+`INSN_CACHE_DEPTH'
+     The number of alternative cache lines that can hold any particular
+     memory location.
+
+   Alternatively, if the machine has system calls or instructions to
+clear the instruction cache directly, you can define the following
+macro.
+
+`CLEAR_INSN_CACHE (BEG, END)'
+     If defined, expands to a C expression clearing the *instruction
+     cache* in the specified interval.  If it is not defined, and the
+     macro INSN_CACHE_SIZE is defined, some generic code is generated
+     to clear the cache.  The definition of this macro would typically
+     be a series of `asm' statements.  Both BEG and END are both pointer
+     expressions.
+
+   To use a standard subroutine, define the following macro.  In
+addition, you must make sure that the instructions in a trampoline fill
+an entire cache line with identical instructions, or else ensure that
+the beginning of the trampoline code is always aligned at the same
+point in its cache line.  Look in `m68k.h' as a guide.
+
+`TRANSFER_FROM_TRAMPOLINE'
+     Define this macro if trampolines need a special subroutine to do
+     their work.  The macro should expand to a series of `asm'
+     statements which will be compiled with GNU CC.  They go in a
+     library function named `__transfer_from_trampoline'.
+
+     If you need to avoid executing the ordinary prologue code of a
+     compiled C function when you jump to the subroutine, you can do so
+     by placing a special label of your own in the assembler code.  Use
+     one `asm' statement to generate an assembler label, and another to
+     make the label global.  Then trampolines can use that label to
+     jump directly to your special assembler code.
+
+
+File: gcc.info,  Node: Library Calls,  Next: Addressing Modes,  Prev: Trampolines,  Up: Target Macros
+
+Implicit Calls to Library Routines
+==================================
+
+   Here is an explanation of implicit calls to library routines.
+
+`MULSI3_LIBCALL'
+     A C string constant giving the name of the function to call for
+     multiplication of one signed full-word by another.  If you do not
+     define this macro, the default name is used, which is `__mulsi3',
+     a function defined in `libgcc.a'.
+
+`DIVSI3_LIBCALL'
+     A C string constant giving the name of the function to call for
+     division of one signed full-word by another.  If you do not define
+     this macro, the default name is used, which is `__divsi3', a
+     function defined in `libgcc.a'.
+
+`UDIVSI3_LIBCALL'
+     A C string constant giving the name of the function to call for
+     division of one unsigned full-word by another.  If you do not
+     define this macro, the default name is used, which is `__udivsi3',
+     a function defined in `libgcc.a'.
+
+`MODSI3_LIBCALL'
+     A C string constant giving the name of the function to call for the
+     remainder in division of one signed full-word by another.  If you
+     do not define this macro, the default name is used, which is
+     `__modsi3', a function defined in `libgcc.a'.
+
+`UMODSI3_LIBCALL'
+     A C string constant giving the name of the function to call for the
+     remainder in division of one unsigned full-word by another.  If
+     you do not define this macro, the default name is used, which is
+     `__umodsi3', a function defined in `libgcc.a'.
+
+`MULDI3_LIBCALL'
+     A C string constant giving the name of the function to call for
+     multiplication of one signed double-word by another.  If you do not
+     define this macro, the default name is used, which is `__muldi3',
+     a function defined in `libgcc.a'.
+
+`DIVDI3_LIBCALL'
+     A C string constant giving the name of the function to call for
+     division of one signed double-word by another.  If you do not
+     define this macro, the default name is used, which is `__divdi3', a
+     function defined in `libgcc.a'.
+
+`UDIVDI3_LIBCALL'
+     A C string constant giving the name of the function to call for
+     division of one unsigned full-word by another.  If you do not
+     define this macro, the default name is used, which is `__udivdi3',
+     a function defined in `libgcc.a'.
+
+`MODDI3_LIBCALL'
+     A C string constant giving the name of the function to call for the
+     remainder in division of one signed double-word by another.  If
+     you do not define this macro, the default name is used, which is
+     `__moddi3', a function defined in `libgcc.a'.
+
+`UMODDI3_LIBCALL'
+     A C string constant giving the name of the function to call for the
+     remainder in division of one unsigned full-word by another.  If
+     you do not define this macro, the default name is used, which is
+     `__umoddi3', a function defined in `libgcc.a'.
+
+`INIT_TARGET_OPTABS'
+     Define this macro as a C statement that declares additional library
+     routines renames existing ones. `init_optabs' calls this macro
+     after initializing all the normal library routines.
+
+`TARGET_EDOM'
+     The value of `EDOM' on the target machine, as a C integer constant
+     expression.  If you don't define this macro, GNU CC does not
+     attempt to deposit the value of `EDOM' into `errno' directly.
+     Look in `/usr/include/errno.h' to find the value of `EDOM' on your
+     system.
+
+     If you do not define `TARGET_EDOM', then compiled code reports
+     domain errors by calling the library function and letting it
+     report the error.  If mathematical functions on your system use
+     `matherr' when there is an error, then you should leave
+     `TARGET_EDOM' undefined so that `matherr' is used normally.
+
+`GEN_ERRNO_RTX'
+     Define this macro as a C expression to create an rtl expression
+     that refers to the global "variable" `errno'.  (On certain systems,
+     `errno' may not actually be a variable.)  If you don't define this
+     macro, a reasonable default is used.
+
+`TARGET_MEM_FUNCTIONS'
+     Define this macro if GNU CC should generate calls to the System V
+     (and ANSI C) library functions `memcpy' and `memset' rather than
+     the BSD functions `bcopy' and `bzero'.
+
+`LIBGCC_NEEDS_DOUBLE'
+     Define this macro if only `float' arguments cannot be passed to
+     library routines (so they must be converted to `double').  This
+     macro affects both how library calls are generated and how the
+     library routines in `libgcc1.c' accept their arguments.  It is
+     useful on machines where floating and fixed point arguments are
+     passed differently, such as the i860.
+
+`FLOAT_ARG_TYPE'
+     Define this macro to override the type used by the library
+     routines to pick up arguments of type `float'.  (By default, they
+     use a union of `float' and `int'.)
+
+     The obvious choice would be `float'--but that won't work with
+     traditional C compilers that expect all arguments declared as
+     `float' to arrive as `double'.  To avoid this conversion, the
+     library routines ask for the value as some other type and then
+     treat it as a `float'.
+
+     On some systems, no other type will work for this.  For these
+     systems, you must use `LIBGCC_NEEDS_DOUBLE' instead, to force
+     conversion of the values `double' before they are passed.
+
+`FLOATIFY (PASSED-VALUE)'
+     Define this macro to override the way library routines redesignate
+     a `float' argument as a `float' instead of the type it was passed
+     as.  The default is an expression which takes the `float' field of
+     the union.
+
+`FLOAT_VALUE_TYPE'
+     Define this macro to override the type used by the library
+     routines to return values that ought to have type `float'.  (By
+     default, they use `int'.)
+
+     The obvious choice would be `float'--but that won't work with
+     traditional C compilers gratuitously convert values declared as
+     `float' into `double'.
+
+`INTIFY (FLOAT-VALUE)'
+     Define this macro to override the way the value of a
+     `float'-returning library routine should be packaged in order to
+     return it.  These functions are actually declared to return type
+     `FLOAT_VALUE_TYPE' (normally `int').
+
+     These values can't be returned as type `float' because traditional
+     C compilers would gratuitously convert the value to a `double'.
+
+     A local variable named `intify' is always available when the macro
+     `INTIFY' is used.  It is a union of a `float' field named `f' and
+     a field named `i' whose type is `FLOAT_VALUE_TYPE' or `int'.
+
+     If you don't define this macro, the default definition works by
+     copying the value through that union.
+
+`nongcc_SI_type'
+     Define this macro as the name of the data type corresponding to
+     `SImode' in the system's own C compiler.
+
+     You need not define this macro if that type is `long int', as it
+     usually is.
+
+`nongcc_word_type'
+     Define this macro as the name of the data type corresponding to the
+     word_mode in the system's own C compiler.
+
+     You need not define this macro if that type is `long int', as it
+     usually is.
+
+`perform_...'
+     Define these macros to supply explicit C statements to carry out
+     various arithmetic operations on types `float' and `double' in the
+     library routines in `libgcc1.c'.  See that file for a full list of
+     these macros and their arguments.
+
+     On most machines, you don't need to define any of these macros,
+     because the C compiler that comes with the system takes care of
+     doing them.
+
+`NEXT_OBJC_RUNTIME'
+     Define this macro to generate code for Objective C message sending
+     using the calling convention of the NeXT system.  This calling
+     convention involves passing the object, the selector and the
+     method arguments all at once to the method-lookup library function.
+
+     The default calling convention passes just the object and the
+     selector to the lookup function, which returns a pointer to the
+     method.
+
+
+File: gcc.info,  Node: Addressing Modes,  Next: Condition Code,  Prev: Library Calls,  Up: Target Macros
+
+Addressing Modes
+================
+
+   This is about addressing modes.
+
+`HAVE_POST_INCREMENT'
+     A C expression that is nonzero the machine supports post-increment
+     addressing.
+
+`HAVE_PRE_INCREMENT'
+`HAVE_POST_DECREMENT'
+`HAVE_PRE_DECREMENT'
+     Similar for other kinds of addressing.
+
+`CONSTANT_ADDRESS_P (X)'
+     A C expression that is 1 if the RTX X is a constant which is a
+     valid address.  On most machines, this can be defined as
+     `CONSTANT_P (X)', but a few machines are more restrictive in which
+     constant addresses are supported.
+
+     `CONSTANT_P' accepts integer-values expressions whose values are
+     not explicitly known, such as `symbol_ref', `label_ref', and
+     `high' expressions and `const' arithmetic expressions, in addition
+     to `const_int' and `const_double' expressions.
+
+`MAX_REGS_PER_ADDRESS'
+     A number, the maximum number of registers that can appear in a
+     valid memory address.  Note that it is up to you to specify a
+     value equal to the maximum number that `GO_IF_LEGITIMATE_ADDRESS'
+     would ever accept.
+
+`GO_IF_LEGITIMATE_ADDRESS (MODE, X, LABEL)'
+     A C compound statement with a conditional `goto LABEL;' executed
+     if X (an RTX) is a legitimate memory address on the target machine
+     for a memory operand of mode MODE.
+
+     It usually pays to define several simpler macros to serve as
+     subroutines for this one.  Otherwise it may be too complicated to
+     understand.
+
+     This macro must exist in two variants: a strict variant and a
+     non-strict one.  The strict variant is used in the reload pass.  It
+     must be defined so that any pseudo-register that has not been
+     allocated a hard register is considered a memory reference.  In
+     contexts where some kind of register is required, a pseudo-register
+     with no hard register must be rejected.
+
+     The non-strict variant is used in other passes.  It must be
+     defined to accept all pseudo-registers in every context where some
+     kind of register is required.
+
+     Compiler source files that want to use the strict variant of this
+     macro define the macro `REG_OK_STRICT'.  You should use an `#ifdef
+     REG_OK_STRICT' conditional to define the strict variant in that
+     case and the non-strict variant otherwise.
+
+     Subroutines to check for acceptable registers for various purposes
+     (one for base registers, one for index registers, and so on) are
+     typically among the subroutines used to define
+     `GO_IF_LEGITIMATE_ADDRESS'.  Then only these subroutine macros
+     need have two variants; the higher levels of macros may be the
+     same whether strict or not.
+
+     Normally, constant addresses which are the sum of a `symbol_ref'
+     and an integer are stored inside a `const' RTX to mark them as
+     constant.  Therefore, there is no need to recognize such sums
+     specifically as legitimate addresses.  Normally you would simply
+     recognize any `const' as legitimate.
+
+     Usually `PRINT_OPERAND_ADDRESS' is not prepared to handle constant
+     sums that are not marked with  `const'.  It assumes that a naked
+     `plus' indicates indexing.  If so, then you *must* reject such
+     naked constant sums as illegitimate addresses, so that none of
+     them will be given to `PRINT_OPERAND_ADDRESS'.
+
+     On some machines, whether a symbolic address is legitimate depends
+     on the section that the address refers to.  On these machines,
+     define the macro `ENCODE_SECTION_INFO' to store the information
+     into the `symbol_ref', and then check for it here.  When you see a
+     `const', you will have to look inside it to find the `symbol_ref'
+     in order to determine the section.  *Note Assembler Format::.
+
+     The best way to modify the name string is by adding text to the
+     beginning, with suitable punctuation to prevent any ambiguity.
+     Allocate the new name in `saveable_obstack'.  You will have to
+     modify `ASM_OUTPUT_LABELREF' to remove and decode the added text
+     and output the name accordingly, and define `STRIP_NAME_ENCODING'
+     to access the original name string.
+
+     You can check the information stored here into the `symbol_ref' in
+     the definitions of the macros `GO_IF_LEGITIMATE_ADDRESS' and
+     `PRINT_OPERAND_ADDRESS'.
+
+`REG_OK_FOR_BASE_P (X)'
+     A C expression that is nonzero if X (assumed to be a `reg' RTX) is
+     valid for use as a base register.  For hard registers, it should
+     always accept those which the hardware permits and reject the
+     others.  Whether the macro accepts or rejects pseudo registers
+     must be controlled by `REG_OK_STRICT' as described above.  This
+     usually requires two variant definitions, of which `REG_OK_STRICT'
+     controls the one actually used.
+
+`REG_MODE_OK_FOR_BASE_P (X, MODE)'
+     A C expression that is just like `REG_OK_FOR_BASE_P', except that
+     that expression may examine the mode of the memory reference in
+     MODE.  You should define this macro if the mode of the memory
+     reference affects whether a register may be used as a base
+     register.  If you define this macro, the compiler will use it
+     instead of `REG_OK_FOR_BASE_P'.
+
+`REG_OK_FOR_INDEX_P (X)'
+     A C expression that is nonzero if X (assumed to be a `reg' RTX) is
+     valid for use as an index register.
+
+     The difference between an index register and a base register is
+     that the index register may be scaled.  If an address involves the
+     sum of two registers, neither one of them scaled, then either one
+     may be labeled the "base" and the other the "index"; but whichever
+     labeling is used must fit the machine's constraints of which
+     registers may serve in each capacity.  The compiler will try both
+     labelings, looking for one that is valid, and will reload one or
+     both registers only if neither labeling works.
+
+`LEGITIMIZE_ADDRESS (X, OLDX, MODE, WIN)'
+     A C compound statement that attempts to replace X with a valid
+     memory address for an operand of mode MODE.  WIN will be a C
+     statement label elsewhere in the code; the macro definition may use
+
+          GO_IF_LEGITIMATE_ADDRESS (MODE, X, WIN);
+
+     to avoid further processing if the address has become legitimate.
+
+     X will always be the result of a call to `break_out_memory_refs',
+     and OLDX will be the operand that was given to that function to
+     produce X.
+
+     The code generated by this macro should not alter the substructure
+     of X.  If it transforms X into a more legitimate form, it should
+     assign X (which will always be a C variable) a new value.
+
+     It is not necessary for this macro to come up with a legitimate
+     address.  The compiler has standard ways of doing so in all cases.
+     In fact, it is safe for this macro to do nothing.  But often a
+     machine-dependent strategy can generate better code.
+
+`LEGITIMIZE_RELOAD_ADDRESS (X, MODE, OPNUM, TYPE, IND_LEVELS, WIN)'
+     A C compound statement that attempts to replace X, which is an
+     address that needs reloading, with a valid memory address for an
+     operand of mode MODE.  WIN will be a C statement label elsewhere
+     in the code.  It is not necessary to define this macro, but it
+     might be useful for performance reasons.
+
+     For example, on the i386, it is sometimes possible to use a single
+     reload register instead of two by reloading a sum of two pseudo
+     registers into a register.  On the other hand, for number of RISC
+     processors offsets are limited so that often an intermediate
+     address needs to be generated in order to address a stack slot.
+     By defining LEGITIMIZE_RELOAD_ADDRESS appropriately, the
+     intermediate addresses generated for adjacent some stack slots can
+     be made identical, and thus be shared.
+
+     *Note*: This macro should be used with caution.  It is necessary
+     to know something of how reload works in order to effectively use
+     this, and it is quite easy to produce macros that build in too
+     much knowledge of reload internals.
+
+     *Note*: This macro must be able to reload an address created by a
+     previous invocation of this macro.  If it fails to handle such
+     addresses then the compiler may generate incorrect code or abort.
+
+     The macro definition should use `push_reload' to indicate parts
+     that need reloading; OPNUM, TYPE and IND_LEVELS are usually
+     suitable to be passed unaltered to `push_reload'.
+
+     The code generated by this macro must not alter the substructure of
+     X.  If it transforms X into a more legitimate form, it should
+     assign X (which will always be a C variable) a new value.  This
+     also applies to parts that you change indirectly by calling
+     `push_reload'.
+
+     The macro definition may use `strict_memory_address_p' to test if
+     the address has become legitimate.
+
+     If you want to change only a part of X, one standard way of doing
+     this is to use `copy_rtx'.  Note, however, that is unshares only a
+     single level of rtl.  Thus, if the part to be changed is not at the
+     top level, you'll need to replace first the top leve It is not
+     necessary for this macro to come up with a legitimate address;
+     but often a machine-dependent strategy can generate better code.
+
+`GO_IF_MODE_DEPENDENT_ADDRESS (ADDR, LABEL)'
+     A C statement or compound statement with a conditional `goto
+     LABEL;' executed if memory address X (an RTX) can have different
+     meanings depending on the machine mode of the memory reference it
+     is used for or if the address is valid for some modes but not
+     others.
+
+     Autoincrement and autodecrement addresses typically have
+     mode-dependent effects because the amount of the increment or
+     decrement is the size of the operand being addressed.  Some
+     machines have other mode-dependent addresses.  Many RISC machines
+     have no mode-dependent addresses.
+
+     You may assume that ADDR is a valid address for the machine.
+
+`LEGITIMATE_CONSTANT_P (X)'
+     A C expression that is nonzero if X is a legitimate constant for
+     an immediate operand on the target machine.  You can assume that X
+     satisfies `CONSTANT_P', so you need not check this.  In fact, `1'
+     is a suitable definition for this macro on machines where anything
+     `CONSTANT_P' is valid.
+
+
+File: gcc.info,  Node: Condition Code,  Next: Costs,  Prev: Addressing Modes,  Up: Target Macros
+
+Condition Code Status
+=====================
+
+   This describes the condition code status.
+
+   The file `conditions.h' defines a variable `cc_status' to describe
+how the condition code was computed (in case the interpretation of the
+condition code depends on the instruction that it was set by).  This
+variable contains the RTL expressions on which the condition code is
+currently based, and several standard flags.
+
+   Sometimes additional machine-specific flags must be defined in the
+machine description header file.  It can also add additional
+machine-specific information by defining `CC_STATUS_MDEP'.
+
+`CC_STATUS_MDEP'
+     C code for a data type which is used for declaring the `mdep'
+     component of `cc_status'.  It defaults to `int'.
+
+     This macro is not used on machines that do not use `cc0'.
+
+`CC_STATUS_MDEP_INIT'
+     A C expression to initialize the `mdep' field to "empty".  The
+     default definition does nothing, since most machines don't use the
+     field anyway.  If you want to use the field, you should probably
+     define this macro to initialize it.
+
+     This macro is not used on machines that do not use `cc0'.
+
+`NOTICE_UPDATE_CC (EXP, INSN)'
+     A C compound statement to set the components of `cc_status'
+     appropriately for an insn INSN whose body is EXP.  It is this
+     macro's responsibility to recognize insns that set the condition
+     code as a byproduct of other activity as well as those that
+     explicitly set `(cc0)'.
+
+     This macro is not used on machines that do not use `cc0'.
+
+     If there are insns that do not set the condition code but do alter
+     other machine registers, this macro must check to see whether they
+     invalidate the expressions that the condition code is recorded as
+     reflecting.  For example, on the 68000, insns that store in address
+     registers do not set the condition code, which means that usually
+     `NOTICE_UPDATE_CC' can leave `cc_status' unaltered for such insns.
+     But suppose that the previous insn set the condition code based
+     on location `a4@(102)' and the current insn stores a new value in
+     `a4'.  Although the condition code is not changed by this, it will
+     no longer be true that it reflects the contents of `a4@(102)'.
+     Therefore, `NOTICE_UPDATE_CC' must alter `cc_status' in this case
+     to say that nothing is known about the condition code value.
+
+     The definition of `NOTICE_UPDATE_CC' must be prepared to deal with
+     the results of peephole optimization: insns whose patterns are
+     `parallel' RTXs containing various `reg', `mem' or constants which
+     are just the operands.  The RTL structure of these insns is not
+     sufficient to indicate what the insns actually do.  What
+     `NOTICE_UPDATE_CC' should do when it sees one is just to run
+     `CC_STATUS_INIT'.
+
+     A possible definition of `NOTICE_UPDATE_CC' is to call a function
+     that looks at an attribute (*note Insn Attributes::.) named, for
+     example, `cc'.  This avoids having detailed information about
+     patterns in two places, the `md' file and in `NOTICE_UPDATE_CC'.
+
+`EXTRA_CC_MODES'
+     A list of names to be used for additional modes for condition code
+     values in registers (*note Jump Patterns::.).  These names are
+     added to `enum machine_mode' and all have class `MODE_CC'.  By
+     convention, they should start with `CC' and end with `mode'.
+
+     You should only define this macro if your machine does not use
+     `cc0' and only if additional modes are required.
+
+`EXTRA_CC_NAMES'
+     A list of C strings giving the names for the modes listed in
+     `EXTRA_CC_MODES'.  For example, the Sparc defines this macro and
+     `EXTRA_CC_MODES' as
+
+          #define EXTRA_CC_MODES CC_NOOVmode, CCFPmode, CCFPEmode
+          #define EXTRA_CC_NAMES "CC_NOOV", "CCFP", "CCFPE"
+
+     This macro is not required if `EXTRA_CC_MODES' is not defined.
+
+`SELECT_CC_MODE (OP, X, Y)'
+     Returns a mode from class `MODE_CC' to be used when comparison
+     operation code OP is applied to rtx X and Y.  For example, on the
+     Sparc, `SELECT_CC_MODE' is defined as (see *note Jump Patterns::.
+     for a description of the reason for this definition)
+
+          #define SELECT_CC_MODE(OP,X,Y) \
+            (GET_MODE_CLASS (GET_MODE (X)) == MODE_FLOAT          \
+             ? ((OP == EQ || OP == NE) ? CCFPmode : CCFPEmode)    \
+             : ((GET_CODE (X) == PLUS || GET_CODE (X) == MINUS    \
+                 || GET_CODE (X) == NEG) \
+                ? CC_NOOVmode : CCmode))
+
+     You need not define this macro if `EXTRA_CC_MODES' is not defined.
+
+`CANONICALIZE_COMPARISON (CODE, OP0, OP1)'
+     One some machines not all possible comparisons are defined, but
+     you can convert an invalid comparison into a valid one.  For
+     example, the Alpha does not have a `GT' comparison, but you can
+     use an `LT' comparison instead and swap the order of the operands.
+
+     On such machines, define this macro to be a C statement to do any
+     required conversions.  CODE is the initial comparison code and OP0
+     and OP1 are the left and right operands of the comparison,
+     respectively.  You should modify CODE, OP0, and OP1 as required.
+
+     GNU CC will not assume that the comparison resulting from this
+     macro is valid but will see if the resulting insn matches a
+     pattern in the `md' file.
+
+     You need not define this macro if it would never change the
+     comparison code or operands.
+
+`REVERSIBLE_CC_MODE (MODE)'
+     A C expression whose value is one if it is always safe to reverse a
+     comparison whose mode is MODE.  If `SELECT_CC_MODE' can ever
+     return MODE for a floating-point inequality comparison, then
+     `REVERSIBLE_CC_MODE (MODE)' must be zero.
+
+     You need not define this macro if it would always returns zero or
+     if the floating-point format is anything other than
+     `IEEE_FLOAT_FORMAT'.  For example, here is the definition used on
+     the Sparc, where floating-point inequality comparisons are always
+     given `CCFPEmode':
+
+          #define REVERSIBLE_CC_MODE(MODE)  ((MODE) != CCFPEmode)
+
+
+File: gcc.info,  Node: Costs,  Next: Sections,  Prev: Condition Code,  Up: Target Macros
+
+Describing Relative Costs of Operations
+=======================================
+
+   These macros let you describe the relative speed of various
+operations on the target machine.
+
+`CONST_COSTS (X, CODE, OUTER_CODE)'
+     A part of a C `switch' statement that describes the relative costs
+     of constant RTL expressions.  It must contain `case' labels for
+     expression codes `const_int', `const', `symbol_ref', `label_ref'
+     and `const_double'.  Each case must ultimately reach a `return'
+     statement to return the relative cost of the use of that kind of
+     constant value in an expression.  The cost may depend on the
+     precise value of the constant, which is available for examination
+     in X, and the rtx code of the expression in which it is contained,
+     found in OUTER_CODE.
+
+     CODE is the expression code--redundant, since it can be obtained
+     with `GET_CODE (X)'.
+
+`RTX_COSTS (X, CODE, OUTER_CODE)'
+     Like `CONST_COSTS' but applies to nonconstant RTL expressions.
+     This can be used, for example, to indicate how costly a multiply
+     instruction is.  In writing this macro, you can use the construct
+     `COSTS_N_INSNS (N)' to specify a cost equal to N fast
+     instructions.  OUTER_CODE is the code of the expression in which X
+     is contained.
+
+     This macro is optional; do not define it if the default cost
+     assumptions are adequate for the target machine.
+
+`DEFAULT_RTX_COSTS (X, CODE, OUTER_CODE)'
+     This macro, if defined, is called for any case not handled by the
+     `RTX_COSTS' or `CONST_COSTS' macros.  This eliminates the need to
+     put case labels into the macro, but the code, or any functions it
+     calls, must assume that the RTL in X could be of any type that has
+     not already been handled.  The arguments are the same as for
+     `RTX_COSTS', and the macro should execute a return statement giving
+     the cost of any RTL expressions that it can handle.  The default
+     cost calculation is used for any RTL for which this macro does not
+     return a value.
+
+     This macro is optional; do not define it if the default cost
+     assumptions are adequate for the target machine.
+
+`ADDRESS_COST (ADDRESS)'
+     An expression giving the cost of an addressing mode that contains
+     ADDRESS.  If not defined, the cost is computed from the ADDRESS
+     expression and the `CONST_COSTS' values.
+
+     For most CISC machines, the default cost is a good approximation
+     of the true cost of the addressing mode.  However, on RISC
+     machines, all instructions normally have the same length and
+     execution time.  Hence all addresses will have equal costs.
+
+     In cases where more than one form of an address is known, the form
+     with the lowest cost will be used.  If multiple forms have the
+     same, lowest, cost, the one that is the most complex will be used.
+
+     For example, suppose an address that is equal to the sum of a
+     register and a constant is used twice in the same basic block.
+     When this macro is not defined, the address will be computed in a
+     register and memory references will be indirect through that
+     register.  On machines where the cost of the addressing mode
+     containing the sum is no higher than that of a simple indirect
+     reference, this will produce an additional instruction and
+     possibly require an additional register.  Proper specification of
+     this macro eliminates this overhead for such machines.
+
+     Similar use of this macro is made in strength reduction of loops.
+
+     ADDRESS need not be valid as an address.  In such a case, the cost
+     is not relevant and can be any value; invalid addresses need not be
+     assigned a different cost.
+
+     On machines where an address involving more than one register is as
+     cheap as an address computation involving only one register,
+     defining `ADDRESS_COST' to reflect this can cause two registers to
+     be live over a region of code where only one would have been if
+     `ADDRESS_COST' were not defined in that manner.  This effect should
+     be considered in the definition of this macro.  Equivalent costs
+     should probably only be given to addresses with different numbers
+     of registers on machines with lots of registers.
+
+     This macro will normally either not be defined or be defined as a
+     constant.
+
+`REGISTER_MOVE_COST (FROM, TO)'
+     A C expression for the cost of moving data from a register in class
+     FROM to one in class TO.  The classes are expressed using the
+     enumeration values such as `GENERAL_REGS'.  A value of 2 is the
+     default; other values are interpreted relative to that.
+
+     It is not required that the cost always equal 2 when FROM is the
+     same as TO; on some machines it is expensive to move between
+     registers if they are not general registers.
+
+     If reload sees an insn consisting of a single `set' between two
+     hard registers, and if `REGISTER_MOVE_COST' applied to their
+     classes returns a value of 2, reload does not check to ensure that
+     the constraints of the insn are met.  Setting a cost of other than
+     2 will allow reload to verify that the constraints are met.  You
+     should do this if the `movM' pattern's constraints do not allow
+     such copying.
+
+`MEMORY_MOVE_COST (MODE, CLASS, IN)'
+     A C expression for the cost of moving data of mode MODE between a
+     register of class CLASS and memory; IN is zero if the value is to
+     be written to memory, non-zero if it is to be read in.  This cost
+     is relative to those in `REGISTER_MOVE_COST'.  If moving between
+     registers and memory is more expensive than between two registers,
+     you should define this macro to express the relative cost.
+
+     If you do not define this macro, GNU CC uses a default cost of 4
+     plus the cost of copying via a secondary reload register, if one is
+     needed.  If your machine requires a secondary reload register to
+     copy between memory and a register of CLASS but the reload
+     mechanism is more complex than copying via an intermediate, define
+     this macro to reflect the actual cost of the move.
+
+     GNU CC defines the function `memory_move_secondary_cost' if
+     secondary reloads are needed.  It computes the costs due to
+     copying via a secondary register.  If your machine copies from
+     memory using a secondary register in the conventional way but the
+     default base value of 4 is not correct for your machine, define
+     this macro to add some other value to the result of that function.
+     The arguments to that function are the same as to this macro.
+
+`BRANCH_COST'
+     A C expression for the cost of a branch instruction.  A value of 1
+     is the default; other values are interpreted relative to that.
+
+   Here are additional macros which do not specify precise relative
+costs, but only that certain actions are more expensive than GNU CC
+would ordinarily expect.
+
+`SLOW_BYTE_ACCESS'
+     Define this macro as a C expression which is nonzero if accessing
+     less than a word of memory (i.e. a `char' or a `short') is no
+     faster than accessing a word of memory, i.e., if such access
+     require more than one instruction or if there is no difference in
+     cost between byte and (aligned) word loads.
+
+     When this macro is not defined, the compiler will access a field by
+     finding the smallest containing object; when it is defined, a
+     fullword load will be used if alignment permits.  Unless bytes
+     accesses are faster than word accesses, using word accesses is
+     preferable since it may eliminate subsequent memory access if
+     subsequent accesses occur to other fields in the same word of the
+     structure, but to different bytes.
+
+`SLOW_ZERO_EXTEND'
+     Define this macro if zero-extension (of a `char' or `short' to an
+     `int') can be done faster if the destination is a register that is
+     known to be zero.
+
+     If you define this macro, you must have instruction patterns that
+     recognize RTL structures like this:
+
+          (set (strict_low_part (subreg:QI (reg:SI ...) 0)) ...)
+
+     and likewise for `HImode'.
+
+`SLOW_UNALIGNED_ACCESS'
+     Define this macro to be the value 1 if unaligned accesses have a
+     cost many times greater than aligned accesses, for example if they
+     are emulated in a trap handler.
+
+     When this macro is non-zero, the compiler will act as if
+     `STRICT_ALIGNMENT' were non-zero when generating code for block
+     moves.  This can cause significantly more instructions to be
+     produced.  Therefore, do not set this macro non-zero if unaligned
+     accesses only add a cycle or two to the time for a memory access.
+
+     If the value of this macro is always zero, it need not be defined.
+
+`DONT_REDUCE_ADDR'
+     Define this macro to inhibit strength reduction of memory
+     addresses.  (On some machines, such strength reduction seems to do
+     harm rather than good.)
+
+`MOVE_RATIO'
+     The threshold of number of scalar memory-to-memory move insns,
+     *below* which a sequence of insns  should be generated instead of a
+     string move insn or a library call.  Increasing the value will
+     always make code faster, but eventually incurs high cost in
+     increased code size.
+
+     Note that on machines with no memory-to-memory move insns, this
+     macro denotes the corresponding number of memory-to-memory
+     *sequences*.
+
+     If you don't define this, a reasonable default is used.
+
+`MOVE_BY_PIECES_P (SIZE, ALIGNMENT)'
+     A C expression used to determine whether `move_by_pieces' will be
+     used to copy a chunk of memory, or whether some other block move
+     mechanism will be used.  Defaults to 1 if `move_by_pieces_ninsns'
+     returns less than `MOVE_RATIO'.
+
+`MOVE_MAX_PIECES'
+     A C expression used by `move_by_pieces' to determine the largest
+     unit a load or store used to copy memory is.  Defaults to
+     `MOVE_MAX'.
+
+`USE_LOAD_POST_INCREMENT (MODE)'
+     A C expression used to determine whether a load postincrement is a
+     good thing to use for a given mode.  Defaults to the value of
+     `HAVE_POST_INCREMENT'.
+
+`USE_LOAD_POST_DECREMENT (MODE)'
+     A C expression used to determine whether a load postdecrement is a
+     good thing to use for a given mode.  Defaults to the value of
+     `HAVE_POST_DECREMENT'.
+
+`USE_LOAD_PRE_INCREMENT (MODE)'
+     A C expression used to determine whether a load preincrement is a
+     good thing to use for a given mode.  Defaults to the value of
+     `HAVE_PRE_INCREMENT'.
+
+`USE_LOAD_PRE_DECREMENT (MODE)'
+     A C expression used to determine whether a load predecrement is a
+     good thing to use for a given mode.  Defaults to the value of
+     `HAVE_PRE_DECREMENT'.
+
+`USE_STORE_POST_INCREMENT (MODE)'
+     A C expression used to determine whether a store postincrement is
+     a good thing to use for a given mode.  Defaults to the value of
+     `HAVE_POST_INCREMENT'.
+
+`USE_STORE_POST_DECREMENT (MODE)'
+     A C expression used to determine whether a store postdeccrement is
+     a good thing to use for a given mode.  Defaults to the value of
+     `HAVE_POST_DECREMENT'.
+
+`USE_STORE_PRE_INCREMENT (MODE)'
+     This macro is used to determine whether a store preincrement is a
+     good thing to use for a given mode.  Defaults to the value of
+     `HAVE_PRE_INCREMENT'.
+
+`USE_STORE_PRE_DECREMENT (MODE)'
+     This macro is used to determine whether a store predecrement is a
+     good thing to use for a given mode.  Defaults to the value of
+     `HAVE_PRE_DECREMENT'.
+
+`NO_FUNCTION_CSE'
+     Define this macro if it is as good or better to call a constant
+     function address than to call an address kept in a register.
+
+`NO_RECURSIVE_FUNCTION_CSE'
+     Define this macro if it is as good or better for a function to call
+     itself with an explicit address than to call an address kept in a
+     register.
+
+`ADJUST_COST (INSN, LINK, DEP_INSN, COST)'
+     A C statement (sans semicolon) to update the integer variable COST
+     based on the relationship between INSN that is dependent on
+     DEP_INSN through the dependence LINK.  The default is to make no
+     adjustment to COST.  This can be used for example to specify to
+     the scheduler that an output- or anti-dependence does not incur
+     the same cost as a data-dependence.
+
+`ADJUST_PRIORITY (INSN)'
+     A C statement (sans semicolon) to update the integer scheduling
+     priority `INSN_PRIORITY(INSN)'.  Reduce the priority to execute
+     the INSN earlier, increase the priority to execute INSN later.
+     Do not define this macro if you do not need to adjust the
+     scheduling priorities of insns.
+

usr/local/nachos/info/gcc.info-27

@@ -0,0 +1,946 @@
+This is Info file gcc.info, produced by Makeinfo version 1.68 from the
+input file ../../gcc-2.95.2/gcc/gcc.texi.
+
+INFO-DIR-SECTION Programming
+START-INFO-DIR-ENTRY
+* gcc: (gcc).                  The GNU Compiler Collection.
+END-INFO-DIR-ENTRY
+   This file documents the use and the internals of the GNU compiler.
+
+   Published by the Free Software Foundation 59 Temple Place - Suite 330
+Boston, MA 02111-1307 USA
+
+   Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
+1999 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 sections entitled "GNU General Public License" and "Funding
+for Free Software" are included exactly as in the original, and
+provided 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, except that the sections entitled "GNU General Public
+License" and "Funding for Free Software", and this permission notice,
+may be included in translations approved by the Free Software Foundation
+instead of in the original English.
+
+
+File: gcc.info,  Node: Instruction Output,  Next: Dispatch Tables,  Prev: Macros for Initialization,  Up: Assembler Format
+
+Output of Assembler Instructions
+--------------------------------
+
+   This describes assembler instruction output.
+
+`REGISTER_NAMES'
+     A C initializer containing the assembler's names for the machine
+     registers, each one as a C string constant.  This is what
+     translates register numbers in the compiler into assembler
+     language.
+
+`ADDITIONAL_REGISTER_NAMES'
+     If defined, a C initializer for an array of structures containing
+     a name and a register number.  This macro defines additional names
+     for hard registers, thus allowing the `asm' option in declarations
+     to refer to registers using alternate names.
+
+`ASM_OUTPUT_OPCODE (STREAM, PTR)'
+     Define this macro if you are using an unusual assembler that
+     requires different names for the machine instructions.
+
+     The definition is a C statement or statements which output an
+     assembler instruction opcode to the stdio stream STREAM.  The
+     macro-operand PTR is a variable of type `char *' which points to
+     the opcode name in its "internal" form--the form that is written
+     in the machine description.  The definition should output the
+     opcode name to STREAM, performing any translation you desire, and
+     increment the variable PTR to point at the end of the opcode so
+     that it will not be output twice.
+
+     In fact, your macro definition may process less than the entire
+     opcode name, or more than the opcode name; but if you want to
+     process text that includes `%'-sequences to substitute operands,
+     you must take care of the substitution yourself.  Just be sure to
+     increment PTR over whatever text should not be output normally.
+
+     If you need to look at the operand values, they can be found as the
+     elements of `recog_operand'.
+
+     If the macro definition does nothing, the instruction is output in
+     the usual way.
+
+`FINAL_PRESCAN_INSN (INSN, OPVEC, NOPERANDS)'
+     If defined, a C statement to be executed just prior to the output
+     of assembler code for INSN, to modify the extracted operands so
+     they will be output differently.
+
+     Here the argument OPVEC is the vector containing the operands
+     extracted from INSN, and NOPERANDS is the number of elements of
+     the vector which contain meaningful data for this insn.  The
+     contents of this vector are what will be used to convert the insn
+     template into assembler code, so you can change the assembler
+     output by changing the contents of the vector.
+
+     This macro is useful when various assembler syntaxes share a single
+     file of instruction patterns; by defining this macro differently,
+     you can cause a large class of instructions to be output
+     differently (such as with rearranged operands).  Naturally,
+     variations in assembler syntax affecting individual insn patterns
+     ought to be handled by writing conditional output routines in
+     those patterns.
+
+     If this macro is not defined, it is equivalent to a null statement.
+
+`FINAL_PRESCAN_LABEL'
+     If defined, `FINAL_PRESCAN_INSN' will be called on each
+     `CODE_LABEL'.  In that case, OPVEC will be a null pointer and
+     NOPERANDS will be zero.
+
+`PRINT_OPERAND (STREAM, X, CODE)'
+     A C compound statement to output to stdio stream STREAM the
+     assembler syntax for an instruction operand X.  X is an RTL
+     expression.
+
+     CODE is a value that can be used to specify one of several ways of
+     printing the operand.  It is used when identical operands must be
+     printed differently depending on the context.  CODE comes from the
+     `%' specification that was used to request printing of the
+     operand.  If the specification was just `%DIGIT' then CODE is 0;
+     if the specification was `%LTR DIGIT' then CODE is the ASCII code
+     for LTR.
+
+     If X is a register, this macro should print the register's name.
+     The names can be found in an array `reg_names' whose type is `char
+     *[]'.  `reg_names' is initialized from `REGISTER_NAMES'.
+
+     When the machine description has a specification `%PUNCT' (a `%'
+     followed by a punctuation character), this macro is called with a
+     null pointer for X and the punctuation character for CODE.
+
+`PRINT_OPERAND_PUNCT_VALID_P (CODE)'
+     A C expression which evaluates to true if CODE is a valid
+     punctuation character for use in the `PRINT_OPERAND' macro.  If
+     `PRINT_OPERAND_PUNCT_VALID_P' is not defined, it means that no
+     punctuation characters (except for the standard one, `%') are used
+     in this way.
+
+`PRINT_OPERAND_ADDRESS (STREAM, X)'
+     A C compound statement to output to stdio stream STREAM the
+     assembler syntax for an instruction operand that is a memory
+     reference whose address is X.  X is an RTL expression.
+
+     On some machines, the syntax for a symbolic address depends on the
+     section that the address refers to.  On these machines, define the
+     macro `ENCODE_SECTION_INFO' to store the information into the
+     `symbol_ref', and then check for it here.  *Note Assembler
+     Format::.
+
+`DBR_OUTPUT_SEQEND(FILE)'
+     A C statement, to be executed after all slot-filler instructions
+     have been output.  If necessary, call `dbr_sequence_length' to
+     determine the number of slots filled in a sequence (zero if not
+     currently outputting a sequence), to decide how many no-ops to
+     output, or whatever.
+
+     Don't define this macro if it has nothing to do, but it is helpful
+     in reading assembly output if the extent of the delay sequence is
+     made explicit (e.g. with white space).
+
+     Note that output routines for instructions with delay slots must be
+     prepared to deal with not being output as part of a sequence (i.e.
+     when the scheduling pass is not run, or when no slot fillers could
+     be found.)  The variable `final_sequence' is null when not
+     processing a sequence, otherwise it contains the `sequence' rtx
+     being output.
+
+`REGISTER_PREFIX'
+`LOCAL_LABEL_PREFIX'
+`USER_LABEL_PREFIX'
+`IMMEDIATE_PREFIX'
+     If defined, C string expressions to be used for the `%R', `%L',
+     `%U', and `%I' options of `asm_fprintf' (see `final.c').  These
+     are useful when a single `md' file must support multiple assembler
+     formats.  In that case, the various `tm.h' files can define these
+     macros differently.
+
+`ASSEMBLER_DIALECT'
+     If your target supports multiple dialects of assembler language
+     (such as different opcodes), define this macro as a C expression
+     that gives the numeric index of the assembler language dialect to
+     use, with zero as the first variant.
+
+     If this macro is defined, you may use constructs of the form
+     `{option0|option1|option2...}' in the output templates of patterns
+     (*note Output Template::.) or in the first argument of
+     `asm_fprintf'.  This construct outputs `option0', `option1' or
+     `option2', etc., if the value of `ASSEMBLER_DIALECT' is zero, one
+     or two, etc.  Any special characters within these strings retain
+     their usual meaning.
+
+     If you do not define this macro, the characters `{', `|' and `}'
+     do not have any special meaning when used in templates or operands
+     to `asm_fprintf'.
+
+     Define the macros `REGISTER_PREFIX', `LOCAL_LABEL_PREFIX',
+     `USER_LABEL_PREFIX' and `IMMEDIATE_PREFIX' if you can express the
+     variations in assembler language syntax with that mechanism.
+     Define `ASSEMBLER_DIALECT' and use the `{option0|option1}' syntax
+     if the syntax variant are larger and involve such things as
+     different opcodes or operand order.
+
+`ASM_OUTPUT_REG_PUSH (STREAM, REGNO)'
+     A C expression to output to STREAM some assembler code which will
+     push hard register number REGNO onto the stack.  The code need not
+     be optimal, since this macro is used only when profiling.
+
+`ASM_OUTPUT_REG_POP (STREAM, REGNO)'
+     A C expression to output to STREAM some assembler code which will
+     pop hard register number REGNO off of the stack.  The code need
+     not be optimal, since this macro is used only when profiling.
+
+
+File: gcc.info,  Node: Dispatch Tables,  Next: Exception Region Output,  Prev: Instruction Output,  Up: Assembler Format
+
+Output of Dispatch Tables
+-------------------------
+
+   This concerns dispatch tables.
+
+`ASM_OUTPUT_ADDR_DIFF_ELT (STREAM, BODY, VALUE, REL)'
+     A C statement to output to the stdio stream STREAM an assembler
+     pseudo-instruction to generate a difference between two labels.
+     VALUE and REL are the numbers of two internal labels.  The
+     definitions of these labels are output using
+     `ASM_OUTPUT_INTERNAL_LABEL', and they must be printed in the same
+     way here.  For example,
+
+          fprintf (STREAM, "\t.word L%d-L%d\n",
+                   VALUE, REL)
+
+     You must provide this macro on machines where the addresses in a
+     dispatch table are relative to the table's own address.  If
+     defined, GNU CC will also use this macro on all machines when
+     producing PIC.  BODY is the body of the ADDR_DIFF_VEC; it is
+     provided so that the mode and flags can be read.
+
+`ASM_OUTPUT_ADDR_VEC_ELT (STREAM, VALUE)'
+     This macro should be provided on machines where the addresses in a
+     dispatch table are absolute.
+
+     The definition should be a C statement to output to the stdio
+     stream STREAM an assembler pseudo-instruction to generate a
+     reference to a label.  VALUE is the number of an internal label
+     whose definition is output using `ASM_OUTPUT_INTERNAL_LABEL'.  For
+     example,
+
+          fprintf (STREAM, "\t.word L%d\n", VALUE)
+
+`ASM_OUTPUT_CASE_LABEL (STREAM, PREFIX, NUM, TABLE)'
+     Define this if the label before a jump-table needs to be output
+     specially.  The first three arguments are the same as for
+     `ASM_OUTPUT_INTERNAL_LABEL'; the fourth argument is the jump-table
+     which follows (a `jump_insn' containing an `addr_vec' or
+     `addr_diff_vec').
+
+     This feature is used on system V to output a `swbeg' statement for
+     the table.
+
+     If this macro is not defined, these labels are output with
+     `ASM_OUTPUT_INTERNAL_LABEL'.
+
+`ASM_OUTPUT_CASE_END (STREAM, NUM, TABLE)'
+     Define this if something special must be output at the end of a
+     jump-table.  The definition should be a C statement to be executed
+     after the assembler code for the table is written.  It should write
+     the appropriate code to stdio stream STREAM.  The argument TABLE
+     is the jump-table insn, and NUM is the label-number of the
+     preceding label.
+
+     If this macro is not defined, nothing special is output at the end
+     of the jump-table.
+
+
+File: gcc.info,  Node: Exception Region Output,  Next: Alignment Output,  Prev: Dispatch Tables,  Up: Assembler Format
+
+Assembler Commands for Exception Regions
+----------------------------------------
+
+   This describes commands marking the start and the end of an exception
+region.
+
+`ASM_OUTPUT_EH_REGION_BEG ()'
+     A C expression to output text to mark the start of an exception
+     region.
+
+     This macro need not be defined on most platforms.
+
+`ASM_OUTPUT_EH_REGION_END ()'
+     A C expression to output text to mark the end of an exception
+     region.
+
+     This macro need not be defined on most platforms.
+
+`EXCEPTION_SECTION ()'
+     A C expression to switch to the section in which the main
+     exception table is to be placed (*note Sections::.).  The default
+     is a section named `.gcc_except_table' on machines that support
+     named sections via `ASM_OUTPUT_SECTION_NAME', otherwise if `-fpic'
+     or `-fPIC' is in effect, the `data_section', otherwise the
+     `readonly_data_section'.
+
+`EH_FRAME_SECTION_ASM_OP'
+     If defined, a C string constant for the assembler operation to
+     switch to the section for exception handling frame unwind
+     information.  If not defined, GNU CC will provide a default
+     definition if the target supports named sections.  `crtstuff.c'
+     uses this macro to switch to the appropriate section.
+
+     You should define this symbol if your target supports DWARF 2 frame
+     unwind information and the default definition does not work.
+
+`OMIT_EH_TABLE ()'
+     A C expression that is nonzero if the normal exception table output
+     should be omitted.
+
+     This macro need not be defined on most platforms.
+
+`EH_TABLE_LOOKUP ()'
+     Alternate runtime support for looking up an exception at runtime
+     and finding the associated handler, if the default method won't
+     work.
+
+     This macro need not be defined on most platforms.
+
+`DOESNT_NEED_UNWINDER'
+     A C expression that decides whether or not the current function
+     needs to have a function unwinder generated for it.  See the file
+     `except.c' for details on when to define this, and how.
+
+`MASK_RETURN_ADDR'
+     An rtx used to mask the return address found via RETURN_ADDR_RTX,
+     so that it does not contain any extraneous set bits in it.
+
+`DWARF2_UNWIND_INFO'
+     Define this macro to 0 if your target supports DWARF 2 frame unwind
+     information, but it does not yet work with exception handling.
+     Otherwise, if your target supports this information (if it defines
+     `INCOMING_RETURN_ADDR_RTX' and either `UNALIGNED_INT_ASM_OP' or
+     `OBJECT_FORMAT_ELF'), GCC will provide a default definition of 1.
+
+     If this macro is defined to 1, the DWARF 2 unwinder will be the
+     default exception handling mechanism; otherwise, setjmp/longjmp
+     will be used by default.
+
+     If this macro is defined to anything, the DWARF 2 unwinder will be
+     used instead of inline unwinders and __unwind_function in the
+     non-setjmp case.
+
+
+File: gcc.info,  Node: Alignment Output,  Prev: Exception Region Output,  Up: Assembler Format
+
+Assembler Commands for Alignment
+--------------------------------
+
+   This describes commands for alignment.
+
+`LABEL_ALIGN_AFTER_BARRIER (LABEL)'
+     The alignment (log base 2) to put in front of LABEL, which follows
+     a BARRIER.
+
+     This macro need not be defined if you don't want any special
+     alignment to be done at such a time.  Most machine descriptions do
+     not currently define the macro.
+
+`LOOP_ALIGN (LABEL)'
+     The alignment (log base 2) to put in front of LABEL, which follows
+     a NOTE_INSN_LOOP_BEG note.
+
+     This macro need not be defined if you don't want any special
+     alignment to be done at such a time.  Most machine descriptions do
+     not currently define the macro.
+
+`LABEL_ALIGN (LABEL)'
+     The alignment (log base 2) to put in front of LABEL.  If
+     LABEL_ALIGN_AFTER_BARRIER / LOOP_ALIGN specify a different
+     alignment, the maximum of the specified values is used.
+
+`ASM_OUTPUT_SKIP (STREAM, NBYTES)'
+     A C statement to output to the stdio stream STREAM an assembler
+     instruction to advance the location counter by NBYTES bytes.
+     Those bytes should be zero when loaded.  NBYTES will be a C
+     expression of type `int'.
+
+`ASM_NO_SKIP_IN_TEXT'
+     Define this macro if `ASM_OUTPUT_SKIP' should not be used in the
+     text section because it fails to put zeros in the bytes that are
+     skipped.  This is true on many Unix systems, where the pseudo-op
+     to skip bytes produces no-op instructions rather than zeros when
+     used in the text section.
+
+`ASM_OUTPUT_ALIGN (STREAM, POWER)'
+     A C statement to output to the stdio stream STREAM an assembler
+     command to advance the location counter to a multiple of 2 to the
+     POWER bytes.  POWER will be a C expression of type `int'.
+
+`ASM_OUTPUT_MAX_SKIP_ALIGN (STREAM, POWER, MAX_SKIP)'
+     A C statement to output to the stdio stream STREAM an assembler
+     command to advance the location counter to a multiple of 2 to the
+     POWER bytes, but only if MAX_SKIP or fewer bytes are needed to
+     satisfy the alignment request.  POWER and MAX_SKIP will be a C
+     expression of type `int'.
+
+
+File: gcc.info,  Node: Debugging Info,  Next: Cross-compilation,  Prev: Assembler Format,  Up: Target Macros
+
+Controlling Debugging Information Format
+========================================
+
+   This describes how to specify debugging information.
+
+* Menu:
+
+* All Debuggers::      Macros that affect all debugging formats uniformly.
+* DBX Options::        Macros enabling specific options in DBX format.
+* DBX Hooks::          Hook macros for varying DBX format.
+* File Names and DBX:: Macros controlling output of file names in DBX format.
+* SDB and DWARF::      Macros for SDB (COFF) and DWARF formats.
+
+
+File: gcc.info,  Node: All Debuggers,  Next: DBX Options,  Up: Debugging Info
+
+Macros Affecting All Debugging Formats
+--------------------------------------
+
+   These macros affect all debugging formats.
+
+`DBX_REGISTER_NUMBER (REGNO)'
+     A C expression that returns the DBX register number for the
+     compiler register number REGNO.  In simple cases, the value of this
+     expression may be REGNO itself.  But sometimes there are some
+     registers that the compiler knows about and DBX does not, or vice
+     versa.  In such cases, some register may need to have one number in
+     the compiler and another for DBX.
+
+     If two registers have consecutive numbers inside GNU CC, and they
+     can be used as a pair to hold a multiword value, then they *must*
+     have consecutive numbers after renumbering with
+     `DBX_REGISTER_NUMBER'.  Otherwise, debuggers will be unable to
+     access such a pair, because they expect register pairs to be
+     consecutive in their own numbering scheme.
+
+     If you find yourself defining `DBX_REGISTER_NUMBER' in way that
+     does not preserve register pairs, then what you must do instead is
+     redefine the actual register numbering scheme.
+
+`DEBUGGER_AUTO_OFFSET (X)'
+     A C expression that returns the integer offset value for an
+     automatic variable having address X (an RTL expression).  The
+     default computation assumes that X is based on the frame-pointer
+     and gives the offset from the frame-pointer.  This is required for
+     targets that produce debugging output for DBX or COFF-style
+     debugging output for SDB and allow the frame-pointer to be
+     eliminated when the `-g' options is used.
+
+`DEBUGGER_ARG_OFFSET (OFFSET, X)'
+     A C expression that returns the integer offset value for an
+     argument having address X (an RTL expression).  The nominal offset
+     is OFFSET.
+
+`PREFERRED_DEBUGGING_TYPE'
+     A C expression that returns the type of debugging output GNU CC
+     should produce when the user specifies just `-g'.  Define this if
+     you have arranged for GNU CC to support more than one format of
+     debugging output.  Currently, the allowable values are `DBX_DEBUG',
+     `SDB_DEBUG', `DWARF_DEBUG', `DWARF2_DEBUG', and `XCOFF_DEBUG'.
+
+     When the user specifies `-ggdb', GNU CC normally also uses the
+     value of this macro to select the debugging output format, but
+     with two exceptions.  If `DWARF2_DEBUGGING_INFO' is defined and
+     `LINKER_DOES_NOT_WORK_WITH_DWARF2' is not defined, GNU CC uses the
+     value `DWARF2_DEBUG'.  Otherwise, if `DBX_DEBUGGING_INFO' is
+     defined, GNU CC uses `DBX_DEBUG'.
+
+     The value of this macro only affects the default debugging output;
+     the user can always get a specific type of output by using
+     `-gstabs', `-gcoff', `-gdwarf-1', `-gdwarf-2', or `-gxcoff'.
+
+
+File: gcc.info,  Node: DBX Options,  Next: DBX Hooks,  Prev: All Debuggers,  Up: Debugging Info
+
+Specific Options for DBX Output
+-------------------------------
+
+   These are specific options for DBX output.
+
+`DBX_DEBUGGING_INFO'
+     Define this macro if GNU CC should produce debugging output for DBX
+     in response to the `-g' option.
+
+`XCOFF_DEBUGGING_INFO'
+     Define this macro if GNU CC should produce XCOFF format debugging
+     output in response to the `-g' option.  This is a variant of DBX
+     format.
+
+`DEFAULT_GDB_EXTENSIONS'
+     Define this macro to control whether GNU CC should by default
+     generate GDB's extended version of DBX debugging information
+     (assuming DBX-format debugging information is enabled at all).  If
+     you don't define the macro, the default is 1: always generate the
+     extended information if there is any occasion to.
+
+`DEBUG_SYMS_TEXT'
+     Define this macro if all `.stabs' commands should be output while
+     in the text section.
+
+`ASM_STABS_OP'
+     A C string constant naming the assembler pseudo op to use instead
+     of `.stabs' to define an ordinary debugging symbol.  If you don't
+     define this macro, `.stabs' is used.  This macro applies only to
+     DBX debugging information format.
+
+`ASM_STABD_OP'
+     A C string constant naming the assembler pseudo op to use instead
+     of `.stabd' to define a debugging symbol whose value is the current
+     location.  If you don't define this macro, `.stabd' is used.  This
+     macro applies only to DBX debugging information format.
+
+`ASM_STABN_OP'
+     A C string constant naming the assembler pseudo op to use instead
+     of `.stabn' to define a debugging symbol with no name.  If you
+     don't define this macro, `.stabn' is used.  This macro applies
+     only to DBX debugging information format.
+
+`DBX_NO_XREFS'
+     Define this macro if DBX on your system does not support the
+     construct `xsTAGNAME'.  On some systems, this construct is used to
+     describe a forward reference to a structure named TAGNAME.  On
+     other systems, this construct is not supported at all.
+
+`DBX_CONTIN_LENGTH'
+     A symbol name in DBX-format debugging information is normally
+     continued (split into two separate `.stabs' directives) when it
+     exceeds a certain length (by default, 80 characters).  On some
+     operating systems, DBX requires this splitting; on others,
+     splitting must not be done.  You can inhibit splitting by defining
+     this macro with the value zero.  You can override the default
+     splitting-length by defining this macro as an expression for the
+     length you desire.
+
+`DBX_CONTIN_CHAR'
+     Normally continuation is indicated by adding a `\' character to
+     the end of a `.stabs' string when a continuation follows.  To use
+     a different character instead, define this macro as a character
+     constant for the character you want to use.  Do not define this
+     macro if backslash is correct for your system.
+
+`DBX_STATIC_STAB_DATA_SECTION'
+     Define this macro if it is necessary to go to the data section
+     before outputting the `.stabs' pseudo-op for a non-global static
+     variable.
+
+`DBX_TYPE_DECL_STABS_CODE'
+     The value to use in the "code" field of the `.stabs' directive for
+     a typedef.  The default is `N_LSYM'.
+
+`DBX_STATIC_CONST_VAR_CODE'
+     The value to use in the "code" field of the `.stabs' directive for
+     a static variable located in the text section.  DBX format does not
+     provide any "right" way to do this.  The default is `N_FUN'.
+
+`DBX_REGPARM_STABS_CODE'
+     The value to use in the "code" field of the `.stabs' directive for
+     a parameter passed in registers.  DBX format does not provide any
+     "right" way to do this.  The default is `N_RSYM'.
+
+`DBX_REGPARM_STABS_LETTER'
+     The letter to use in DBX symbol data to identify a symbol as a
+     parameter passed in registers.  DBX format does not customarily
+     provide any way to do this.  The default is `'P''.
+
+`DBX_MEMPARM_STABS_LETTER'
+     The letter to use in DBX symbol data to identify a symbol as a
+     stack parameter.  The default is `'p''.
+
+`DBX_FUNCTION_FIRST'
+     Define this macro if the DBX information for a function and its
+     arguments should precede the assembler code for the function.
+     Normally, in DBX format, the debugging information entirely
+     follows the assembler code.
+
+`DBX_LBRAC_FIRST'
+     Define this macro if the `N_LBRAC' symbol for a block should
+     precede the debugging information for variables and functions
+     defined in that block.  Normally, in DBX format, the `N_LBRAC'
+     symbol comes first.
+
+`DBX_BLOCKS_FUNCTION_RELATIVE'
+     Define this macro if the value of a symbol describing the scope of
+     a block (`N_LBRAC' or `N_RBRAC') should be relative to the start
+     of the enclosing function.  Normally, GNU C uses an absolute
+     address.
+
+`DBX_USE_BINCL'
+     Define this macro if GNU C should generate `N_BINCL' and `N_EINCL'
+     stabs for included header files, as on Sun systems.  This macro
+     also directs GNU C to output a type number as a pair of a file
+     number and a type number within the file.  Normally, GNU C does not
+     generate `N_BINCL' or `N_EINCL' stabs, and it outputs a single
+     number for a type number.
+
+
+File: gcc.info,  Node: DBX Hooks,  Next: File Names and DBX,  Prev: DBX Options,  Up: Debugging Info
+
+Open-Ended Hooks for DBX Format
+-------------------------------
+
+   These are hooks for DBX format.
+
+`DBX_OUTPUT_LBRAC (STREAM, NAME)'
+     Define this macro to say how to output to STREAM the debugging
+     information for the start of a scope level for variable names.  The
+     argument NAME is the name of an assembler symbol (for use with
+     `assemble_name') whose value is the address where the scope begins.
+
+`DBX_OUTPUT_RBRAC (STREAM, NAME)'
+     Like `DBX_OUTPUT_LBRAC', but for the end of a scope level.
+
+`DBX_OUTPUT_ENUM (STREAM, TYPE)'
+     Define this macro if the target machine requires special handling
+     to output an enumeration type.  The definition should be a C
+     statement (sans semicolon) to output the appropriate information
+     to STREAM for the type TYPE.
+
+`DBX_OUTPUT_FUNCTION_END (STREAM, FUNCTION)'
+     Define this macro if the target machine requires special output at
+     the end of the debugging information for a function.  The
+     definition should be a C statement (sans semicolon) to output the
+     appropriate information to STREAM.  FUNCTION is the
+     `FUNCTION_DECL' node for the function.
+
+`DBX_OUTPUT_STANDARD_TYPES (SYMS)'
+     Define this macro if you need to control the order of output of the
+     standard data types at the beginning of compilation.  The argument
+     SYMS is a `tree' which is a chain of all the predefined global
+     symbols, including names of data types.
+
+     Normally, DBX output starts with definitions of the types for
+     integers and characters, followed by all the other predefined
+     types of the particular language in no particular order.
+
+     On some machines, it is necessary to output different particular
+     types first.  To do this, define `DBX_OUTPUT_STANDARD_TYPES' to
+     output those symbols in the necessary order.  Any predefined types
+     that you don't explicitly output will be output afterward in no
+     particular order.
+
+     Be careful not to define this macro so that it works only for C.
+     There are no global variables to access most of the built-in
+     types, because another language may have another set of types.
+     The way to output a particular type is to look through SYMS to see
+     if you can find it.  Here is an example:
+
+          {
+            tree decl;
+            for (decl = syms; decl; decl = TREE_CHAIN (decl))
+              if (!strcmp (IDENTIFIER_POINTER (DECL_NAME (decl)),
+                           "long int"))
+                dbxout_symbol (decl);
+            ...
+          }
+
+     This does nothing if the expected type does not exist.
+
+     See the function `init_decl_processing' in `c-decl.c' to find the
+     names to use for all the built-in C types.
+
+     Here is another way of finding a particular type:
+
+          {
+            tree decl;
+            for (decl = syms; decl; decl = TREE_CHAIN (decl))
+              if (TREE_CODE (decl) == TYPE_DECL
+                  && (TREE_CODE (TREE_TYPE (decl))
+                      == INTEGER_CST)
+                  && TYPE_PRECISION (TREE_TYPE (decl)) == 16
+                  && TYPE_UNSIGNED (TREE_TYPE (decl)))
+          /* This must be `unsigned short'.  */
+                dbxout_symbol (decl);
+            ...
+          }
+
+`NO_DBX_FUNCTION_END'
+     Some stabs encapsulation formats (in particular ECOFF), cannot
+     handle the `.stabs "",N_FUN,,0,0,Lscope-function-1' gdb dbx
+     extention construct.  On those machines, define this macro to turn
+     this feature off without disturbing the rest of the gdb extensions.
+
+
+File: gcc.info,  Node: File Names and DBX,  Next: SDB and DWARF,  Prev: DBX Hooks,  Up: Debugging Info
+
+File Names in DBX Format
+------------------------
+
+   This describes file names in DBX format.
+
+`DBX_WORKING_DIRECTORY'
+     Define this if DBX wants to have the current directory recorded in
+     each object file.
+
+     Note that the working directory is always recorded if GDB
+     extensions are enabled.
+
+`DBX_OUTPUT_MAIN_SOURCE_FILENAME (STREAM, NAME)'
+     A C statement to output DBX debugging information to the stdio
+     stream STREAM which indicates that file NAME is the main source
+     file--the file specified as the input file for compilation.  This
+     macro is called only once, at the beginning of compilation.
+
+     This macro need not be defined if the standard form of output for
+     DBX debugging information is appropriate.
+
+`DBX_OUTPUT_MAIN_SOURCE_DIRECTORY (STREAM, NAME)'
+     A C statement to output DBX debugging information to the stdio
+     stream STREAM which indicates that the current directory during
+     compilation is named NAME.
+
+     This macro need not be defined if the standard form of output for
+     DBX debugging information is appropriate.
+
+`DBX_OUTPUT_MAIN_SOURCE_FILE_END (STREAM, NAME)'
+     A C statement to output DBX debugging information at the end of
+     compilation of the main source file NAME.
+
+     If you don't define this macro, nothing special is output at the
+     end of compilation, which is correct for most machines.
+
+`DBX_OUTPUT_SOURCE_FILENAME (STREAM, NAME)'
+     A C statement to output DBX debugging information to the stdio
+     stream STREAM which indicates that file NAME is the current source
+     file.  This output is generated each time input shifts to a
+     different source file as a result of `#include', the end of an
+     included file, or a `#line' command.
+
+     This macro need not be defined if the standard form of output for
+     DBX debugging information is appropriate.
+
+
+File: gcc.info,  Node: SDB and DWARF,  Prev: File Names and DBX,  Up: Debugging Info
+
+Macros for SDB and DWARF Output
+-------------------------------
+
+   Here are macros for SDB and DWARF output.
+
+`SDB_DEBUGGING_INFO'
+     Define this macro if GNU CC should produce COFF-style debugging
+     output for SDB in response to the `-g' option.
+
+`DWARF_DEBUGGING_INFO'
+     Define this macro if GNU CC should produce dwarf format debugging
+     output in response to the `-g' option.
+
+`DWARF2_DEBUGGING_INFO'
+     Define this macro if GNU CC should produce dwarf version 2 format
+     debugging output in response to the `-g' option.
+
+     To support optional call frame debugging information, you must also
+     define `INCOMING_RETURN_ADDR_RTX' and either set
+     `RTX_FRAME_RELATED_P' on the prologue insns if you use RTL for the
+     prologue, or call `dwarf2out_def_cfa' and `dwarf2out_reg_save' as
+     appropriate from `FUNCTION_PROLOGUE' if you don't.
+
+`DWARF2_FRAME_INFO'
+     Define this macro to a nonzero value if GNU CC should always output
+     Dwarf 2 frame information.  If `DWARF2_UNWIND_INFO' (*note
+     Exception Region Output::. is nonzero, GNU CC will output this
+     information not matter how you define `DWARF2_FRAME_INFO'.
+
+`LINKER_DOES_NOT_WORK_WITH_DWARF2'
+     Define this macro if the linker does not work with Dwarf version 2.
+     Normally, if the user specifies only `-ggdb' GNU CC will use Dwarf
+     version 2 if available; this macro disables this.  See the
+     description of the `PREFERRED_DEBUGGING_TYPE' macro for more
+     details.
+
+`PUT_SDB_...'
+     Define these macros to override the assembler syntax for the
+     special SDB assembler directives.  See `sdbout.c' for a list of
+     these macros and their arguments.  If the standard syntax is used,
+     you need not define them yourself.
+
+`SDB_DELIM'
+     Some assemblers do not support a semicolon as a delimiter, even
+     between SDB assembler directives.  In that case, define this macro
+     to be the delimiter to use (usually `\n').  It is not necessary to
+     define a new set of `PUT_SDB_OP' macros if this is the only change
+     required.
+
+`SDB_GENERATE_FAKE'
+     Define this macro to override the usual method of constructing a
+     dummy name for anonymous structure and union types.  See
+     `sdbout.c' for more information.
+
+`SDB_ALLOW_UNKNOWN_REFERENCES'
+     Define this macro to allow references to unknown structure, union,
+     or enumeration tags to be emitted.  Standard COFF does not allow
+     handling of unknown references, MIPS ECOFF has support for it.
+
+`SDB_ALLOW_FORWARD_REFERENCES'
+     Define this macro to allow references to structure, union, or
+     enumeration tags that have not yet been seen to be handled.  Some
+     assemblers choke if forward tags are used, while some require it.
+
+
+File: gcc.info,  Node: Cross-compilation,  Next: Misc,  Prev: Debugging Info,  Up: Target Macros
+
+Cross Compilation and Floating Point
+====================================
+
+   While all modern machines use 2's complement representation for
+integers, there are a variety of representations for floating point
+numbers.  This means that in a cross-compiler the representation of
+floating point numbers in the compiled program may be different from
+that used in the machine doing the compilation.
+
+   Because different representation systems may offer different amounts
+of range and precision, the cross compiler cannot safely use the host
+machine's floating point arithmetic.  Therefore, floating point
+constants must be represented in the target machine's format.  This
+means that the cross compiler cannot use `atof' to parse a floating
+point constant; it must have its own special routine to use instead.
+Also, constant folding must emulate the target machine's arithmetic (or
+must not be done at all).
+
+   The macros in the following table should be defined only if you are
+cross compiling between different floating point formats.
+
+   Otherwise, don't define them.  Then default definitions will be set
+up which use `double' as the data type, `==' to test for equality, etc.
+
+   You don't need to worry about how many times you use an operand of
+any of these macros.  The compiler never uses operands which have side
+effects.
+
+`REAL_VALUE_TYPE'
+     A macro for the C data type to be used to hold a floating point
+     value in the target machine's format.  Typically this would be a
+     `struct' containing an array of `int'.
+
+`REAL_VALUES_EQUAL (X, Y)'
+     A macro for a C expression which compares for equality the two
+     values, X and Y, both of type `REAL_VALUE_TYPE'.
+
+`REAL_VALUES_LESS (X, Y)'
+     A macro for a C expression which tests whether X is less than Y,
+     both values being of type `REAL_VALUE_TYPE' and interpreted as
+     floating point numbers in the target machine's representation.
+
+`REAL_VALUE_LDEXP (X, SCALE)'
+     A macro for a C expression which performs the standard library
+     function `ldexp', but using the target machine's floating point
+     representation.  Both X and the value of the expression have type
+     `REAL_VALUE_TYPE'.  The second argument, SCALE, is an integer.
+
+`REAL_VALUE_FIX (X)'
+     A macro whose definition is a C expression to convert the
+     target-machine floating point value X to a signed integer.  X has
+     type `REAL_VALUE_TYPE'.
+
+`REAL_VALUE_UNSIGNED_FIX (X)'
+     A macro whose definition is a C expression to convert the
+     target-machine floating point value X to an unsigned integer.  X
+     has type `REAL_VALUE_TYPE'.
+
+`REAL_VALUE_RNDZINT (X)'
+     A macro whose definition is a C expression to round the
+     target-machine floating point value X towards zero to an integer
+     value (but still as a floating point number).  X has type
+     `REAL_VALUE_TYPE', and so does the value.
+
+`REAL_VALUE_UNSIGNED_RNDZINT (X)'
+     A macro whose definition is a C expression to round the
+     target-machine floating point value X towards zero to an unsigned
+     integer value (but still represented as a floating point number).
+     X has type `REAL_VALUE_TYPE', and so does the value.
+
+`REAL_VALUE_ATOF (STRING, MODE)'
+     A macro for a C expression which converts STRING, an expression of
+     type `char *', into a floating point number in the target machine's
+     representation for mode MODE.  The value has type
+     `REAL_VALUE_TYPE'.
+
+`REAL_INFINITY'
+     Define this macro if infinity is a possible floating point value,
+     and therefore division by 0 is legitimate.
+
+`REAL_VALUE_ISINF (X)'
+     A macro for a C expression which determines whether X, a floating
+     point value, is infinity.  The value has type `int'.  By default,
+     this is defined to call `isinf'.
+
+`REAL_VALUE_ISNAN (X)'
+     A macro for a C expression which determines whether X, a floating
+     point value, is a "nan" (not-a-number).  The value has type `int'.
+     By default, this is defined to call `isnan'.
+
+   Define the following additional macros if you want to make floating
+point constant folding work while cross compiling.  If you don't define
+them, cross compilation is still possible, but constant folding will
+not happen for floating point values.
+
+`REAL_ARITHMETIC (OUTPUT, CODE, X, Y)'
+     A macro for a C statement which calculates an arithmetic operation
+     of the two floating point values X and Y, both of type
+     `REAL_VALUE_TYPE' in the target machine's representation, to
+     produce a result of the same type and representation which is
+     stored in OUTPUT (which will be a variable).
+
+     The operation to be performed is specified by CODE, a tree code
+     which will always be one of the following: `PLUS_EXPR',
+     `MINUS_EXPR', `MULT_EXPR', `RDIV_EXPR', `MAX_EXPR', `MIN_EXPR'.
+
+     The expansion of this macro is responsible for checking for
+     overflow.  If overflow happens, the macro expansion should execute
+     the statement `return 0;', which indicates the inability to
+     perform the arithmetic operation requested.
+
+`REAL_VALUE_NEGATE (X)'
+     A macro for a C expression which returns the negative of the
+     floating point value X.  Both X and the value of the expression
+     have type `REAL_VALUE_TYPE' and are in the target machine's
+     floating point representation.
+
+     There is no way for this macro to report overflow, since overflow
+     can't happen in the negation operation.
+
+`REAL_VALUE_TRUNCATE (MODE, X)'
+     A macro for a C expression which converts the floating point value
+     X to mode MODE.
+
+     Both X and the value of the expression are in the target machine's
+     floating point representation and have type `REAL_VALUE_TYPE'.
+     However, the value should have an appropriate bit pattern to be
+     output properly as a floating constant whose precision accords
+     with mode MODE.
+
+     There is no way for this macro to report overflow.
+
+`REAL_VALUE_TO_INT (LOW, HIGH, X)'
+     A macro for a C expression which converts a floating point value X
+     into a double-precision integer which is then stored into LOW and
+     HIGH, two variables of type INT.
+
+`REAL_VALUE_FROM_INT (X, LOW, HIGH, MODE)'
+     A macro for a C expression which converts a double-precision
+     integer found in LOW and HIGH, two variables of type INT, into a
+     floating point value which is then stored into X.  The value is in
+     the target machine's representation for mode MODE and has the type
+     `REAL_VALUE_TYPE'.
+

usr/local/nachos/info/gcc.info-29

@@ -0,0 +1,535 @@
+This is Info file gcc.info, produced by Makeinfo version 1.68 from the
+input file ../../gcc-2.95.2/gcc/gcc.texi.
+
+INFO-DIR-SECTION Programming
+START-INFO-DIR-ENTRY
+* gcc: (gcc).                  The GNU Compiler Collection.
+END-INFO-DIR-ENTRY
+   This file documents the use and the internals of the GNU compiler.
+
+   Published by the Free Software Foundation 59 Temple Place - Suite 330
+Boston, MA 02111-1307 USA
+
+   Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
+1999 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 sections entitled "GNU General Public License" and "Funding
+for Free Software" are included exactly as in the original, and
+provided 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, except that the sections entitled "GNU General Public
+License" and "Funding for Free Software", and this permission notice,
+may be included in translations approved by the Free Software Foundation
+instead of in the original English.
+
+
+File: gcc.info,  Node: Copying,  Next: Contributors,  Prev: GNU/Linux,  Up: Top
+
+GNU GENERAL PUBLIC LICENSE
+**************************
+
+                         Version 2, June 1991
+
+     Copyright (C) 1989, 1991 Free Software Foundation, Inc.
+     59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
+     
+     Everyone is permitted to copy and distribute verbatim copies
+     of this license document, but changing it is not allowed.
+
+Preamble
+========
+
+   The licenses for most software are designed to take away your
+freedom to share and change it.  By contrast, the GNU General Public
+License is intended to guarantee your freedom to share and change free
+software--to make sure the software is free for all its users.  This
+General Public License applies to most of the Free Software
+Foundation's software and to any other program whose authors commit to
+using it.  (Some other Free Software Foundation software is covered by
+the GNU Library General Public License instead.)  You can apply it to
+your programs, too.
+
+   When we speak of free software, we are referring to freedom, not
+price.  Our General Public Licenses are designed to make sure that you
+have the freedom to distribute copies of free software (and charge for
+this service if you wish), that you receive source code or can get it
+if you want it, that you can change the software or use pieces of it in
+new free programs; and that you know you can do these things.
+
+   To protect your rights, we need to make restrictions that forbid
+anyone to deny you these rights or to ask you to surrender the rights.
+These restrictions translate to certain responsibilities for you if you
+distribute copies of the software, or if you modify it.
+
+   For example, if you distribute copies of such a program, whether
+gratis or for a fee, you must give the recipients all the rights that
+you have.  You must make sure that they, too, receive or can get the
+source code.  And you must show them these terms so they know their
+rights.
+
+   We protect your rights with two steps: (1) copyright the software,
+and (2) offer you this license which gives you legal permission to copy,
+distribute and/or modify the software.
+
+   Also, for each author's protection and ours, we want to make certain
+that everyone understands that there is no warranty for this free
+software.  If the software is modified by someone else and passed on, we
+want its recipients to know that what they have is not the original, so
+that any problems introduced by others will not reflect on the original
+authors' reputations.
+
+   Finally, any free program is threatened constantly by software
+patents.  We wish to avoid the danger that redistributors of a free
+program will individually obtain patent licenses, in effect making the
+program proprietary.  To prevent this, we have made it clear that any
+patent must be licensed for everyone's free use or not licensed at all.
+
+   The precise terms and conditions for copying, distribution and
+modification follow.
+
+    TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
+
+  0. This License applies to any program or other work which contains a
+     notice placed by the copyright holder saying it may be distributed
+     under the terms of this General Public License.  The "Program",
+     below, refers to any such program or work, and a "work based on
+     the Program" means either the Program or any derivative work under
+     copyright law: that is to say, a work containing the Program or a
+     portion of it, either verbatim or with modifications and/or
+     translated into another language.  (Hereinafter, translation is
+     included without limitation in the term "modification".)  Each
+     licensee is addressed as "you".
+
+     Activities other than copying, distribution and modification are
+     not covered by this License; they are outside its scope.  The act
+     of running the Program is not restricted, and the output from the
+     Program is covered only if its contents constitute a work based on
+     the Program (independent of having been made by running the
+     Program).  Whether that is true depends on what the Program does.
+
+  1. You may copy and distribute verbatim copies of the Program's
+     source code as you receive it, in any medium, provided that you
+     conspicuously and appropriately publish on each copy an appropriate
+     copyright notice and disclaimer of warranty; keep intact all the
+     notices that refer to this License and to the absence of any
+     warranty; and give any other recipients of the Program a copy of
+     this License along with the Program.
+
+     You may charge a fee for the physical act of transferring a copy,
+     and you may at your option offer warranty protection in exchange
+     for a fee.
+
+  2. You may modify your copy or copies of the Program or any portion
+     of it, thus forming a work based on the Program, and copy and
+     distribute such modifications or work under the terms of Section 1
+     above, provided that you also meet all of these conditions:
+
+       a. You must cause the modified files to carry prominent notices
+          stating that you changed the files and the date of any change.
+
+       b. You must cause any work that you distribute or publish, that
+          in whole or in part contains or is derived from the Program
+          or any part thereof, to be licensed as a whole at no charge
+          to all third parties under the terms of this License.
+
+       c. If the modified program normally reads commands interactively
+          when run, you must cause it, when started running for such
+          interactive use in the most ordinary way, to print or display
+          an announcement including an appropriate copyright notice and
+          a notice that there is no warranty (or else, saying that you
+          provide a warranty) and that users may redistribute the
+          program under these conditions, and telling the user how to
+          view a copy of this License.  (Exception: if the Program
+          itself is interactive but does not normally print such an
+          announcement, your work based on the Program is not required
+          to print an announcement.)
+
+     These requirements apply to the modified work as a whole.  If
+     identifiable sections of that work are not derived from the
+     Program, and can be reasonably considered independent and separate
+     works in themselves, then this License, and its terms, do not
+     apply to those sections when you distribute them as separate
+     works.  But when you distribute the same sections as part of a
+     whole which is a work based on the Program, the distribution of
+     the whole must be on the terms of this License, whose permissions
+     for other licensees extend to the entire whole, and thus to each
+     and every part regardless of who wrote it.
+
+     Thus, it is not the intent of this section to claim rights or
+     contest your rights to work written entirely by you; rather, the
+     intent is to exercise the right to control the distribution of
+     derivative or collective works based on the Program.
+
+     In addition, mere aggregation of another work not based on the
+     Program with the Program (or with a work based on the Program) on
+     a volume of a storage or distribution medium does not bring the
+     other work under the scope of this License.
+
+  3. You may copy and distribute the Program (or a work based on it,
+     under Section 2) in object code or executable form under the terms
+     of Sections 1 and 2 above provided that you also do one of the
+     following:
+
+       a. Accompany it with the complete corresponding machine-readable
+          source code, which must be distributed under the terms of
+          Sections 1 and 2 above on a medium customarily used for
+          software interchange; or,
+
+       b. Accompany it with a written offer, valid for at least three
+          years, to give any third party, for a charge no more than your
+          cost of physically performing source distribution, a complete
+          machine-readable copy of the corresponding source code, to be
+          distributed under the terms of Sections 1 and 2 above on a
+          medium customarily used for software interchange; or,
+
+       c. Accompany it with the information you received as to the offer
+          to distribute corresponding source code.  (This alternative is
+          allowed only for noncommercial distribution and only if you
+          received the program in object code or executable form with
+          such an offer, in accord with Subsection b above.)
+
+     The source code for a work means the preferred form of the work for
+     making modifications to it.  For an executable work, complete
+     source code means all the source code for all modules it contains,
+     plus any associated interface definition files, plus the scripts
+     used to control compilation and installation of the executable.
+     However, as a special exception, the source code distributed need
+     not include anything that is normally distributed (in either
+     source or binary form) with the major components (compiler,
+     kernel, and so on) of the operating system on which the executable
+     runs, unless that component itself accompanies the executable.
+
+     If distribution of executable or object code is made by offering
+     access to copy from a designated place, then offering equivalent
+     access to copy the source code from the same place counts as
+     distribution of the source code, even though third parties are not
+     compelled to copy the source along with the object code.
+
+  4. You may not copy, modify, sublicense, or distribute the Program
+     except as expressly provided under this License.  Any attempt
+     otherwise to copy, modify, sublicense or distribute the Program is
+     void, and will automatically terminate your rights under this
+     License.  However, parties who have received copies, or rights,
+     from you under this License will not have their licenses
+     terminated so long as such parties remain in full compliance.
+
+  5. You are not required to accept this License, since you have not
+     signed it.  However, nothing else grants you permission to modify
+     or distribute the Program or its derivative works.  These actions
+     are prohibited by law if you do not accept this License.
+     Therefore, by modifying or distributing the Program (or any work
+     based on the Program), you indicate your acceptance of this
+     License to do so, and all its terms and conditions for copying,
+     distributing or modifying the Program or works based on it.
+
+  6. Each time you redistribute the Program (or any work based on the
+     Program), the recipient automatically receives a license from the
+     original licensor to copy, distribute or modify the Program
+     subject to these terms and conditions.  You may not impose any
+     further restrictions on the recipients' exercise of the rights
+     granted herein.  You are not responsible for enforcing compliance
+     by third parties to this License.
+
+  7. If, as a consequence of a court judgment or allegation of patent
+     infringement or for any other reason (not limited to patent
+     issues), conditions are imposed on you (whether by court order,
+     agreement or otherwise) that contradict the conditions of this
+     License, they do not excuse you from the conditions of this
+     License.  If you cannot distribute so as to satisfy simultaneously
+     your obligations under this License and any other pertinent
+     obligations, then as a consequence you may not distribute the
+     Program at all.  For example, if a patent license would not permit
+     royalty-free redistribution of the Program by all those who
+     receive copies directly or indirectly through you, then the only
+     way you could satisfy both it and this License would be to refrain
+     entirely from distribution of the Program.
+
+     If any portion of this section is held invalid or unenforceable
+     under any particular circumstance, the balance of the section is
+     intended to apply and the section as a whole is intended to apply
+     in other circumstances.
+
+     It is not the purpose of this section to induce you to infringe any
+     patents or other property right claims or to contest validity of
+     any such claims; this section has the sole purpose of protecting
+     the integrity of the free software distribution system, which is
+     implemented by public license practices.  Many people have made
+     generous contributions to the wide range of software distributed
+     through that system in reliance on consistent application of that
+     system; it is up to the author/donor to decide if he or she is
+     willing to distribute software through any other system and a
+     licensee cannot impose that choice.
+
+     This section is intended to make thoroughly clear what is believed
+     to be a consequence of the rest of this License.
+
+  8. If the distribution and/or use of the Program is restricted in
+     certain countries either by patents or by copyrighted interfaces,
+     the original copyright holder who places the Program under this
+     License may add an explicit geographical distribution limitation
+     excluding those countries, so that distribution is permitted only
+     in or among countries not thus excluded.  In such case, this
+     License incorporates the limitation as if written in the body of
+     this License.
+
+  9. The Free Software Foundation may publish revised and/or new
+     versions of the General Public License from time to time.  Such
+     new versions will be similar in spirit to the present version, but
+     may differ in detail to address new problems or concerns.
+
+     Each version is given a distinguishing version number.  If the
+     Program specifies a version number of this License which applies
+     to it and "any later version", you have the option of following
+     the terms and conditions either of that version or of any later
+     version published by the Free Software Foundation.  If the Program
+     does not specify a version number of this License, you may choose
+     any version ever published by the Free Software Foundation.
+
+ 10. If you wish to incorporate parts of the Program into other free
+     programs whose distribution conditions are different, write to the
+     author to ask for permission.  For software which is copyrighted
+     by the Free Software Foundation, write to the Free Software
+     Foundation; we sometimes make exceptions for this.  Our decision
+     will be guided by the two goals of preserving the free status of
+     all derivatives of our free software and of promoting the sharing
+     and reuse of software generally.
+
+                                NO WARRANTY
+
+ 11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO
+     WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE
+     LAW.  EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT
+     HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT
+     WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT
+     NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
+     FITNESS FOR A PARTICULAR PURPOSE.  THE ENTIRE RISK AS TO THE
+     QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU.  SHOULD THE
+     PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY
+     SERVICING, REPAIR OR CORRECTION.
+
+ 12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN
+     WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY
+     MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE
+     LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL,
+     INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR
+     INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF
+     DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU
+     OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY
+     OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN
+     ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
+
+                      END OF TERMS AND CONDITIONS
+
+How to Apply These Terms to Your New Programs
+=============================================
+
+   If you develop a new program, and you want it to be of the greatest
+possible use to the public, the best way to achieve this is to make it
+free software which everyone can redistribute and change under these
+terms.
+
+   To do so, attach the following notices to the program.  It is safest
+to attach them to the start of each source file to most effectively
+convey the exclusion of warranty; and each file should have at least
+the "copyright" line and a pointer to where the full notice is found.
+
+     ONE LINE TO GIVE THE PROGRAM'S NAME AND A BRIEF IDEA OF WHAT IT DOES.
+     Copyright (C) YYYY  NAME OF AUTHOR
+     
+     This program is free software; you can redistribute it and/or modify
+     it under the terms of the GNU General Public License as published by
+     the Free Software Foundation; either version 2 of the License, or
+     (at your option) any later version.
+     
+     This program is distributed in the hope that it will be useful,
+     but WITHOUT ANY WARRANTY; without even the implied warranty of
+     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+     GNU General Public License for more details.
+     
+     You should have received a copy of the GNU General Public License
+     along with this program; if not, write to the Free Software
+     Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+
+   Also add information on how to contact you by electronic and paper
+mail.
+
+   If the program is interactive, make it output a short notice like
+this when it starts in an interactive mode:
+
+     Gnomovision version 69, Copyright (C) YYYY NAME OF AUTHOR
+     Gnomovision comes with ABSOLUTELY NO WARRANTY; for details
+     type `show w'.
+     This is free software, and you are welcome to redistribute it
+     under certain conditions; type `show c' for details.
+
+   The hypothetical commands `show w' and `show c' should show the
+appropriate parts of the General Public License.  Of course, the
+commands you use may be called something other than `show w' and `show
+c'; they could even be mouse-clicks or menu items--whatever suits your
+program.
+
+   You should also get your employer (if you work as a programmer) or
+your school, if any, to sign a "copyright disclaimer" for the program,
+if necessary.  Here is a sample; alter the names:
+
+     Yoyodyne, Inc., hereby disclaims all copyright interest in the program
+     `Gnomovision' (which makes passes at compilers) written by James Hacker.
+     
+     SIGNATURE OF TY COON, 1 April 1989
+     Ty Coon, President of Vice
+
+   This General Public License does not permit incorporating your
+program into proprietary programs.  If your program is a subroutine
+library, you may consider it more useful to permit linking proprietary
+applications with the library.  If this is what you want to do, use the
+GNU Library General Public License instead of this License.
+
+
+File: gcc.info,  Node: Contributors,  Next: Index,  Prev: Copying,  Up: Top
+
+Contributors to GCC
+*******************
+
+   In addition to Richard Stallman, several people have written parts
+of GCC.
+
+   * The idea of using RTL and some of the optimization ideas came from
+     the program PO written at the University of Arizona by Jack
+     Davidson and Christopher Fraser.  See "Register Allocation and
+     Exhaustive Peephole Optimization", Software Practice and
+     Experience 14 (9), Sept. 1984, 857-866.
+
+   * Paul Rubin wrote most of the preprocessor.
+
+   * Leonard Tower wrote parts of the parser, RTL generator, and RTL
+     definitions, and of the Vax machine description.
+
+   * Ted Lemon wrote parts of the RTL reader and printer.
+
+   * Jim Wilson implemented loop strength reduction and some other loop
+     optimizations.
+
+   * Nobuyuki Hikichi of Software Research Associates, Tokyo,
+     contributed the support for the Sony NEWS machine.
+
+   * Charles LaBrec contributed the support for the Integrated Solutions
+     68020 system.
+
+   * Michael Tiemann of Cygnus Support wrote the front end for C++, as
+     well as the support for inline functions and instruction
+     scheduling.  Also the descriptions of the National Semiconductor
+     32000 series cpu, the SPARC cpu and part of the Motorola 88000 cpu.
+
+   * Gerald Baumgartner added the signature extension to the C++
+     front-end.
+
+   * Jan Stein of the Chalmers Computer Society provided support for
+     Genix, as well as part of the 32000 machine description.
+
+   * Randy Smith finished the Sun FPA support.
+
+   * Robert Brown implemented the support for Encore 32000 systems.
+
+   * David Kashtan of SRI adapted GCC to VMS.
+
+   * Alex Crain provided changes for the 3b1.
+
+   * Greg Satz and Chris Hanson assisted in making GCC work on HP-UX for
+     the 9000 series 300.
+
+   * William Schelter did most of the work on the Intel 80386 support.
+
+   * Christopher Smith did the port for Convex machines.
+
+   * Paul Petersen wrote the machine description for the Alliant FX/8.
+
+   * Dario Dariol contributed the four varieties of sample programs
+     that print a copy of their source.
+
+   * Alain Lichnewsky ported GCC to the Mips cpu.
+
+   * Devon Bowen, Dale Wiles and Kevin Zachmann ported GCC to the Tahoe.
+
+   * Jonathan Stone wrote the machine description for the Pyramid
+     computer.
+
+   * Gary Miller ported GCC to Charles River Data Systems machines.
+
+   * 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.
+
+   * Richard Kenner and Michael Tiemann jointly developed reorg.c, the
+     delay slot scheduler.
+
+   * Mike Meissner and Tom Wood of Data General finished the port to the
+     Motorola 88000.
+
+   * Masanobu Yuhara of Fujitsu Laboratories implemented the machine
+     description for the Tron architecture (specifically, the Gmicro).
+
+   * NeXT, Inc. donated the front end that supports the Objective C
+     language.
+
+   * James van Artsdalen wrote the code that makes efficient use of the
+     Intel 80387 register stack.
+
+   * Mike Meissner at the Open Software Foundation finished the port to
+     the MIPS cpu, including adding ECOFF debug support, and worked on
+     the Intel port for the Intel 80386 cpu.  Later at Cygnus Support,
+     he worked on the rs6000 and PowerPC ports.
+
+   * Ron Guilmette implemented the `protoize' and `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.
+
+   * Torbjorn Granlund implemented multiply- and divide-by-constant
+     optimization, improved long long support, and improved leaf
+     function register allocation.
+
+   * Mike Stump implemented the support for Elxsi 64 bit CPU.
+
+   * John Wehle added the machine description for the Western Electric
+     32000 processor used in several 3b series machines (no relation to
+     the National Semiconductor 32000 processor).
+
+   * Holger Teutsch provided the support for the Clipper cpu.
+
+   * Kresten Krab Thorup wrote the run time support for the Objective C
+     language.
+
+   * Stephen Moshier contributed the floating point emulator that
+     assists in cross-compilation and permits support for floating
+     point numbers wider than 64 bits.
+
+   * David Edelsohn contributed the changes to RS/6000 port to make it
+     support the PowerPC and POWER2 architectures.
+
+   * Steve Chamberlain wrote the support for the Hitachi SH processor.
+
+   * Peter Schauer wrote the code to allow debugging to work on the
+     Alpha.
+
+   * Oliver M. Kellogg of Deutsche Aerospace contributed the port to the
+     MIL-STD-1750A.
+
+   * Michael K. Gschwind contributed the port to the PDP-11.
+
+   * David Reese of Sun Microsystems contributed to the Solaris on
+     PowerPC port.
+

usr/local/nachos/info/gcc.info-7

@@ -0,0 +1,943 @@
+This is Info file gcc.info, produced by Makeinfo version 1.68 from the
+input file ../../gcc-2.95.2/gcc/gcc.texi.
+
+INFO-DIR-SECTION Programming
+START-INFO-DIR-ENTRY
+* gcc: (gcc).                  The GNU Compiler Collection.
+END-INFO-DIR-ENTRY
+   This file documents the use and the internals of the GNU compiler.
+
+   Published by the Free Software Foundation 59 Temple Place - Suite 330
+Boston, MA 02111-1307 USA
+
+   Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
+1999 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 sections entitled "GNU General Public License" and "Funding
+for Free Software" are included exactly as in the original, and
+provided 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, except that the sections entitled "GNU General Public
+License" and "Funding for Free Software", and this permission notice,
+may be included in translations approved by the Free Software Foundation
+instead of in the original English.
+
+
+File: gcc.info,  Node: Environment Variables,  Next: Running Protoize,  Prev: Code Gen Options,  Up: Invoking GCC
+
+Environment Variables Affecting GCC
+===================================
+
+   This section describes several environment variables that affect how
+GCC operates.  Some of them work by specifying directories or prefixes
+to use when searching for various kinds of files. Some are used to
+specify other aspects of the compilation environment.
+
+   Note that you can also specify places to search using options such as
+`-B', `-I' and `-L' (*note Directory Options::.).  These take
+precedence over places specified using environment variables, which in
+turn take precedence over those specified by the configuration of GCC.
+*Note Driver::.
+
+`LANG'
+`LC_CTYPE'
+`LC_MESSAGES'
+`LC_ALL'
+     These environment variables control the way that GCC uses
+     localization information that allow GCC to work with different
+     national conventions.  GCC inspects the locale categories
+     `LC_CTYPE' and `LC_MESSAGES' if it has been configured to do so.
+     These locale categories can be set to any value supported by your
+     installation.  A typical value is `en_UK' for English in the United
+     Kingdom.
+
+     The `LC_CTYPE' environment variable specifies character
+     classification.  GCC uses it to determine the character boundaries
+     in a string; this is needed for some multibyte encodings that
+     contain quote and escape characters that would otherwise be
+     interpreted as a string end or escape.
+
+     The `LC_MESSAGES' environment variable specifies the language to
+     use in diagnostic messages.
+
+     If the `LC_ALL' environment variable is set, it overrides the value
+     of `LC_CTYPE' and `LC_MESSAGES'; otherwise, `LC_CTYPE' and
+     `LC_MESSAGES' default to the value of the `LANG' environment
+     variable.  If none of these variables are set, GCC defaults to
+     traditional C English behavior.
+
+`TMPDIR'
+     If `TMPDIR' is set, it specifies the directory to use for temporary
+     files.  GCC uses temporary files to hold the output of one stage of
+     compilation which is to be used as input to the next stage: for
+     example, the output of the preprocessor, which is the input to the
+     compiler proper.
+
+`GCC_EXEC_PREFIX'
+     If `GCC_EXEC_PREFIX' is set, it specifies a prefix to use in the
+     names of the subprograms executed by the compiler.  No slash is
+     added when this prefix is combined with the name of a subprogram,
+     but you can specify a prefix that ends with a slash if you wish.
+
+     If GCC cannot find the subprogram using the specified prefix, it
+     tries looking in the usual places for the subprogram.
+
+     The default value of `GCC_EXEC_PREFIX' is `PREFIX/lib/gcc-lib/'
+     where PREFIX is the value of `prefix' when you ran the `configure'
+     script.
+
+     Other prefixes specified with `-B' take precedence over this
+     prefix.
+
+     This prefix is also used for finding files such as `crt0.o' that
+     are used for linking.
+
+     In addition, the prefix is used in an unusual way in finding the
+     directories to search for header files.  For each of the standard
+     directories whose name normally begins with
+     `/usr/local/lib/gcc-lib' (more precisely, with the value of
+     `GCC_INCLUDE_DIR'), GCC tries replacing that beginning with the
+     specified prefix to produce an alternate directory name.  Thus,
+     with `-Bfoo/', GCC will search `foo/bar' where it would normally
+     search `/usr/local/lib/bar'.  These alternate directories are
+     searched first; the standard directories come next.
+
+`COMPILER_PATH'
+     The value of `COMPILER_PATH' is a colon-separated list of
+     directories, much like `PATH'.  GCC tries the directories thus
+     specified when searching for subprograms, if it can't find the
+     subprograms using `GCC_EXEC_PREFIX'.
+
+`LIBRARY_PATH'
+     The value of `LIBRARY_PATH' is a colon-separated list of
+     directories, much like `PATH'.  When configured as a native
+     compiler, GCC tries the directories thus specified when searching
+     for special linker files, if it can't find them using
+     `GCC_EXEC_PREFIX'.  Linking using GCC also uses these directories
+     when searching for ordinary libraries for the `-l' option (but
+     directories specified with `-L' come first).
+
+`C_INCLUDE_PATH'
+`CPLUS_INCLUDE_PATH'
+`OBJC_INCLUDE_PATH'
+     These environment variables pertain to particular languages.  Each
+     variable's value is a colon-separated list of directories, much
+     like `PATH'.  When GCC searches for header files, it tries the
+     directories listed in the variable for the language you are using,
+     after the directories specified with `-I' but before the standard
+     header file directories.
+
+`DEPENDENCIES_OUTPUT'
+     If this variable is set, its value specifies how to output
+     dependencies for Make based on the header files processed by the
+     compiler.  This output looks much like the output from the `-M'
+     option (*note Preprocessor Options::.), but it goes to a separate
+     file, and is in addition to the usual results of compilation.
+
+     The value of `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 `FILE TARGET', in which case the rules are written to file
+     FILE using TARGET as the target name.
+
+`LANG'
+     This variable is used to pass locale information to the compiler.
+     One way in which this information is used is to determine the
+     character set to be used when character literals, string literals
+     and comments are parsed in C and C++.  When the compiler is
+     configured to allow multibyte characters, the following values for
+     `LANG' are recognized:
+
+    `C-JIS'
+          Recognize JIS characters.
+
+    `C-SJIS'
+          Recognize SJIS characters.
+
+    `C-EUCJP'
+          Recognize EUCJP characters.
+
+     If `LANG' is not defined, or if it has some other value, then the
+     compiler will use mblen and mbtowc as defined by the default
+     locale to recognize and translate multibyte characters.
+
+
+File: gcc.info,  Node: Running Protoize,  Prev: Environment Variables,  Up: Invoking GCC
+
+Running Protoize
+================
+
+   The program `protoize' is an optional part of GNU C.  You can use it
+to add prototypes to a program, thus converting the program to ANSI C
+in one respect.  The companion program `unprotoize' does the reverse:
+it removes argument types from any prototypes that are found.
+
+   When you run these programs, you must specify a set of source files
+as command line arguments.  The conversion programs start out by
+compiling these files to see what functions they define.  The
+information gathered about a file FOO is saved in a file named `FOO.X'.
+
+   After scanning comes actual conversion.  The specified files are all
+eligible to be converted; any files they include (whether sources or
+just headers) are eligible as well.
+
+   But not all the eligible files are converted.  By default,
+`protoize' and `unprotoize' convert only source and header files in the
+current directory.  You can specify additional directories whose files
+should be converted with the `-d DIRECTORY' option.  You can also
+specify particular files to exclude with the `-x FILE' option.  A file
+is converted if it is eligible, its directory name matches one of the
+specified directory names, and its name within the directory has not
+been excluded.
+
+   Basic conversion with `protoize' consists of rewriting most function
+definitions and function declarations to specify the types of the
+arguments.  The only ones not rewritten are those for varargs functions.
+
+   `protoize' optionally inserts prototype declarations at the
+beginning of the source file, to make them available for any calls that
+precede the function's definition.  Or it can insert prototype
+declarations with block scope in the blocks where undeclared functions
+are called.
+
+   Basic conversion with `unprotoize' consists of rewriting most
+function declarations to remove any argument types, and rewriting
+function definitions to the old-style pre-ANSI form.
+
+   Both conversion programs print a warning for any function
+declaration or definition that they can't convert.  You can suppress
+these warnings with `-q'.
+
+   The output from `protoize' or `unprotoize' replaces the original
+source file.  The original file is renamed to a name ending with
+`.save'.  If the `.save' file already exists, then the source file is
+simply discarded.
+
+   `protoize' and `unprotoize' both depend on GCC itself to scan the
+program and collect information about the functions it uses.  So
+neither of these programs will work until GCC is installed.
+
+   Here is a table of the options you can use with `protoize' and
+`unprotoize'.  Each option works with both programs unless otherwise
+stated.
+
+`-B DIRECTORY'
+     Look for the file `SYSCALLS.c.X' in DIRECTORY, instead of the
+     usual directory (normally `/usr/local/lib').  This file contains
+     prototype information about standard system functions.  This option
+     applies only to `protoize'.
+
+`-c COMPILATION-OPTIONS'
+     Use  COMPILATION-OPTIONS as the options when running `gcc' to
+     produce the `.X' files.  The special option `-aux-info' is always
+     passed in addition, to tell `gcc' to write a `.X' file.
+
+     Note that the compilation options must be given as a single
+     argument to `protoize' or `unprotoize'.  If you want to specify
+     several `gcc' options, you must quote the entire set of
+     compilation options to make them a single word in the shell.
+
+     There are certain `gcc' arguments that you cannot use, because they
+     would produce the wrong kind of output.  These include `-g', `-O',
+     `-c', `-S', and `-o' If you include these in the
+     COMPILATION-OPTIONS, they are ignored.
+
+`-C'
+     Rename files to end in `.C' instead of `.c'.  This is convenient
+     if you are converting a C program to C++.  This option applies
+     only to `protoize'.
+
+`-g'
+     Add explicit global declarations.  This means inserting explicit
+     declarations at the beginning of each source file for each function
+     that is called in the file and was not declared.  These
+     declarations precede the first function definition that contains a
+     call to an undeclared function.  This option applies only to
+     `protoize'.
+
+`-i STRING'
+     Indent old-style parameter declarations with the string STRING.
+     This option applies only to `protoize'.
+
+     `unprotoize' converts prototyped function definitions to old-style
+     function definitions, where the arguments are declared between the
+     argument list and the initial `{'.  By default, `unprotoize' uses
+     five spaces as the indentation.  If you want to indent with just
+     one space instead, use `-i " "'.
+
+`-k'
+     Keep the `.X' files.  Normally, they are deleted after conversion
+     is finished.
+
+`-l'
+     Add explicit local declarations.  `protoize' with `-l' inserts a
+     prototype declaration for each function in each block which calls
+     the function without any declaration.  This option applies only to
+     `protoize'.
+
+`-n'
+     Make no real changes.  This mode just prints information about the
+     conversions that would have been done without `-n'.
+
+`-N'
+     Make no `.save' files.  The original files are simply deleted.
+     Use this option with caution.
+
+`-p PROGRAM'
+     Use the program PROGRAM as the compiler.  Normally, the name `gcc'
+     is used.
+
+`-q'
+     Work quietly.  Most warnings are suppressed.
+
+`-v'
+     Print the version number, just like `-v' for `gcc'.
+
+   If you need special compiler options to compile one of your program's
+source files, then you should generate that file's `.X' file specially,
+by running `gcc' on that source file with the appropriate options and
+the option `-aux-info'.  Then run `protoize' on the entire set of
+files.  `protoize' will use the existing `.X' file because it is newer
+than the source file.  For example:
+
+     gcc -Dfoo=bar file1.c -aux-info
+     protoize *.c
+
+You need to include the special files along with the rest in the
+`protoize' command, even though their `.X' files already exist, because
+otherwise they won't get converted.
+
+   *Note Protoize Caveats::, for more information on how to use
+`protoize' successfully.
+
+   Note most of this information is out of date and superceded by the
+EGCS install procedures.  It is provided for historical reference only.
+
+
+File: gcc.info,  Node: Installation,  Next: C Extensions,  Prev: Invoking GCC,  Up: Top
+
+Installing GNU CC
+*****************
+
+* Menu:
+
+* Configuration Files::  Files created by running `configure'.
+* Configurations::    Configurations Supported by GNU CC.
+* Other Dir::     Compiling in a separate directory (not where the source is).
+* Cross-Compiler::   Building and installing a cross-compiler.
+* Sun Install::   See below for installation on the Sun.
+* VMS Install::   See below for installation on VMS.
+* Collect2::	  How `collect2' works; how it finds `ld'.
+* Header Dirs::   Understanding the standard header file directories.
+
+   Here is the procedure for installing GNU CC on a GNU or Unix system.
+See *Note VMS Install::, for VMS systems.  In this section we assume you
+compile in the same directory that contains the source files; see *Note
+Other Dir::, to find out how to compile in a separate directory on Unix
+systems.
+
+   You cannot install GNU C by itself on MSDOS; it will not compile
+under any MSDOS compiler except itself.  You need to get the complete
+compilation package DJGPP, which includes binaries as well as sources,
+and includes all the necessary compilation tools and libraries.
+
+  1. If you have built GNU CC previously in the same directory for a
+     different target machine, do `make distclean' to delete all files
+     that might be invalid.  One of the files this deletes is
+     `Makefile'; if `make distclean' complains that `Makefile' does not
+     exist, it probably means that the directory is already suitably
+     clean.
+
+  2. On a System V release 4 system, make sure `/usr/bin' precedes
+     `/usr/ucb' in `PATH'.  The `cc' command in `/usr/ucb' uses
+     libraries which have bugs.
+
+  3. Make sure the Bison parser generator is installed.  (This is
+     unnecessary if the Bison output files `c-parse.c' and `cexp.c' are
+     more recent than `c-parse.y' and `cexp.y' and you do not plan to
+     change the `.y' files.)
+
+     Bison versions older than Sept 8, 1988 will produce incorrect
+     output for `c-parse.c'.
+
+  4. If you have chosen a configuration for GNU CC which requires other
+     GNU tools (such as GAS or the GNU linker) instead of the standard
+     system tools, install the required tools in the build directory
+     under the names `as', `ld' or whatever is appropriate.  This will
+     enable the compiler to find the proper tools for compilation of
+     the program `enquire'.
+
+     Alternatively, you can do subsequent compilation using a value of
+     the `PATH' environment variable such that the necessary GNU tools
+     come before the standard system tools.
+
+  5. Specify the host, build and target machine configurations.  You do
+     this when you run the `configure' script.
+
+     The "build" machine is the system which you are using, the "host"
+     machine is the system where you want to run the resulting compiler
+     (normally the build machine), and the "target" machine is the
+     system for which you want the compiler to generate code.
+
+     If you are building a compiler to produce code for the machine it
+     runs on (a native compiler), you normally do not need to specify
+     any operands to `configure'; it will try to guess the type of
+     machine you are on and use that as the build, host and target
+     machines.  So you don't need to specify a configuration when
+     building a native compiler unless `configure' cannot figure out
+     what your configuration is or guesses wrong.
+
+     In those cases, specify the build machine's "configuration name"
+     with the `--host' option; the host and target will default to be
+     the same as the host machine.  (If you are building a
+     cross-compiler, see *Note Cross-Compiler::.)
+
+     Here is an example:
+
+          ./configure --host=sparc-sun-sunos4.1
+
+     A configuration name may be canonical or it may be more or less
+     abbreviated.
+
+     A canonical configuration name has three parts, separated by
+     dashes.  It looks like this: `CPU-COMPANY-SYSTEM'.  (The three
+     parts may themselves contain dashes; `configure' can figure out
+     which dashes serve which purpose.)  For example,
+     `m68k-sun-sunos4.1' specifies a Sun 3.
+
+     You can also replace parts of the configuration by nicknames or
+     aliases.  For example, `sun3' stands for `m68k-sun', so
+     `sun3-sunos4.1' is another way to specify a Sun 3.  You can also
+     use simply `sun3-sunos', since the version of SunOS is assumed by
+     default to be version 4.
+
+     You can specify a version number after any of the system types,
+     and some of the CPU types.  In most cases, the version is
+     irrelevant, and will be ignored.  So you might as well specify the
+     version if you know it.
+
+     See *Note Configurations::, for a list of supported configuration
+     names and notes on many of the configurations.  You should check
+     the notes in that section before proceeding any further with the
+     installation of GNU CC.
+
+  6. When running `configure', you may also need to specify certain
+     additional options that describe variant hardware and software
+     configurations.  These are `--with-gnu-as', `--with-gnu-ld',
+     `--with-stabs' and `--nfp'.
+
+    `--with-gnu-as'
+          If you will use GNU CC with the GNU assembler (GAS), you
+          should declare this by using the `--with-gnu-as' option when
+          you run `configure'.
+
+          Using this option does not install GAS.  It only modifies the
+          output of GNU CC to work with GAS.  Building and installing
+          GAS is up to you.
+
+          Conversely, if you *do not* wish to use GAS and do not specify
+          `--with-gnu-as' when building GNU CC, it is up to you to make
+          sure that GAS is not installed.  GNU CC searches for a
+          program named `as' in various directories; if the program it
+          finds is GAS, then it runs GAS.  If you are not sure where
+          GNU CC finds the assembler it is using, try specifying `-v'
+          when you run it.
+
+          The systems where it makes a difference whether you use GAS
+          are
+          `hppa1.0-ANY-ANY', `hppa1.1-ANY-ANY', `i386-ANY-sysv',
+          `i386-ANY-isc',
+          `i860-ANY-bsd', `m68k-bull-sysv',
+          `m68k-hp-hpux', `m68k-sony-bsd',
+          `m68k-altos-sysv', `m68000-hp-hpux',
+          `m68000-att-sysv', `ANY-lynx-lynxos', and `mips-ANY').  On
+          any other system, `--with-gnu-as' has no effect.
+
+          On the systems listed above (except for the HP-PA, for ISC on
+          the 386, and for `mips-sgi-irix5.*'), if you use GAS, you
+          should also use the GNU linker (and specify `--with-gnu-ld').
+
+    `--with-gnu-ld'
+          Specify the option `--with-gnu-ld' if you plan to use the GNU
+          linker with GNU CC.
+
+          This option does not cause the GNU linker to be installed; it
+          just modifies the behavior of GNU CC to work with the GNU
+          linker.
+
+    `--with-stabs'
+          On MIPS based systems and on Alphas, you must specify whether
+          you want GNU CC to create the normal ECOFF debugging format,
+          or to use BSD-style stabs passed through the ECOFF symbol
+          table.  The normal ECOFF debug format cannot fully handle
+          languages other than C.  BSD stabs format can handle other
+          languages, but it only works with the GNU debugger GDB.
+
+          Normally, GNU CC uses the ECOFF debugging format by default;
+          if you prefer BSD stabs, specify `--with-stabs' when you
+          configure GNU CC.
+
+          No matter which default you choose when you configure GNU CC,
+          the user can use the `-gcoff' and `-gstabs+' options to
+          specify explicitly the debug format for a particular
+          compilation.
+
+          `--with-stabs' is meaningful on the ISC system on the 386,
+          also, if `--with-gas' is used.  It selects use of stabs
+          debugging information embedded in COFF output.  This kind of
+          debugging information supports C++ well; ordinary COFF
+          debugging information does not.
+
+          `--with-stabs' is also meaningful on 386 systems running
+          SVR4.  It selects use of stabs debugging information embedded
+          in ELF output.  The C++ compiler currently (2.6.0) does not
+          support the DWARF debugging information normally used on 386
+          SVR4 platforms; stabs provide a workable alternative.  This
+          requires gas and gdb, as the normal SVR4 tools can not
+          generate or interpret stabs.
+
+    `--nfp'
+          On certain systems, you must specify whether the machine has
+          a floating point unit.  These systems include
+          `m68k-sun-sunosN' and `m68k-isi-bsd'.  On any other system,
+          `--nfp' currently has no effect, though perhaps there are
+          other systems where it could usefully make a difference.
+
+    `--enable-haifa'
+    `--disable-haifa'
+          Use `--enable-haifa' to enable use of an experimental
+          instruction scheduler (from IBM Haifa).  This may or may not
+          produce better code.  Some targets on which it is known to be
+          a win enable it by default; use `--disable-haifa' to disable
+          it in these cases.  `configure' will print out whether the
+          Haifa scheduler is enabled when it is run.
+
+    `--enable-threads=TYPE'
+          Certain systems, notably Linux-based GNU systems, can't be
+          relied on to supply a threads facility for the Objective C
+          runtime and so will default to single-threaded runtime.  They
+          may, however, have a library threads implementation
+          available, in which case threads can be enabled with this
+          option by supplying a suitable TYPE, probably `posix'.  The
+          possibilities for TYPE are `single', `posix', `win32',
+          `solaris', `irix' and `mach'.
+
+    `--enable-checking'
+          When you specify this option, the compiler is built to
+          perform checking of tree node types when referencing fields
+          of that node.  This does not change the generated code, but
+          adds error checking within the compiler.  This will slow down
+          the compiler and may only work properly if you are building
+          the compiler with GNU C.
+
+          The `configure' script searches subdirectories of the source
+          directory for other compilers that are to be integrated into
+          GNU CC.  The GNU compiler for C++, called G++ is in a
+          subdirectory named `cp'.  `configure' inserts rules into
+          `Makefile' to build all of those compilers.
+
+          Here we spell out what files will be set up by `configure'.
+          Normally you need not be concerned with these files.
+
+             * A file named `config.h' is created that contains a
+               `#include' of the top-level config file for the machine
+               you will run the compiler on (*note Config::.).  This
+               file is responsible for defining information about the
+               host machine.  It includes `tm.h'.
+
+               The top-level config file is located in the subdirectory
+               `config'.  Its name is always `xm-SOMETHING.h'; usually
+               `xm-MACHINE.h', but there are some exceptions.
+
+               If your system does not support symbolic links, you
+               might want to set up `config.h' to contain a `#include'
+               command which refers to the appropriate file.
+
+             * A file named `tconfig.h' is created which includes the
+               top-level config file for your target machine.  This is
+               used for compiling certain programs to run on that
+               machine.
+
+             * A file named `tm.h' is created which includes the
+               machine-description macro file for your target machine.
+               It should be in the subdirectory `config' and its name
+               is often `MACHINE.h'.
+
+    `--enable-nls'
+    `--disable-nls'
+          The `--enable-nls' option enables Native Language Support
+          (NLS), which lets GCC output diagnostics in languages other
+          than American English.  No translations are available yet, so
+          the main users of this option now are those translating GCC's
+          diagnostics who want to test their work.  Once translations
+          become available, Native Language Support will become enabled
+          by default.  The `--disable-nls' option disables NLS.
+
+    `--with-included-gettext'
+          If NLS is enabled, the GCC build procedure normally attempts
+          to use the host's `gettext' libraries, and falls back on
+          GCC's copy of the GNU `gettext' library only if the host
+          libraries do not suffice.  The `--with-included-gettext'
+          option causes the build procedure to prefer its copy of GNU
+          `gettext'.
+
+    `--with-catgets'
+          If NLS is enabled, and if the host lacks `gettext' but has the
+          inferior `catgets' interface, the GCC build procedure normally
+          ignores `catgets' and instead uses GCC's copy of the GNU
+          `gettext' library.  The `--with-catgets' option causes the
+          build procedure to use the host's `catgets' in this situation.
+
+  7. In certain cases, you should specify certain other options when
+     you run `configure'.
+
+        * The standard directory for installing GNU CC is
+          `/usr/local/lib'.  If you want to install its files somewhere
+          else, specify `--prefix=DIR' when you run `configure'.  Here
+          DIR is a directory name to use instead of `/usr/local' for
+          all purposes with one exception: the directory
+          `/usr/local/include' is searched for header files no matter
+          where you install the compiler.  To override this name, use
+          the `--with-local-prefix' option below.  The directory you
+          specify need not exist, but its parent directory must exist.
+
+        * Specify `--with-local-prefix=DIR' if you want the compiler to
+          search directory `DIR/include' for locally installed header
+          files *instead* of `/usr/local/include'.
+
+          You should specify `--with-local-prefix' *only* if your site
+          has a different convention (not `/usr/local') for where to put
+          site-specific files.
+
+          The default value for `--with-local-prefix' is `/usr/local'
+          regardless of the value of `--prefix'.  Specifying `--prefix'
+          has no effect on which directory GNU CC searches for local
+          header files.  This may seem counterintuitive, but actually
+          it is logical.
+
+          The purpose of `--prefix' is to specify where to *install GNU
+          CC*.  The local header files in `/usr/local/include'--if you
+          put any in that directory--are not part of GNU CC.  They are
+          part of other programs--perhaps many others.  (GNU CC
+          installs its own header files in another directory which is
+          based on the `--prefix' value.)
+
+          *Do not* specify `/usr' as the `--with-local-prefix'!  The
+          directory you use for `--with-local-prefix' *must not* contain
+          any of the system's standard header files.  If it did contain
+          them, certain programs would be miscompiled (including GNU
+          Emacs, on certain targets), because this would override and
+          nullify the header file corrections made by the `fixincludes'
+          script.
+
+          Indications are that people who use this option use it based
+          on mistaken ideas of what it is for.  People use it as if it
+          specified where to install part of GNU CC.  Perhaps they make
+          this assumption because installing GNU CC creates the
+          directory.
+
+  8. Build the compiler.  Just type `make LANGUAGES=c' in the compiler
+     directory.
+
+     `LANGUAGES=c' specifies that only the C compiler should be
+     compiled.  The makefile normally builds compilers for all the
+     supported languages; currently, C, C++ and Objective C.  However,
+     C is the only language that is sure to work when you build with
+     other non-GNU C compilers.  In addition, building anything but C
+     at this stage is a waste of time.
+
+     In general, you can specify the languages to build by typing the
+     argument `LANGUAGES="LIST"', where LIST is one or more words from
+     the list `c', `c++', and `objective-c'.  If you have any
+     additional GNU compilers as subdirectories of the GNU CC source
+     directory, you may also specify their names in this list.
+
+     Ignore any warnings you may see about "statement not reached" in
+     `insn-emit.c'; they are normal.  Also, warnings about "unknown
+     escape sequence" are normal in `genopinit.c' and perhaps some
+     other files.  Likewise, you should ignore warnings about "constant
+     is so large that it is unsigned" in `insn-emit.c' and
+     `insn-recog.c', a warning about a comparison always being zero in
+     `enquire.o', and warnings about shift counts exceeding type widths
+     in `cexp.y'.  Any other compilation errors may represent bugs in
+     the port to your machine or operating system, and should be
+     investigated and reported (*note Bugs::.).
+
+     Some compilers fail to compile GNU CC because they have bugs or
+     limitations.  For example, the Microsoft compiler is said to run
+     out of macro space.  Some Ultrix compilers run out of expression
+     space; then you need to break up the statement where the problem
+     happens.
+
+  9. If you are building a cross-compiler, stop here.  *Note
+     Cross-Compiler::.
+
+ 10. Move the first-stage object files and executables into a
+     subdirectory with this command:
+
+          make stage1
+
+     The files are moved into a subdirectory named `stage1'.  Once
+     installation is complete, you may wish to delete these files with
+     `rm -r stage1'.
+
+ 11. If you have chosen a configuration for GNU CC which requires other
+     GNU tools (such as GAS or the GNU linker) instead of the standard
+     system tools, install the required tools in the `stage1'
+     subdirectory under the names `as', `ld' or whatever is
+     appropriate.  This will enable the stage 1 compiler to find the
+     proper tools in the following stage.
+
+     Alternatively, you can do subsequent compilation using a value of
+     the `PATH' environment variable such that the necessary GNU tools
+     come before the standard system tools.
+
+ 12. Recompile the compiler with itself, with this command:
+
+          make CC="stage1/xgcc -Bstage1/" CFLAGS="-g -O2"
+
+     This is called making the stage 2 compiler.
+
+     The command shown above builds compilers for all the supported
+     languages.  If you don't want them all, you can specify the
+     languages to build by typing the argument `LANGUAGES="LIST"'.  LIST
+     should contain one or more words from the list `c', `c++',
+     `objective-c', and `proto'.  Separate the words with spaces.
+     `proto' stands for the programs `protoize' and `unprotoize'; they
+     are not a separate language, but you use `LANGUAGES' to enable or
+     disable their installation.
+
+     If you are going to build the stage 3 compiler, then you might
+     want to build only the C language in stage 2.
+
+     Once you have built the stage 2 compiler, if you are short of disk
+     space, you can delete the subdirectory `stage1'.
+
+     On a 68000 or 68020 system lacking floating point hardware, unless
+     you have selected a `tm.h' file that expects by default that there
+     is no such hardware, do this instead:
+
+          make CC="stage1/xgcc -Bstage1/" CFLAGS="-g -O2 -msoft-float"
+
+ 13. If you wish to test the compiler by compiling it with itself one
+     more time, install any other necessary GNU tools (such as GAS or
+     the GNU linker) in the `stage2' subdirectory as you did in the
+     `stage1' subdirectory, then do this:
+
+          make stage2
+          make CC="stage2/xgcc -Bstage2/" CFLAGS="-g -O2"
+
+     This is called making the stage 3 compiler.  Aside from the `-B'
+     option, the compiler options should be the same as when you made
+     the stage 2 compiler.  But the `LANGUAGES' option need not be the
+     same.  The command shown above builds compilers for all the
+     supported languages; if you don't want them all, you can specify
+     the languages to build by typing the argument `LANGUAGES="LIST"',
+     as described above.
+
+     If you do not have to install any additional GNU tools, you may
+     use the command
+
+          make bootstrap LANGUAGES=LANGUAGE-LIST BOOT_CFLAGS=OPTION-LIST
+
+     instead of making `stage1', `stage2', and performing the two
+     compiler builds.
+
+ 14. Compare the latest object files with the stage 2 object files--they
+     ought to be identical, aside from time stamps (if any).
+
+     On some systems, meaningful comparison of object files is
+     impossible; they always appear "different."  This is currently
+     true on Solaris and some systems that use ELF object file format.
+     On some versions of Irix on SGI machines and DEC Unix (OSF/1) on
+     Alpha systems, you will not be able to compare the files without
+     specifying `-save-temps'; see the description of individual
+     systems above to see if you get comparison failures.  You may have
+     similar problems on other systems.
+
+     Use this command to compare the files:
+
+          make compare
+
+     This will mention any object files that differ between stage 2 and
+     stage 3.  Any difference, no matter how innocuous, indicates that
+     the stage 2 compiler has compiled GNU CC incorrectly, and is
+     therefore a potentially serious bug which you should investigate
+     and report (*note Bugs::.).
+
+     If your system does not put time stamps in the object files, then
+     this is a faster way to compare them (using the Bourne shell):
+
+          for file in *.o; do
+          cmp $file stage2/$file
+          done
+
+     If you have built the compiler with the `-mno-mips-tfile' option on
+     MIPS machines, you will not be able to compare the files.
+
+ 15. Install the compiler driver, the compiler's passes and run-time
+     support with `make install'.  Use the same value for `CC',
+     `CFLAGS' and `LANGUAGES' that you used when compiling the files
+     that are being installed.  One reason this is necessary is that
+     some versions of Make have bugs and recompile files gratuitously
+     when you do this step.  If you use the same variable values, those
+     files will be recompiled properly.
+
+     For example, if you have built the stage 2 compiler, you can use
+     the following command:
+
+          make install CC="stage2/xgcc -Bstage2/" CFLAGS="-g -O" LANGUAGES="LIST"
+
+     This copies the files `cc1', `cpp' and `libgcc.a' to files `cc1',
+     `cpp' and `libgcc.a' in the directory
+     `/usr/local/lib/gcc-lib/TARGET/VERSION', which is where the
+     compiler driver program looks for them.  Here TARGET is the
+     canonicalized form of target machine type specified when you ran
+     `configure', and VERSION is the version number of GNU CC.  This
+     naming scheme permits various versions and/or cross-compilers to
+     coexist.  It also copies the executables for compilers for other
+     languages (e.g., `cc1plus' for C++) to the same directory.
+
+     This also copies the driver program `xgcc' into
+     `/usr/local/bin/gcc', so that it appears in typical execution
+     search paths.  It also copies `gcc.1' into `/usr/local/man/man1'
+     and info pages into `/usr/local/info'.
+
+     On some systems, this command causes recompilation of some files.
+     This is usually due to bugs in `make'.  You should either ignore
+     this problem, or use GNU Make.
+
+     *Warning: there is a bug in `alloca' in the Sun library.  To avoid
+     this bug, be sure to install the executables of GNU CC that were
+     compiled by GNU CC.  (That is, the executables from stage 2 or 3,
+     not stage 1.)  They use `alloca' as a built-in function and never
+     the one in the library.*
+
+     (It is usually better to install GNU CC executables from stage 2
+     or 3, since they usually run faster than the ones compiled with
+     some other compiler.)
+
+ 16. If you're going to use C++, you need to install the C++ runtime
+     library.  This includes all I/O functionality, special class
+     libraries, etc.
+
+     The standard C++ runtime library for GNU CC is called `libstdc++'.
+     An obsolescent library `libg++' may also be available, but it's
+     necessary only for older software that hasn't been converted yet;
+     if you don't know whether you need `libg++' then you probably don't
+     need it.
+
+     Here's one way to build and install `libstdc++' for GNU CC:
+
+        * Build and install GNU CC, so that invoking `gcc' obtains the
+          GNU CC that was just built.
+
+        * Obtain a copy of a compatible `libstdc++' distribution.  For
+          example, the `libstdc++-2.8.0.tar.gz' distribution should be
+          compatible with GCC 2.8.0.  GCC distributors normally
+          distribute `libstdc++' as well.
+
+        * Set the `CXX' environment variable to `gcc' while running the
+          `libstdc++' distribution's `configure' command.  Use the same
+          `configure' options that you used when you invoked GCC's
+          `configure' command.
+
+        * Invoke `make' to build the C++ runtime.
+
+        * Invoke `make install' to install the C++ runtime.
+
+     To summarize, after building and installing GNU CC, invoke the
+     following shell commands in the topmost directory of the C++
+     library distribution.  For CONFIGURE-OPTIONS, use the same options
+     that you used to configure GNU CC.
+
+          $ CXX=gcc ./configure CONFIGURE-OPTIONS
+          $ make
+          $ make install
+
+ 17. GNU CC includes a runtime library for Objective-C because it is an
+     integral part of the language.  You can find the files associated
+     with the library in the subdirectory `objc'.  The GNU Objective-C
+     Runtime Library requires header files for the target's C library in
+     order to be compiled,and also requires the header files for the
+     target's thread library if you want thread support.  *Note
+     Cross-Compilers and Header Files: Cross Headers, for discussion
+     about header files issues for cross-compilation.
+
+     When you run `configure', it picks the appropriate Objective-C
+     thread implementation file for the target platform.  In some
+     situations, you may wish to choose a different back-end as some
+     platforms support multiple thread implementations or you may wish
+     to disable thread support completely.  You do this by specifying a
+     value for the OBJC_THREAD_FILE makefile variable on the command
+     line when you run make, for example:
+
+          make CC="stage2/xgcc -Bstage2/" CFLAGS="-g -O2" OBJC_THREAD_FILE=thr-single
+
+     Below is a list of the currently available back-ends.
+
+        * thr-single Disable thread support, should work for all
+          platforms.
+
+        * thr-decosf1 DEC OSF/1 thread support.
+
+        * thr-irix SGI IRIX thread support.
+
+        * thr-mach Generic MACH thread support, known to work on
+          NEXTSTEP.
+
+        * thr-os2 IBM OS/2 thread support.
+
+        * thr-posix Generix POSIX thread support.
+
+        * thr-pthreads PCThreads on Linux-based GNU systems.
+
+        * thr-solaris SUN Solaris thread support.
+
+        * thr-win32 Microsoft Win32 API thread support.
+
+
+File: gcc.info,  Node: Configuration Files,  Next: Configurations,  Up: Installation
+
+Files Created by `configure'
+============================
+
+   Here we spell out what files will be set up by `configure'.  Normally
+you need not be concerned with these files.
+
+   * A file named `config.h' is created that contains a `#include' of
+     the top-level config file for the machine you will run the compiler
+     on (*note Config::.).  This file is responsible for defining
+     information about the host machine.  It includes `tm.h'.
+
+     The top-level config file is located in the subdirectory `config'.
+     Its name is always `xm-SOMETHING.h'; usually `xm-MACHINE.h', but
+     there are some exceptions.
+
+     If your system does not support symbolic links, you might want to
+     set up `config.h' to contain a `#include' command which refers to
+     the appropriate file.
+
+   * A file named `tconfig.h' is created which includes the top-level
+     config file for your target machine.  This is used for compiling
+     certain programs to run on that machine.
+
+   * A file named `tm.h' is created which includes the
+     machine-description macro file for your target machine.  It should
+     be in the subdirectory `config' and its name is often `MACHINE.h'.
+
+   * The command file `configure' also constructs the file `Makefile'
+     by adding some text to the template file `Makefile.in'.  The
+     additional text comes from files in the `config' directory, named
+     `t-TARGET' and `x-HOST'.  If these files do not exist, it means
+     nothing needs to be added for a given target or host.
+

usr/local/nachos/lib/gcc-lib/decstation-ultrix/2.95.2/include/README

@@ -0,0 +1,9 @@
+This README file is copied into the directory for GCC-only header files
+when fixincludes is run by the makefile for GCC.
+
+Many of the files in this directory were made from the standard system
+header files of this system by the shell script `fixincludes'.
+They are system-specific, and will not work on any other kind of system.
+They are also not part of GCC.  The reason for making the files here
+is to fix the places in the header files which use constructs
+that are incompatible with ANSI C.

usr/local/nachos/lib/gcc-lib/decstation-ultrix/2.95.2/include/float.h

@@ -0,0 +1,96 @@
+/* float.h for target with IEEE 32 bit and 64 bit floating point formats */
+#ifndef _FLOAT_H_
+#define _FLOAT_H_
+/* Produced by enquire version 4.3, CWI, Amsterdam */
+
+   /* Radix of exponent representation */
+#undef FLT_RADIX
+#define FLT_RADIX 2
+   /* Number of base-FLT_RADIX digits in the significand of a float */
+#undef FLT_MANT_DIG
+#define FLT_MANT_DIG 24
+   /* Number of decimal digits of precision in a float */
+#undef FLT_DIG
+#define FLT_DIG 6
+   /* Addition rounds to 0: zero, 1: nearest, 2: +inf, 3: -inf, -1: unknown */
+#undef FLT_ROUNDS
+#define FLT_ROUNDS 1
+   /* Difference between 1.0 and the minimum float greater than 1.0 */
+#undef FLT_EPSILON
+#define FLT_EPSILON 1.19209290e-07F
+   /* Minimum int x such that FLT_RADIX**(x-1) is a normalised float */
+#undef FLT_MIN_EXP
+#define FLT_MIN_EXP (-125)
+   /* Minimum normalised float */
+#undef FLT_MIN
+#define FLT_MIN 1.17549435e-38F
+   /* Minimum int x such that 10**x is a normalised float */
+#undef FLT_MIN_10_EXP
+#define FLT_MIN_10_EXP (-37)
+   /* Maximum int x such that FLT_RADIX**(x-1) is a representable float */
+#undef FLT_MAX_EXP
+#define FLT_MAX_EXP 128
+   /* Maximum float */
+#undef FLT_MAX
+#define FLT_MAX 3.40282347e+38F
+   /* Maximum int x such that 10**x is a representable float */
+#undef FLT_MAX_10_EXP
+#define FLT_MAX_10_EXP 38
+
+   /* Number of base-FLT_RADIX digits in the significand of a double */
+#undef DBL_MANT_DIG
+#define DBL_MANT_DIG 53
+   /* Number of decimal digits of precision in a double */
+#undef DBL_DIG
+#define DBL_DIG 15
+   /* Difference between 1.0 and the minimum double greater than 1.0 */
+#undef DBL_EPSILON
+#define DBL_EPSILON 2.2204460492503131e-16
+   /* Minimum int x such that FLT_RADIX**(x-1) is a normalised double */
+#undef DBL_MIN_EXP
+#define DBL_MIN_EXP (-1021)
+   /* Minimum normalised double */
+#undef DBL_MIN
+#define DBL_MIN 2.2250738585072014e-308
+   /* Minimum int x such that 10**x is a normalised double */
+#undef DBL_MIN_10_EXP
+#define DBL_MIN_10_EXP (-307)
+   /* Maximum int x such that FLT_RADIX**(x-1) is a representable double */
+#undef DBL_MAX_EXP
+#define DBL_MAX_EXP 1024
+   /* Maximum double */
+#undef DBL_MAX
+#define DBL_MAX 1.7976931348623157e+308
+   /* Maximum int x such that 10**x is a representable double */
+#undef DBL_MAX_10_EXP
+#define DBL_MAX_10_EXP 308
+
+   /* Number of base-FLT_RADIX digits in the significand of a long double */
+#undef LDBL_MANT_DIG
+#define LDBL_MANT_DIG 53
+   /* Number of decimal digits of precision in a long double */
+#undef LDBL_DIG
+#define LDBL_DIG 15
+   /* Difference between 1.0 and the minimum long double greater than 1.0 */
+#undef LDBL_EPSILON
+#define LDBL_EPSILON 2.2204460492503131e-16L
+   /* Minimum int x such that FLT_RADIX**(x-1) is a normalised long double */
+#undef LDBL_MIN_EXP
+#define LDBL_MIN_EXP (-1021)
+   /* Minimum normalised long double */
+#undef LDBL_MIN
+#define LDBL_MIN 2.2250738585072014e-308L
+   /* Minimum int x such that 10**x is a normalised long double */
+#undef LDBL_MIN_10_EXP
+#define LDBL_MIN_10_EXP (-307)
+   /* Maximum int x such that FLT_RADIX**(x-1) is a representable long double */
+#undef LDBL_MAX_EXP
+#define LDBL_MAX_EXP 1024
+   /* Maximum long double */
+#undef LDBL_MAX
+#define LDBL_MAX 1.7976931348623157e+308L
+   /* Maximum int x such that 10**x is a representable long double */
+#undef LDBL_MAX_10_EXP
+#define LDBL_MAX_10_EXP 308
+
+#endif /*  _FLOAT_H_ */

usr/local/nachos/lib/gcc-lib/decstation-ultrix/2.95.2/include/iso646.h

@@ -0,0 +1,15 @@
+/* Macros for C programs written in national variants of ISO 646.  */
+
+#ifndef __cplusplus
+#define and	&&
+#define and_eq	&=
+#define bitand	&
+#define bitor	|
+#define compl	~
+#define not	!
+#define not_eq	!=
+#define or	||
+#define or_eq	|=
+#define xor	^
+#define xor_eq	^=
+#endif

usr/local/nachos/lib/gcc-lib/decstation-ultrix/2.95.2/include/limits.h

@@ -0,0 +1,98 @@
+#ifndef _LIMITS_H___
+#ifndef _MACH_MACHLIMITS_H_
+
+/* _MACH_MACHLIMITS_H_ is used on OSF/1.  */
+#define _LIMITS_H___
+#define _MACH_MACHLIMITS_H_
+
+/* Number of bits in a `char'.  */
+#undef CHAR_BIT
+#define CHAR_BIT 8
+
+/* Maximum length of a multibyte character.  */
+#ifndef MB_LEN_MAX
+#define MB_LEN_MAX 1
+#endif
+
+/* Minimum and maximum values a `signed char' can hold.  */
+#undef SCHAR_MIN
+#define SCHAR_MIN (-128)
+#undef SCHAR_MAX
+#define SCHAR_MAX 127
+
+/* Maximum value an `unsigned char' can hold.  (Minimum is 0).  */
+#undef UCHAR_MAX
+#define UCHAR_MAX 255
+
+/* Minimum and maximum values a `char' can hold.  */
+#ifdef __CHAR_UNSIGNED__
+#undef CHAR_MIN
+#define CHAR_MIN 0
+#undef CHAR_MAX
+#define CHAR_MAX 255
+#else
+#undef CHAR_MIN
+#define CHAR_MIN (-128)
+#undef CHAR_MAX
+#define CHAR_MAX 127
+#endif
+
+/* Minimum and maximum values a `signed short int' can hold.  */
+#undef SHRT_MIN
+/* For the sake of 16 bit hosts, we may not use -32768 */
+#define SHRT_MIN (-32767-1)
+#undef SHRT_MAX
+#define SHRT_MAX 32767
+
+/* Maximum value an `unsigned short int' can hold.  (Minimum is 0).  */
+#undef USHRT_MAX
+#define USHRT_MAX 65535
+
+/* Minimum and maximum values a `signed int' can hold.  */
+#ifndef __INT_MAX__
+#define __INT_MAX__ 2147483647
+#endif
+#undef INT_MIN
+#define INT_MIN (-INT_MAX-1)
+#undef INT_MAX
+#define INT_MAX __INT_MAX__
+
+/* Maximum value an `unsigned int' can hold.  (Minimum is 0).  */
+#undef UINT_MAX
+#define UINT_MAX (INT_MAX * 2U + 1)
+
+/* Minimum and maximum values a `signed long int' can hold.
+   (Same as `int').  */
+#ifndef __LONG_MAX__
+#if defined (__alpha__) || defined (__sparc_v9__) || defined (__sparcv9)
+#define __LONG_MAX__ 9223372036854775807L
+#else
+#define __LONG_MAX__ 2147483647L
+#endif /* __alpha__ || sparc64 */
+#endif
+#undef LONG_MIN
+#define LONG_MIN (-LONG_MAX-1)
+#undef LONG_MAX
+#define LONG_MAX __LONG_MAX__
+
+/* Maximum value an `unsigned long int' can hold.  (Minimum is 0).  */
+#undef ULONG_MAX
+#define ULONG_MAX (LONG_MAX * 2UL + 1)
+
+#if defined (__GNU_LIBRARY__) ? defined (__USE_GNU) : !defined (__STRICT_ANSI__)
+/* Minimum and maximum values a `signed long long int' can hold.  */
+#ifndef __LONG_LONG_MAX__
+#define __LONG_LONG_MAX__ 9223372036854775807LL
+#endif
+#undef LONG_LONG_MIN
+#define LONG_LONG_MIN (-LONG_LONG_MAX-1)
+#undef LONG_LONG_MAX
+#define LONG_LONG_MAX __LONG_LONG_MAX__
+
+/* Maximum value an `unsigned long long int' can hold.  (Minimum is 0).  */
+#undef ULONG_LONG_MAX
+#define ULONG_LONG_MAX (LONG_LONG_MAX * 2ULL + 1)
+#endif
+
+#endif /* _MACH_MACHLIMITS_H_ */
+#endif /* _LIMITS_H___ */

usr/local/nachos/lib/gcc-lib/decstation-ultrix/2.95.2/include/proto.h

@@ -0,0 +1,4 @@
+/* This header file is to avoid trouble with semi-ANSI header files
+   on the Convex in system version 8.0.  */
+
+#define _PROTO(list) ()

usr/local/nachos/lib/gcc-lib/decstation-ultrix/2.95.2/include/stdarg.h

@@ -0,0 +1,212 @@
+/* stdarg.h for GNU.
+   Note that the type used in va_arg is supposed to match the
+   actual type **after default promotions**.
+   Thus, va_arg (..., short) is not valid.  */
+
+#ifndef _STDARG_H
+#ifndef _ANSI_STDARG_H_
+#ifndef __need___va_list
+#define _STDARG_H
+#define _ANSI_STDARG_H_
+#endif /* not __need___va_list */
+#undef __need___va_list
+
+#ifdef __clipper__
+#include "va-clipper.h"
+#else
+#ifdef __m88k__
+#include "va-m88k.h"
+#else
+#ifdef __i860__
+#include "va-i860.h"
+#else
+#ifdef __hppa__
+#include "va-pa.h"
+#else
+#ifdef __mips__
+#include "va-mips.h"
+#else
+#ifdef __sparc__
+#include "va-sparc.h"
+#else
+#ifdef __i960__
+#include "va-i960.h"
+#else
+#ifdef __alpha__
+#include "va-alpha.h"
+#else
+#if defined (__H8300__) || defined (__H8300H__) || defined (__H8300S__)
+#include "va-h8300.h"
+#else
+#if defined (__PPC__) && (defined (_CALL_SYSV) || defined (_WIN32))
+#include "va-ppc.h"
+#else
+#ifdef __arc__
+#include "va-arc.h"
+#else
+#ifdef __M32R__
+#include "va-m32r.h"
+#else
+#ifdef __sh__
+#include "va-sh.h"
+#else
+#ifdef __mn10300__
+#include "va-mn10300.h"
+#else
+#ifdef __mn10200__
+#include "va-mn10200.h"
+#else
+#ifdef __v850__
+#include "va-v850.h"
+#else
+#if defined (_TMS320C4x) || defined (_TMS320C3x)
+#include <va-c4x.h>
+#else
+
+/* Define __gnuc_va_list.  */
+
+#ifndef __GNUC_VA_LIST
+#define __GNUC_VA_LIST
+#if defined(__svr4__) || defined(_AIX) || defined(_M_UNIX) || defined(__NetBSD__)
+typedef char *__gnuc_va_list;
+#else
+typedef void *__gnuc_va_list;
+#endif
+#endif
+
+/* Define the standard macros for the user,
+   if this invocation was from the user program.  */
+#ifdef _STDARG_H
+
+/* Amount of space required in an argument list for an arg of type TYPE.
+   TYPE may alternatively be an expression whose type is used.  */
+
+#if defined(sysV68)
+#define __va_rounded_size(TYPE)  \
+  (((sizeof (TYPE) + sizeof (short) - 1) / sizeof (short)) * sizeof (short))
+#elif defined(_AIX)
+#define __va_rounded_size(TYPE)  \
+  (((sizeof (TYPE) + sizeof (long) - 1) / sizeof (long)) * sizeof (long))
+#else
+#define __va_rounded_size(TYPE)  \
+  (((sizeof (TYPE) + sizeof (int) - 1) / sizeof (int)) * sizeof (int))
+#endif
+
+#define va_start(AP, LASTARG) 						\
+ (AP = ((__gnuc_va_list) __builtin_next_arg (LASTARG)))
+
+#undef va_end
+void va_end (__gnuc_va_list);		/* Defined in libgcc.a */
+#define va_end(AP)	((void)0)
+
+/* We cast to void * and then to TYPE * because this avoids
+   a warning about increasing the alignment requirement.  */
+
+#if (defined (__arm__) && ! defined (__ARMEB__)) || defined (__i386__) || defined (__i860__) || defined (__ns32000__) || defined (__vax__)
+/* This is for little-endian machines; small args are padded upward.  */
+#define va_arg(AP, TYPE)						\
+ (AP = (__gnuc_va_list) ((char *) (AP) + __va_rounded_size (TYPE)),	\
+  *((TYPE *) (void *) ((char *) (AP) - __va_rounded_size (TYPE))))
+#else /* big-endian */
+/* This is for big-endian machines; small args are padded downward.  */
+#define va_arg(AP, TYPE)						\
+ (AP = (__gnuc_va_list) ((char *) (AP) + __va_rounded_size (TYPE)),	\
+  *((TYPE *) (void *) ((char *) (AP)					\
+		       - ((sizeof (TYPE) < __va_rounded_size (char)	\
+			   ? sizeof (TYPE) : __va_rounded_size (TYPE))))))
+#endif /* big-endian */
+
+/* Copy __gnuc_va_list into another variable of this type.  */
+#define __va_copy(dest, src) (dest) = (src)
+
+#endif /* _STDARG_H */
+
+#endif /* not TMS320C3x or TMS320C4x */
+#endif /* not v850 */
+#endif /* not mn10200 */
+#endif /* not mn10300 */
+#endif /* not sh */
+#endif /* not m32r */
+#endif /* not arc */
+#endif /* not powerpc with V.4 calling sequence */
+#endif /* not h8300 */
+#endif /* not alpha */
+#endif /* not i960 */
+#endif /* not sparc */
+#endif /* not mips */
+#endif /* not hppa */
+#endif /* not i860 */
+#endif /* not m88k */
+#endif /* not clipper */
+
+#ifdef _STDARG_H
+/* Define va_list, if desired, from __gnuc_va_list. */
+/* We deliberately do not define va_list when called from
+   stdio.h, because ANSI C says that stdio.h is not supposed to define
+   va_list.  stdio.h needs to have access to that data type, 
+   but must not use that name.  It should use the name __gnuc_va_list,
+   which is safe because it is reserved for the implementation.  */
+
+#ifdef _HIDDEN_VA_LIST  /* On OSF1, this means varargs.h is "half-loaded".  */
+#undef _VA_LIST
+#endif
+
+#ifdef _BSD_VA_LIST
+#undef _BSD_VA_LIST
+#endif
+
+#if defined(__svr4__) || (defined(_SCO_DS) && !defined(__VA_LIST))
+/* SVR4.2 uses _VA_LIST for an internal alias for va_list,
+   so we must avoid testing it and setting it here.
+   SVR4 uses _VA_LIST as a flag in stdarg.h, but we should
+   have no conflict with that.  */
+#ifndef _VA_LIST_
+#define _VA_LIST_
+#ifdef __i860__
+#ifndef _VA_LIST
+#define _VA_LIST va_list
+#endif
+#endif /* __i860__ */
+typedef __gnuc_va_list va_list;
+#ifdef _SCO_DS
+#define __VA_LIST
+#endif
+#endif /* _VA_LIST_ */
+#else /* not __svr4__ || _SCO_DS */
+
+/* The macro _VA_LIST_ is the same thing used by this file in Ultrix.
+   But on BSD NET2 we must not test or define or undef it.
+   (Note that the comments in NET 2's ansi.h
+   are incorrect for _VA_LIST_--see stdio.h!)  */
+#if !defined (_VA_LIST_) || defined (__BSD_NET2__) || defined (____386BSD____) || defined (__bsdi__) || defined (__sequent__) || defined (__FreeBSD__) || defined(WINNT)
+/* The macro _VA_LIST_DEFINED is used in Windows NT 3.5  */
+#ifndef _VA_LIST_DEFINED
+/* The macro _VA_LIST is used in SCO Unix 3.2.  */
+#ifndef _VA_LIST
+/* The macro _VA_LIST_T_H is used in the Bull dpx2  */
+#ifndef _VA_LIST_T_H
+typedef __gnuc_va_list va_list;
+#endif /* not _VA_LIST_T_H */
+#endif /* not _VA_LIST */
+#endif /* not _VA_LIST_DEFINED */
+#if !(defined (__BSD_NET2__) || defined (____386BSD____) || defined (__bsdi__) || defined (__sequent__) || defined (__FreeBSD__))
+#define _VA_LIST_
+#endif
+#ifndef _VA_LIST
+#define _VA_LIST
+#endif
+#ifndef _VA_LIST_DEFINED
+#define _VA_LIST_DEFINED
+#endif
+#ifndef _VA_LIST_T_H
+#define _VA_LIST_T_H
+#endif
+
+#endif /* not _VA_LIST_, except on certain systems */
+
+#endif /* not __svr4__ */
+
+#endif /* _STDARG_H */
+
+#endif /* not _ANSI_STDARG_H_ */
+#endif /* not _STDARG_H */

usr/local/nachos/lib/gcc-lib/decstation-ultrix/2.95.2/include/stdbool.h

@@ -0,0 +1,20 @@
+/* stdbool.h for GNU.  */
+#ifndef __STDBOOL_H__
+#define __STDBOOL_H__	1
+
+/* The type `bool' must promote to `int' or `unsigned int'.  The constants
+   `true' and `false' must have the value 0 and 1 respectively.  */
+typedef enum
+  {
+    false = 0,
+    true = 1
+  } bool;
+
+/* The names `true' and `false' must also be made available as macros.  */
+#define false	false
+#define true	true
+
+/* Signal that all the definitions are present.  */
+#define __bool_true_false_are_defined	1
+
+#endif	/* stdbool.h */

usr/local/nachos/lib/gcc-lib/decstation-ultrix/2.95.2/include/stddef.h

@@ -0,0 +1,342 @@
+#if (!defined(_STDDEF_H) && !defined(_STDDEF_H_) && !defined(_ANSI_STDDEF_H) \
+     && !defined(__STDDEF_H__)) \
+    || defined(__need_wchar_t) || defined(__need_size_t) \
+    || defined(__need_ptrdiff_t) || defined(__need_NULL) \
+    || defined(__need_wint_t)
+
+/* Any one of these symbols __need_* means that GNU libc
+   wants us just to define one data type.  So don't define
+   the symbols that indicate this file's entire job has been done.  */
+#if (!defined(__need_wchar_t) && !defined(__need_size_t)	\
+     && !defined(__need_ptrdiff_t) && !defined(__need_NULL)	\
+     && !defined(__need_wint_t))
+#define _STDDEF_H
+#define _STDDEF_H_
+/* snaroff@next.com says the NeXT needs this.  */
+#define _ANSI_STDDEF_H
+/* Irix 5.1 needs this.  */
+#define __STDDEF_H__
+#endif
+
+#ifndef __sys_stdtypes_h
+/* This avoids lossage on SunOS but only if stdtypes.h comes first.
+   There's no way to win with the other order!  Sun lossage.  */
+
+/* On 4.3bsd-net2, make sure ansi.h is included, so we have
+   one less case to deal with in the following.  */
+#if defined (__BSD_NET2__) || defined (____386BSD____) || defined (__FreeBSD__) || defined(__NetBSD__)
+#include <machine/ansi.h>
+#endif
+
+/* In 4.3bsd-net2, machine/ansi.h defines these symbols, which are
+   defined if the corresponding type is *not* defined.
+   FreeBSD-2.1 defines _MACHINE_ANSI_H_ instead of _ANSI_H_ */
+#if defined(_ANSI_H_) || defined(_MACHINE_ANSI_H_)
+#if !defined(_SIZE_T_) && !defined(_BSD_SIZE_T_)
+#define _SIZE_T
+#endif
+#if !defined(_PTRDIFF_T_) && !defined(_BSD_PTRDIFF_T_)
+#define _PTRDIFF_T
+#endif
+/* On BSD/386 1.1, at least, machine/ansi.h defines _BSD_WCHAR_T_
+   instead of _WCHAR_T_. */
+#if !defined(_WCHAR_T_) && !defined(_BSD_WCHAR_T_)
+#ifndef _BSD_WCHAR_T_
+#define _WCHAR_T
+#endif
+#endif
+/* Undef _FOO_T_ if we are supposed to define foo_t.  */
+#if defined (__need_ptrdiff_t) || defined (_STDDEF_H_)
+#undef _PTRDIFF_T_
+#undef _BSD_PTRDIFF_T_
+#endif
+#if defined (__need_size_t) || defined (_STDDEF_H_)
+#undef _SIZE_T_
+#undef _BSD_SIZE_T_
+#endif
+#if defined (__need_wchar_t) || defined (_STDDEF_H_)
+#undef _WCHAR_T_
+#undef _BSD_WCHAR_T_
+#endif
+#endif /* defined(_ANSI_H_) || defined(_MACHINE_ANSI_H_) */
+
+/* Sequent's header files use _PTRDIFF_T_ in some conflicting way.
+   Just ignore it.  */
+#if defined (__sequent__) && defined (_PTRDIFF_T_)
+#undef _PTRDIFF_T_
+#endif
+
+/* On VxWorks, <type/vxTypesBase.h> may have defined macros like
+   _TYPE_size_t which will typedef size_t.  fixincludes patched the
+   vxTypesBase.h so that this macro is only defined if _GCC_SIZE_T is
+   not defined, and so that defining this macro defines _GCC_SIZE_T.
+   If we find that the macros are still defined at this point, we must
+   invoke them so that the type is defined as expected.  */
+#if defined (_TYPE_ptrdiff_t) && (defined (__need_ptrdiff_t) || defined (_STDDEF_H_))
+_TYPE_ptrdiff_t;
+#undef _TYPE_ptrdiff_t
+#endif
+#if defined (_TYPE_size_t) && (defined (__need_size_t) || defined (_STDDEF_H_))
+_TYPE_size_t;
+#undef _TYPE_size_t
+#endif
+#if defined (_TYPE_wchar_t) && (defined (__need_wchar_t) || defined (_STDDEF_H_))
+_TYPE_wchar_t;
+#undef _TYPE_wchar_t
+#endif
+
+/* In case nobody has defined these types, but we aren't running under
+   GCC 2.00, make sure that __PTRDIFF_TYPE__, __SIZE__TYPE__, and
+   __WCHAR_TYPE__ have reasonable values.  This can happen if the
+   parts of GCC is compiled by an older compiler, that actually
+   include gstddef.h, such as collect2.  */
+
+/* Signed type of difference of two pointers.  */
+
+/* Define this type if we are doing the whole job,
+   or if we want this type in particular.  */
+#if defined (_STDDEF_H) || defined (__need_ptrdiff_t)
+#ifndef _PTRDIFF_T	/* in case <sys/types.h> has defined it. */
+#ifndef _T_PTRDIFF_
+#ifndef _T_PTRDIFF
+#ifndef __PTRDIFF_T
+#ifndef _PTRDIFF_T_
+#ifndef _BSD_PTRDIFF_T_
+#ifndef ___int_ptrdiff_t_h
+#ifndef _GCC_PTRDIFF_T
+#define _PTRDIFF_T
+#define _T_PTRDIFF_
+#define _T_PTRDIFF
+#define __PTRDIFF_T
+#define _PTRDIFF_T_
+#define _BSD_PTRDIFF_T_
+#define ___int_ptrdiff_t_h
+#define _GCC_PTRDIFF_T
+#ifndef __PTRDIFF_TYPE__
+#define __PTRDIFF_TYPE__ long int
+#endif
+typedef __PTRDIFF_TYPE__ ptrdiff_t;
+#endif /* _GCC_PTRDIFF_T */
+#endif /* ___int_ptrdiff_t_h */
+#endif /* _BSD_PTRDIFF_T_ */
+#endif /* _PTRDIFF_T_ */
+#endif /* __PTRDIFF_T */
+#endif /* _T_PTRDIFF */
+#endif /* _T_PTRDIFF_ */
+#endif /* _PTRDIFF_T */
+
+/* If this symbol has done its job, get rid of it.  */
+#undef	__need_ptrdiff_t
+
+#endif /* _STDDEF_H or __need_ptrdiff_t.  */
+
+/* Unsigned type of `sizeof' something.  */
+
+/* Define this type if we are doing the whole job,
+   or if we want this type in particular.  */
+#if defined (_STDDEF_H) || defined (__need_size_t)
+#ifndef __size_t__	/* BeOS */
+#ifndef _SIZE_T	/* in case <sys/types.h> has defined it. */
+#ifndef _SYS_SIZE_T_H
+#ifndef _T_SIZE_
+#ifndef _T_SIZE
+#ifndef __SIZE_T
+#ifndef _SIZE_T_
+#ifndef _BSD_SIZE_T_
+#ifndef _SIZE_T_DEFINED_
+#ifndef _SIZE_T_DEFINED
+#ifndef ___int_size_t_h
+#ifndef _GCC_SIZE_T
+#ifndef _SIZET_
+#ifndef __size_t
+#define __size_t__	/* BeOS */
+#define _SIZE_T
+#define _SYS_SIZE_T_H
+#define _T_SIZE_
+#define _T_SIZE
+#define __SIZE_T
+#define _SIZE_T_
+#define _BSD_SIZE_T_
+#define _SIZE_T_DEFINED_
+#define _SIZE_T_DEFINED
+#define ___int_size_t_h
+#define _GCC_SIZE_T
+#define _SIZET_
+#define __size_t
+#ifndef __SIZE_TYPE__
+#define __SIZE_TYPE__ long unsigned int
+#endif
+#if !(defined (__GNUG__) && defined (size_t))
+typedef __SIZE_TYPE__ size_t;
+#ifdef __BEOS__
+typedef long ssize_t;
+#endif /* __BEOS__ */
+#endif /* !(defined (__GNUG__) && defined (size_t)) */
+#endif /* __size_t */
+#endif /* _SIZET_ */
+#endif /* _GCC_SIZE_T */
+#endif /* ___int_size_t_h */
+#endif /* _SIZE_T_DEFINED */
+#endif /* _SIZE_T_DEFINED_ */
+#endif /* _BSD_SIZE_T_ */
+#endif /* _SIZE_T_ */
+#endif /* __SIZE_T */
+#endif /* _T_SIZE */
+#endif /* _T_SIZE_ */
+#endif /* _SYS_SIZE_T_H */
+#endif /* _SIZE_T */
+#endif /* __size_t__ */
+#undef	__need_size_t
+#endif /* _STDDEF_H or __need_size_t.  */
+
+
+/* Wide character type.
+   Locale-writers should change this as necessary to
+   be big enough to hold unique values not between 0 and 127,
+   and not (wchar_t) -1, for each defined multibyte character.  */
+
+/* Define this type if we are doing the whole job,
+   or if we want this type in particular.  */
+#if defined (_STDDEF_H) || defined (__need_wchar_t)
+#ifndef __wchar_t__	/* BeOS */
+#ifndef _WCHAR_T
+#ifndef _T_WCHAR_
+#ifndef _T_WCHAR
+#ifndef __WCHAR_T
+#ifndef _WCHAR_T_
+#ifndef _BSD_WCHAR_T_
+#ifndef _WCHAR_T_DEFINED_
+#ifndef _WCHAR_T_DEFINED
+#ifndef _WCHAR_T_H
+#ifndef ___int_wchar_t_h
+#ifndef __INT_WCHAR_T_H
+#ifndef _GCC_WCHAR_T
+#define __wchar_t__	/* BeOS */
+#define _WCHAR_T
+#define _T_WCHAR_
+#define _T_WCHAR
+#define __WCHAR_T
+#define _WCHAR_T_
+#define _BSD_WCHAR_T_
+#define _WCHAR_T_DEFINED_
+#define _WCHAR_T_DEFINED
+#define _WCHAR_T_H
+#define ___int_wchar_t_h
+#define __INT_WCHAR_T_H
+#define _GCC_WCHAR_T
+
+/* On BSD/386 1.1, at least, machine/ansi.h defines _BSD_WCHAR_T_
+   instead of _WCHAR_T_, and _BSD_RUNE_T_ (which, unlike the other
+   symbols in the _FOO_T_ family, stays defined even after its
+   corresponding type is defined).  If we define wchar_t, then we
+   must undef _WCHAR_T_; for BSD/386 1.1 (and perhaps others), if
+   we undef _WCHAR_T_, then we must also define rune_t, since 
+   headers like runetype.h assume that if machine/ansi.h is included,
+   and _BSD_WCHAR_T_ is not defined, then rune_t is available.
+   machine/ansi.h says, "Note that _WCHAR_T_ and _RUNE_T_ must be of
+   the same type." */
+#ifdef _BSD_WCHAR_T_
+#undef _BSD_WCHAR_T_
+#ifdef _BSD_RUNE_T_
+#if !defined (_ANSI_SOURCE) && !defined (_POSIX_SOURCE)
+typedef _BSD_RUNE_T_ rune_t;
+#endif
+#endif
+#endif
+
+#ifndef __WCHAR_TYPE__
+#ifdef __BEOS__
+#define __WCHAR_TYPE__ unsigned char
+#else
+#define __WCHAR_TYPE__ int
+#endif
+#endif
+#ifndef __cplusplus
+typedef __WCHAR_TYPE__ wchar_t;
+#endif
+#endif
+#endif
+#endif
+#endif
+#endif
+#endif
+#endif
+#endif
+#endif
+#endif
+#endif
+#endif
+#endif /* __wchar_t__ */
+#undef	__need_wchar_t
+#endif /* _STDDEF_H or __need_wchar_t.  */
+
+#if defined (_STDDEF_H) || defined (__need_wint_t)
+#ifndef _WINT_T
+#define _WINT_T
+
+#ifndef __WINT_TYPE__
+#define __WINT_TYPE__ unsigned int
+#endif
+typedef __WINT_TYPE__ wint_t;
+#endif
+#undef __need_wint_t
+#endif
+
+/*  In 4.3bsd-net2, leave these undefined to indicate that size_t, etc.
+    are already defined.  */
+/*  BSD/OS 3.1 requires the MACHINE_ANSI_H check here.  FreeBSD 2.x apparently
+    does not, even though there is a check for MACHINE_ANSI_H above.  */
+#if defined(_ANSI_H_) || (defined(__bsdi__) && defined(_MACHINE_ANSI_H_))
+/*  The references to _GCC_PTRDIFF_T_, _GCC_SIZE_T_, and _GCC_WCHAR_T_
+    are probably typos and should be removed before 2.8 is released.  */
+#ifdef _GCC_PTRDIFF_T_
+#undef _PTRDIFF_T_
+#undef _BSD_PTRDIFF_T_
+#endif
+#ifdef _GCC_SIZE_T_
+#undef _SIZE_T_
+#undef _BSD_SIZE_T_
+#endif
+#ifdef _GCC_WCHAR_T_
+#undef _WCHAR_T_
+#undef _BSD_WCHAR_T_
+#endif
+/*  The following ones are the real ones.  */
+#ifdef _GCC_PTRDIFF_T
+#undef _PTRDIFF_T_
+#undef _BSD_PTRDIFF_T_
+#endif
+#ifdef _GCC_SIZE_T
+#undef _SIZE_T_
+#undef _BSD_SIZE_T_
+#endif
+#ifdef _GCC_WCHAR_T
+#undef _WCHAR_T_
+#undef _BSD_WCHAR_T_
+#endif
+#endif /* _ANSI_H_ || ( __bsdi__ && _MACHINE_ANSI_H_ ) */
+
+#endif /* __sys_stdtypes_h */
+
+/* A null pointer constant.  */
+
+#if defined (_STDDEF_H) || defined (__need_NULL)
+#undef NULL		/* in case <stdio.h> has defined it. */
+#ifdef __GNUG__
+#define NULL __null
+#else   /* G++ */
+#define NULL ((void *)0)
+#endif  /* G++ */
+#endif	/* NULL not defined and <stddef.h> or need NULL.  */
+#undef	__need_NULL
+
+#ifdef _STDDEF_H
+
+/* Offset of member MEMBER in a struct of type TYPE.  */
+
+#define offsetof(TYPE, MEMBER) ((size_t) &((TYPE *)0)->MEMBER)
+
+#endif /* _STDDEF_H was defined this time */
+
+#endif /* !_STDDEF_H && !_STDDEF_H_ && !_ANSI_STDDEF_H && !__STDDEF_H__
+	  || __need_XXX was not defined before */

usr/local/nachos/lib/gcc-lib/decstation-ultrix/2.95.2/include/syslimits.h

@@ -0,0 +1,8 @@
+/* syslimits.h stands for the system's own limits.h file.
+   If we can use it ok unmodified, then we install this text.
+   If fixincludes fixes it, then the fixed version is installed
+   instead of this text.  */
+
+#define _GCC_NEXT_LIMITS_H		/* tell gcc's limits.h to recurse */
+#include_next <limits.h>
+#undef _GCC_NEXT_LIMITS_H

usr/local/nachos/lib/gcc-lib/decstation-ultrix/2.95.2/include/va-alpha.h

@@ -0,0 +1,128 @@
+/* GNU C varargs and stdargs support for the DEC Alpha.  */
+
+/* Note:  We must use the name __builtin_savregs.  GCC attaches special
+   significance to that name.  In particular, regardless of where in a
+   function __builtin_saveregs is called, GCC moves the call up to the
+   very start of the function.  */
+
+/* Define __gnuc_va_list.  */
+
+#ifndef __GNUC_VA_LIST
+#define __GNUC_VA_LIST
+
+/* In VMS, __gnuc_va_list is simply char *; on OSF, it's a structure.  */
+
+#ifdef __VMS__
+typedef char *__gnuc_va_list;
+#else
+
+typedef struct {
+  char *__base;			/* Pointer to first integer register. */
+  int __offset;			/* Byte offset of args so far. */
+} __gnuc_va_list;
+#endif
+
+#endif /* __GNUC_VA_LIST */
+
+/* If this is for internal libc use, don't define anything but
+   __gnuc_va_list.  */
+
+#if !defined(__GNUC_VA_LIST_1) && (defined (_STDARG_H) || defined (_VARARGS_H))
+#define __GNUC_VA_LIST_1
+
+#define _VA_LIST
+#define _VA_LIST_
+
+typedef __gnuc_va_list va_list;
+
+#if !defined(_STDARG_H)
+
+/* varargs support */
+#define va_alist __builtin_va_alist
+#define va_dcl	 int __builtin_va_alist;...
+#ifdef __VMS__
+#define va_start(pvar) ((pvar) = __builtin_saveregs ())
+#else
+#define va_start(pvar) ((pvar) = * (__gnuc_va_list *) __builtin_saveregs ())
+#endif
+
+#else /* STDARG.H */
+
+/* ANSI alternative.  */
+
+/* Call __builtin_next_arg even though we aren't using its value, so that
+   we can verify that firstarg is correct.  */
+
+#ifdef __VMS__
+#define va_start(pvar, firstarg)				\
+  (__builtin_next_arg (firstarg),				\
+   (pvar) = __builtin_saveregs ())
+#else
+#define va_start(pvar, firstarg)				\
+  (__builtin_next_arg (firstarg),				\
+   (pvar) = *(__gnuc_va_list *) __builtin_saveregs ())
+#endif
+
+#endif /* _STDARG_H */
+
+#define va_end(__va)	((void) 0)
+
+/* Values returned by __builtin_classify_type.  */
+
+enum {
+  __no_type_class = -1,
+  __void_type_class,
+  __integer_type_class,
+  __char_type_class,
+  __enumeral_type_class,
+  __boolean_type_class,
+  __pointer_type_class,
+  __reference_type_class,
+  __offset_type_class,
+  __real_type_class,
+  __complex_type_class,
+  __function_type_class,
+  __method_type_class,
+  __record_type_class,
+  __union_type_class,
+  __array_type_class,
+  __string_type_class,
+  __set_type_class,
+  __file_type_class,
+  __lang_type_class
+};
+
+/* Note that parameters are always aligned at least to a word boundary
+   (when passed) regardless of what GCC's __alignof__ operator says.  */
+
+/* Avoid errors if compiling GCC v2 with GCC v1.  */
+#if __GNUC__ == 1
+#define __extension__
+#endif
+
+/* Get the size of a type in bytes, rounded up to an integral number
+   of words.  */
+
+#define __va_tsize(__type)  \
+  (((sizeof (__type) + __extension__ sizeof (long long) - 1)   \
+    / __extension__ sizeof (long long)) * __extension__ sizeof (long long))
+
+#ifdef __VMS__
+#define va_arg(__va, __type)						\
+(*(((__va) += __va_tsize (__type)),					\
+   (__type *)(void *)((__va) - __va_tsize (__type))))
+
+#else
+
+#define va_arg(__va, __type)						\
+(*(((__va).__offset += __va_tsize (__type)),				\
+   (__type *)(void *)((__va).__base + (__va).__offset			\
+	      - (((__builtin_classify_type (* (__type *) 0)		\
+		   == __real_type_class) && (__va).__offset <= (6 * 8))	\
+		 ? (6 * 8) + 8 : __va_tsize (__type)))))
+#endif
+
+/* Copy __gnuc_va_list into another variable of this type.  */
+#define __va_copy(dest, src) (dest) = (src)
+
+#endif /* __GNUC_VA_LIST_1 */

usr/local/nachos/lib/gcc-lib/decstation-ultrix/2.95.2/include/va-arc.h

@@ -0,0 +1,111 @@
+/* stdarg/varargs support for the ARC */
+
+/* Define __gnuc_va_list.  */
+
+#ifndef __GNUC_VA_LIST
+#define __GNUC_VA_LIST
+typedef void * __gnuc_va_list;
+#endif /* not __GNUC_VA_LIST */
+
+/* If this is for internal libc use, don't define anything but
+   __gnuc_va_list.  */
+#if defined (_STDARG_H) || defined (_VARARGS_H)
+
+/* In GCC version 2, we want an ellipsis at the end of the declaration
+   of the argument list.  GCC version 1 can't parse it.  */
+
+#if __GNUC__ > 1
+#define __va_ellipsis ...
+#else
+#define __va_ellipsis
+#endif
+
+/* See arc_setup_incoming_varargs for reasons for the oddity in va_start.  */
+#ifdef _STDARG_H
+#define va_start(AP, LASTARG) \
+(AP = (__gnuc_va_list) ((int *) __builtin_next_arg (LASTARG) \
+			+ (__builtin_args_info (0) < 8 \
+			   ? (__builtin_args_info (0) & 1) \
+			   : 0)))
+#else
+#define va_alist  __builtin_va_alist
+#define va_dcl    int __builtin_va_alist; __va_ellipsis
+#define va_start(AP) \
+(AP = (__gnuc_va_list) ((int *) &__builtin_va_alist \
+			+ (__builtin_args_info (0) < 8 \
+			   ? (__builtin_args_info (0) & 1) \
+			   : 0)))
+#endif
+
+#ifndef va_end
+void va_end (__gnuc_va_list);		/* Defined in libgcc.a */
+
+/* Values returned by __builtin_classify_type.  */
+
+enum __va_type_classes {
+  __no_type_class = -1,
+  __void_type_class,
+  __integer_type_class,
+  __char_type_class,
+  __enumeral_type_class,
+  __boolean_type_class,
+  __pointer_type_class,
+  __reference_type_class,
+  __offset_type_class,
+  __real_type_class,
+  __complex_type_class,
+  __function_type_class,
+  __method_type_class,
+  __record_type_class,
+  __union_type_class,
+  __array_type_class,
+  __string_type_class,
+  __set_type_class,
+  __file_type_class,
+  __lang_type_class
+};
+
+#endif
+#define va_end(AP)	((void)0)
+
+/* Avoid errors if compiling GCC v2 with GCC v1.  */
+#if __GNUC__ == 1
+#define __extension__
+#endif
+
+/* All aggregates are passed by reference.  All scalar types larger than 8
+   bytes are passed by reference.  */
+/* We cast to void * and then to TYPE * because this avoids
+   a warning about increasing the alignment requirement.
+   The casts to char * avoid warnings about invalid pointer arithmetic.  */
+
+#define __va_rounded_size(TYPE)  \
+  (((sizeof (TYPE) + sizeof (int) - 1) / sizeof (int)) * sizeof (int))
+
+#ifdef __big_endian__
+#define va_arg(AP,TYPE) \
+__extension__							\
+(*({((__builtin_classify_type (*(TYPE*) 0) >= __record_type_class \
+      || __va_rounded_size (TYPE) > 8)				\
+     ? ((AP) = (char *)(AP) + __va_rounded_size (TYPE *),	\
+	*(TYPE **) (void *) ((char *)(AP) - __va_rounded_size (TYPE *))) \
+     : ((TYPE *) (void *)					\
+	(AP = (void *) ((__alignof__ (TYPE) > 4			\
+			 ? ((int) AP + 8 - 1) & -8		\
+			 : (int) AP)				\
+			 + __va_rounded_size (TYPE))) - 1));}))
+#else
+#define va_arg(AP,TYPE) \
+__extension__							\
+(*({((__builtin_classify_type (*(TYPE*) 0) >= __record_type_class \
+      || __va_rounded_size (TYPE) > 8)				\
+     ? ((AP) = (char *)(AP) + __va_rounded_size (TYPE *),	\
+	*(TYPE **) (void *) ((char *)(AP) - __va_rounded_size (TYPE *))) \
+     : ((AP = (void *) ((__alignof__ (TYPE) > 4			\
+			? ((int) AP + 8 - 1) & -8		\
+			: (int) AP)				\
+		       + __va_rounded_size (TYPE))),		\
+	(TYPE *) (void *) (AP - __va_rounded_size (TYPE))));}))
+#endif
+
+#endif /* defined (_STDARG_H) || defined (_VARARGS_H) */

usr/local/nachos/lib/gcc-lib/decstation-ultrix/2.95.2/include/va-c4x.h

@@ -0,0 +1,34 @@
+/* GNU C varargs support for the TMS320C[34]x  */
+
+/* C[34]x arguments grow in weird ways (downwards) that the standard
+   varargs stuff can't handle. */
+
+#ifndef __GNUC_VA_LIST
+#define __GNUC_VA_LIST
+
+typedef void *__gnuc_va_list;
+
+#endif /* not __GNUC_VA_LIST */
+
+/* If this is for internal libc use, don't define anything but
+   __gnuc_va_list.  */
+#if defined (_STDARG_H) || defined (_VARARGS_H)
+
+#ifdef _STDARG_H /* stdarg.h support */
+
+#define va_start(AP,LASTARG) AP=(__gnuc_va_list) __builtin_next_arg (LASTARG)
+
+#else /* varargs.h support */
+
+#define	__va_ellipsis	...
+#define	va_alist	__builtin_va_alist
+#define	va_dcl		int __builtin_va_alist; __va_ellipsis
+#define va_start(AP)	AP=(__gnuc_va_list) ((int *)&__builtin_va_alist +  1)
+
+#endif /* _STDARG_H */
+
+#define va_end(AP)	((void) 0)
+#define va_arg(AP,TYPE)	(AP = (__gnuc_va_list) ((char *) (AP) - sizeof(TYPE)), \
+			 *((TYPE *) ((char *) (AP))))
+
+#endif /* defined (_STDARG_H) || defined (_VARARGS_H) */

usr/local/nachos/lib/gcc-lib/decstation-ultrix/2.95.2/include/va-clipper.h

@@ -0,0 +1,60 @@
+/* GNU C varargs and stdargs support for Clipper.  */
+
+/* Define __gnuc_va_list. */
+
+#ifndef __GNUC_VA_LIST
+#define __GNUC_VA_LIST
+
+typedef struct
+{
+  int __va_ap;				/* pointer to stack args */
+  void *__va_reg[4];			/* pointer to r0,f0,r1,f1 */
+  int __va_num;				/* number of args processed */
+} __gnuc_va_list;
+#endif /* not __GNUC_VA_LIST */
+
+
+#if defined (_STDARG_H) || defined (_VARARGS_H)
+typedef __gnuc_va_list va_list;
+#define __va_list __gnuc_va_list	/* acc compatibility */
+
+#define _VA_LIST
+#define _VA_LIST_
+#define _SYS_INT_STDARG_H		/* acc compatibility */
+
+/* Call __builtin_next_arg even though we aren't using its value, so that
+   we can verify that LASTARG is correct.  */
+#ifdef _STDARG_H
+#define va_start(AP,LASTARG)			\
+  (__builtin_next_arg (LASTARG),		\
+   (AP) = *(va_list *)__builtin_saveregs(),	\
+   (AP).__va_num = __builtin_args_info (0),	\
+   (AP).__va_ap += __builtin_args_info (1))
+#else
+#define va_alist  __builtin_va_alist
+/* The ... causes current_function_varargs to be set in cc1.  */
+#define va_dcl    va_list __builtin_va_alist; ...
+#define va_start(AP)				\
+  ((AP) = *(va_list *)__builtin_saveregs(),	\
+   (AP).__va_num = __builtin_args_info (0))
+#endif /* _STDARG_H */
+
+/* round to alignment of `type' but keep a least integer alignment */
+#define __va_round(AP,TYPE)					\
+  ((AP).__va_ap = ((AP).__va_ap + __alignof__ (TYPE) - 1 ) &	\
+   ~(__alignof__ (TYPE) - 1),					\
+  ((AP).__va_ap = ((AP).__va_ap + sizeof (int) - 1) & ~(sizeof (int) - 1)))
+
+#define va_arg(AP, TYPE) \
+  (*((AP).__va_num < 2 && __builtin_classify_type (* (TYPE *)0) < 12	\
+   ? (__builtin_classify_type (* (TYPE *)0) == 8			\
+      ? ((TYPE *)(AP).__va_reg[2 * (AP).__va_num++ + 1])		\
+      : ((TYPE *)(AP).__va_reg[2 * (AP).__va_num++ ]))			\
+   : ((AP).__va_num++, __va_round (AP,TYPE), ((TYPE *)((AP).__va_ap))++)))
+
+#define va_end(AP)	((void) 0)
+
+/* Copy __gnuc_va_list into another variable of this type.  */
+#define __va_copy(dest, src) (dest) = (src)
+
+#endif /* defined (_STDARG_H) || defined (_VARARGS_H) */

usr/local/nachos/lib/gcc-lib/decstation-ultrix/2.95.2/include/va-h8300.h

@@ -0,0 +1,56 @@
+/* stdarg/vararg support for the Hitachi h8/300 and h8/300h */
+
+/* Define __gnuc_va_list. */
+
+#ifndef __GNUC_VA_LIST
+#define __GNUC_VA_LIST
+typedef void *__gnuc_va_list;
+#endif
+
+/* If this is for internal libc use, don't define anything but
+   __gnuc_va_list.  */
+#if defined (_STDARG_H) || defined (_VARARGS_H)
+
+/* In GCC version 2, we want an ellipsis at the end of the declaration
+   of the argument list.  GCC version 1 can't parse it.  */
+
+#if __GNUC__ > 1
+#define __va_ellipsis ...
+#else
+#define __va_ellipsis
+#endif
+
+#ifdef __H8300__
+#define __va_rounded_size(TYPE)  \
+  (((sizeof (TYPE) + sizeof (int) - 1) / sizeof (int)) * sizeof (int))
+#else
+#define __va_rounded_size(TYPE)  \
+  (((sizeof (TYPE) + sizeof (long) - 1) / sizeof (long)) * sizeof (long))
+#endif
+
+#ifdef _STDARG_H
+
+#define va_start(AP,LASTARG) \
+  (AP = ((__gnuc_va_list) __builtin_next_arg (LASTARG)))
+
+#else /* _VARARGS_H */
+
+#define va_alist  __builtin_va_alist
+/* The ... causes current_function_varargs to be set in cc1.  */
+#define va_dcl    int __builtin_va_alist; __va_ellipsis
+#define va_start(AP)  AP = (void *) &__builtin_va_alist
+
+#endif /* _VARARGS_H */
+
+#define va_arg(AP, TYPE)						\
+ (AP = (__gnuc_va_list) ((char *) (AP) + __va_rounded_size (TYPE)),	\
+  *((TYPE *) (void *) ((char *) (AP)					\
+		       - ((sizeof (TYPE) < __va_rounded_size (int)	\
+			  ? sizeof (TYPE) : __va_rounded_size (TYPE))))))
+
+#define va_end(AP)	((void) 0)
+
+/* Copy __gnuc_va_list into another variable of this type.  */
+#define __va_copy(dest, src) (dest) = (src)
+
+#endif /* defined (_STDARG_H) || defined (_VARARGS_H) */

usr/local/nachos/lib/gcc-lib/decstation-ultrix/2.95.2/include/va-i860.h

@@ -0,0 +1,214 @@
+/* Note:  We must use the name __builtin_savregs.  GCC attaches special
+   significance to that name.  In particular, regardless of where in a
+   function __builtin_saveregs is called, GCC moves the call up to the
+   very start of the function.  */
+
+
+/* Define __gnuc_va_list.  */
+
+#ifndef __GNUC_VA_LIST
+#define __GNUC_VA_LIST
+
+typedef union {
+  float		__freg[8];
+  double	__dreg[4];
+} __f_regs;
+
+typedef struct {
+#if defined (__SVR4__) || defined (__svr4__) || defined (__alliant__) || defined (__PARAGON__)
+  __f_regs __float_regs; long __ireg[12];
+#else /* pre-SVR4 */
+  long __ireg[12]; __f_regs __float_regs;
+#endif
+} __va_saved_regs;
+
+typedef struct {
+#if defined(__SVR4__) || defined(__svr4__) || defined(__alliant__) || defined (__PARAGON__)
+  unsigned	__ireg_used;	/* How many int regs consumed 'til now? */
+  unsigned	__freg_used;	/* How many flt regs consumed 'til now? */
+  long		*__reg_base;	/* Address of where we stored the regs. */
+  long *	__mem_ptr;	/* Address of memory overflow args area. */
+#else /* pre-SVR4 */
+  long		*__reg_base;	/* Address of where we stored the regs. */
+  long *	__mem_ptr;	/* Address of memory overflow args area. */
+  unsigned	__ireg_used;	/* How many int regs consumed 'til now? */
+  unsigned	__freg_used;	/* How many flt regs consumed 'til now? */
+#endif
+} __gnuc_va_list;
+#endif /* not __GNUC_VA_LIST */
+
+/* If this is for internal libc use, don't define anything but
+   __gnuc_va_list.  */
+#if defined (_STDARG_H) || defined (_VARARGS_H)
+
+#if !defined(_STDARG_H)
+
+/* varargs support */
+#define va_alist __builtin_va_alist
+#if defined (__PARAGON__)
+#define va_dcl int va_alist;
+#else	/* __PARAGON__ */
+#define va_dcl
+#endif	/* __PARAGON__ */
+#define va_start(pvar) ((pvar) = * (__gnuc_va_list *) __builtin_saveregs ())
+
+#else /* STDARG.H */
+
+/* ANSI alternative.  */
+/* Note that CUMULATIVE_ARGS elements are measured in bytes on the i860,
+   so we divide by 4 to get # of registers.  */
+#define va_start(pvar, firstarg) \
+ ((pvar) = *(__gnuc_va_list *) __builtin_saveregs (),			\
+  (pvar).__ireg_used = __builtin_args_info (0) / 4,		\
+  (pvar).__freg_used = __builtin_args_info (1) / 4,		\
+  (pvar).__mem_ptr = __builtin_next_arg (firstarg))
+
+#endif /* _STDARG_H */
+
+/* Values returned by __builtin_classify_type.  */
+
+#ifndef va_end
+enum {
+  __no_type_class = -1,
+  __void_type_class,
+  __integer_type_class,
+  __char_type_class,
+  __enumeral_type_class,
+  __boolean_type_class,
+  __pointer_type_class,
+  __reference_type_class,
+  __offset_type_class,
+  __real_type_class,
+  __complex_type_class,
+  __function_type_class,
+  __method_type_class,
+  __record_type_class,
+  __union_type_class,
+  __array_type_class,
+  __string_type_class,
+  __set_type_class,
+  __file_type_class,
+  __lang_type_class
+};
+
+void va_end (__gnuc_va_list);		/* Defined in libgcc.a */
+#endif
+#define va_end(__va)	((void) 0)
+
+#define __NUM_PARM_FREGS	8
+#define __NUM_PARM_IREGS	12
+
+#define __savereg(__va) ((__va_saved_regs *) ((__va).__reg_base))
+
+/* This macro works both for SVR4 and pre-SVR4 environments.  */
+
+/* Note that parameters are always aligned at least to a word boundary
+   (when passed) regardless of what GCC's __alignof__ operator says.  */
+
+/* Make allowances here for adding 128-bit (long double) floats someday.  */
+
+#if 0 /* What was this for? */
+#ifndef __GNU_VA_LIST
+#define __ireg_used ireg_used
+#define __freg_used freg_used
+#define __mem_ptr mem_ptr
+#define __reg_base reg_base
+#endif
+#endif /* 0 */
+
+/* Avoid errors if compiling GCC v2 with GCC v1.  */
+#if __GNUC__ == 1
+#define __extension__
+#endif
+
+#define va_arg(__va, __type)						\
+__extension__								\
+(* (__type *)								\
+({									\
+  register void *__rv;  /* result value */				\
+  register unsigned __align;						\
+  switch (__builtin_classify_type (* (__type *) 0))			\
+    {									\
+    case __real_type_class:						\
+      switch (sizeof (__type))						\
+	{								\
+	  case sizeof (float):						\
+	  case sizeof (double):						\
+	    if ((__va).__freg_used < __NUM_PARM_FREGS - 1)		\
+	      {								\
+	        if (((__va).__freg_used & 1) != 0)			\
+	          (__va).__freg_used++;	/* skip odd */			\
+	        __rv = &__savereg((__va))->__float_regs.__freg[(__va).__freg_used];\
+		(__va).__freg_used += 2;				\
+	      }								\
+	    else							\
+	      {								\
+	        if ((((unsigned) (__va).__mem_ptr) & (sizeof(double)-1)) != 0) \
+	          (__va).__mem_ptr++;	/* skip odd */			\
+	        __rv = (__va).__mem_ptr;				\
+	        (__va).__mem_ptr += 2;					\
+	      }								\
+	    if (sizeof (__type) == sizeof (float))			\
+	      {								\
+	        *((float *) __rv) = *((double *) __rv);			\
+		*(((long *) __rv) + 1) = 0xfff00001;			\
+	      }								\
+	    break;							\
+	  default:							\
+	    abort ();							\
+	}								\
+      break;								\
+    case __void_type_class:						\
+    case __integer_type_class:						\
+    case __char_type_class:						\
+    case __enumeral_type_class:						\
+    case __boolean_type_class:						\
+    case __pointer_type_class:						\
+    case __reference_type_class:					\
+    case __offset_type_class:						\
+      if (sizeof (__type) <= 4)						\
+	{								\
+          __rv = ((__va).__ireg_used < __NUM_PARM_IREGS			\
+	          ? (&__savereg((__va))->__ireg[(__va).__ireg_used++])	\
+	          : (__va).__mem_ptr++);				\
+	  break;							\
+	}								\
+      else if ((__va).__ireg_used + sizeof (__type) / 4 <= __NUM_PARM_IREGS) \
+	{								\
+	  __rv = &__savereg((__va))->__ireg[(__va).__ireg_used];	\
+	  (__va).__ireg_used += sizeof (__type) / 4;			\
+          break;							\
+	}								\
+      /* Fall through to fetch from memory.  */				\
+    case __record_type_class:						\
+    case __union_type_class:						\
+      __align = (__alignof__ (__type) < sizeof (long)			\
+		 ? sizeof (long)					\
+		 : __alignof__ (__type));				\
+      (__va).__mem_ptr							\
+	= (long *)							\
+	  ((((unsigned) (__va).__mem_ptr) + (__align-1)) & ~(__align-1)); \
+      __rv = (__va).__mem_ptr;						\
+      (__va).__mem_ptr							\
+	+= ((sizeof (__type) + sizeof (long) - 1) / sizeof (long));	\
+      break;								\
+    case __complex_type_class:						\
+    case __function_type_class:						\
+    case __method_type_class:						\
+    case __array_type_class:						\
+    case __string_type_class:						\
+    case __set_type_class:						\
+    case __file_type_class:						\
+    case __lang_type_class:						\
+    case __no_type_class:						\
+    default:								\
+	abort ();							\
+    }									\
+  __rv;									\
+}))
+
+/* Copy __gnuc_va_list into another variable of this type.  */
+#define __va_copy(dest, src) (dest) = (src)
+
+#endif /* defined (_STDARG_H) || defined (_VARARGS_H) */
+

usr/local/nachos/lib/gcc-lib/decstation-ultrix/2.95.2/include/va-i960.h

@@ -0,0 +1,79 @@
+/* GNU C varargs support for the Intel 80960.  */
+
+/* Define __gnuc_va_list.  */
+
+#ifndef __GNUC_VA_LIST
+#define __GNUC_VA_LIST
+/* The first element is the address of the first argument.
+   The second element is the number of bytes skipped past so far.  */
+typedef unsigned __gnuc_va_list[2];	
+#endif /* not __GNUC_VA_LIST */
+
+/* If this is for internal libc use, don't define anything but
+   __gnuc_va_list.  */
+#if defined (_STDARG_H) || defined (_VARARGS_H)
+
+/* In GCC version 2, we want an ellipsis at the end of the declaration
+   of the argument list.  GCC version 1 can't parse it.  */
+
+#if __GNUC__ > 1
+#define __va_ellipsis ...
+#else
+#define __va_ellipsis
+#endif
+
+/* The stack size of the type t.  */
+#define __vsiz(T)   (((sizeof (T) + 3) / 4) * 4)
+/* The stack alignment of the type t.  */
+#define __vali(T)   (__alignof__ (T) >= 4 ? __alignof__ (T) : 4)
+/* The offset of the next stack argument after one of type t at offset i.  */
+#define __vpad(I, T) ((((I) + __vali (T) - 1) / __vali (T)) \
+		       * __vali (T) + __vsiz (T))
+
+/* Avoid errors if compiling GCC v2 with GCC v1.  */
+#if __GNUC__ == 1
+#define __extension__
+#endif
+
+#ifdef _STDARG_H
+/* Call __builtin_next_arg even though we aren't using its value, so that
+   we can verify that firstarg is correct.  */
+#define va_start(AP, LASTARG)				\
+__extension__						\
+({ __builtin_next_arg (LASTARG);			\
+   __asm__ ("st	g14,%0" : "=m" (*(AP)));		\
+   (AP)[1] = (__builtin_args_info (0) + __builtin_args_info (1)) * 4; })
+
+#else
+
+#define	va_alist __builtin_va_alist
+#define	va_dcl	 char *__builtin_va_alist; __va_ellipsis
+#define	va_start(AP) \
+__extension__						\
+({ __asm__ ("st	g14,%0" : "=m" (*(AP)));		\
+   (AP)[1] = (__builtin_args_info (0) + __builtin_args_info (1)) * 4; })
+#endif
+
+/* We cast to void * and then to TYPE * because this avoids
+   a warning about increasing the alignment requirement.  */
+#define	va_arg(AP, T)							\
+(									\
+  (									\
+    ((AP)[1] <= 48 && (__vpad ((AP)[1], T) > 48 || __vsiz (T) > 16))	\
+      ? ((AP)[1] = 48 + __vsiz (T))					\
+      : ((AP)[1] = __vpad ((AP)[1], T))					\
+  ),									\
+									\
+  *((T *) (void *) ((char *) *(AP) + (AP)[1] - __vsiz (T)))		\
+)
+
+#ifndef va_end
+void va_end (__gnuc_va_list);		/* Defined in libgcc.a */
+#endif
+#define	va_end(AP)	((void) 0)
+
+/* Copy __gnuc_va_list into another variable of this type.  */
+#define __va_copy(dest, src) (dest) = (src)
+
+#endif /* defined (_STDARG_H) || defined (_VARARGS_H) */
+

usr/local/nachos/lib/gcc-lib/decstation-ultrix/2.95.2/include/va-m32r.h

@@ -0,0 +1,86 @@
+/* GNU C stdarg/varargs support for the M32R */
+
+/* Define __gnuc_va_list.  */
+#ifndef __GNUC_VA_LIST
+#define __GNUC_VA_LIST
+typedef void *__gnuc_va_list;
+#endif /* not __GNUC_VA_LIST */
+
+/* If this is for internal libc use, don't define anything but
+   __gnuc_va_list.  */
+#if defined (_STDARG_H) || defined (_VARARGS_H)
+
+/* Common code for va_start for both varargs and stdarg.  */
+
+#define __va_rounded_size(TYPE)  \
+  (((sizeof (TYPE) + sizeof (int) - 1) / sizeof (int)) * sizeof (int))
+
+#ifdef _STDARG_H /* stdarg.h support */
+
+/* Calling __builtin_next_arg gives the proper error message if LASTARG is
+   not indeed the last argument.  */
+#define va_start(AP, LASTARG) 						\
+ (AP = ((__gnuc_va_list) __builtin_next_arg (LASTARG)))
+
+#else /* varargs.h support */
+
+#define va_alist  __builtin_va_alist
+/* The ... causes current_function_varargs to be set in cc1.  */
+#define va_dcl    int __builtin_va_alist; ...
+#define va_start(AP)  AP=(char *) &__builtin_va_alist
+
+#endif /* _STDARG_H */
+
+/* Nothing needs to be done to end varargs/stdarg processing */
+#define va_end(AP) ((void) 0)
+
+/* Values returned by __builtin_classify_type.  */
+enum __type_class
+{
+  __no_type_class = -1,
+  __void_type_class,
+  __integer_type_class,
+  __char_type_class,
+  __enumeral_type_class,
+  __boolean_type_class,
+  __pointer_type_class,
+  __reference_type_class,
+  __offset_type_class,
+  __real_type_class,
+  __complex_type_class,
+  __function_type_class,
+  __method_type_class,
+  __record_type_class,
+  __union_type_class,
+  __array_type_class,
+  __string_type_class,
+  __set_type_class,
+  __file_type_class,
+  __lang_type_class
+};
+
+/* Return whether a type is passed by reference.  */
+#define __va_by_reference_p(TYPE) (sizeof (TYPE) > 8)
+
+#define va_arg(AP,TYPE)							\
+__extension__ (*({							\
+  register TYPE *__ptr;							\
+									\
+  if (__va_by_reference_p (TYPE))					\
+    {									\
+      __ptr = *(TYPE **)(void *) (AP);					\
+      (AP) = (__gnuc_va_list) ((char *) (AP) + sizeof (void *));	\
+    }									\
+  else									\
+    {									\
+      __ptr = (TYPE *)(void *)						\
+        ((char *) (AP) + (sizeof (TYPE) < __va_rounded_size (char)	\
+			  ? __va_rounded_size (TYPE) - sizeof (TYPE)	\
+			  : 0));					\
+      (AP) = (__gnuc_va_list) ((char *) (AP) + __va_rounded_size (TYPE)); \
+    }									\
+									\
+  __ptr;								\
+}))
+
+#endif /* defined (_STDARG_H) || defined (_VARARGS_H) */

usr/local/nachos/lib/gcc-lib/decstation-ultrix/2.95.2/include/va-m88k.h

@@ -0,0 +1,87 @@
+/* GNU C varargs support for the Motorola 88100  */
+
+/* Define __gnuc_va_list.  */
+
+#ifndef __GNUC_VA_LIST
+#define __GNUC_VA_LIST
+
+typedef struct
+{
+  int  __va_arg;		/* argument number */
+  int *__va_stk;		/* start of args passed on stack */
+  int *__va_reg;		/* start of args passed in regs */
+} __gnuc_va_list;
+#endif /* not __GNUC_VA_LIST */
+
+/* If this is for internal libc use, don't define anything but
+   __gnuc_va_list.  */
+#if defined (_STDARG_H) || defined (_VARARGS_H)
+
+#ifdef _STDARG_H /* stdarg.h support */
+
+/* Call __builtin_next_arg even though we aren't using its value, so that
+   we can verify that LASTARG is correct.  */
+#if __GNUC__ > 1 /* GCC 2.0 and beyond */
+#define va_start(AP,LASTARG)				\
+ (__builtin_next_arg (LASTARG),				\
+  (AP) = *(__gnuc_va_list *)__builtin_saveregs())
+#else
+#define va_start(AP,LASTARG) \
+  ( (AP).__va_reg = (int *) __builtin_saveregs2(0), \
+    (AP).__va_stk = (int *) __builtin_argptr(), \
+    (AP).__va_arg = (int) (__builtin_argsize() + 3) / 4 )
+#endif
+
+#else /* varargs.h support */
+
+#if __GNUC__ > 1 /* GCC 2.0 and beyond */
+#define va_start(AP) ((AP) = *(__gnuc_va_list *)__builtin_saveregs())
+#else
+#define va_start(AP) \
+  ( (AP).__va_reg = (int *) __builtin_saveregs2(1), \
+    (AP).__va_stk = (int *) __builtin_argptr(), \
+    (AP).__va_arg = (int) (__builtin_argsize() - 4 + 3) / 4 )
+#endif
+#define va_alist __va_1st_arg
+#define va_dcl register int va_alist;...
+
+#endif /* _STDARG_H */
+
+/* Avoid trouble between this file and _int_varargs.h under DG/UX.  This file
+   can be included by <stdio.h> and others and provides definitions of
+   __va_size and __va_reg_p and  a va_list typedef.  Avoid defining va_list
+   again with _VA_LIST.  */
+#ifdef __INT_VARARGS_H
+#undef __va_size
+#undef __va_reg_p
+#define __gnuc_va_list va_list
+#define _VA_LIST
+#define _VA_LIST_
+#else
+/* Similarly, if this gets included first, do nothing in _int_varargs.h.  */
+#define __INT_VARARGS_H
+#endif
+
+#define __va_reg_p(TYPE) \
+  (__builtin_classify_type(*(TYPE *)0) < 12 \
+   ? sizeof(TYPE) <= 8 : sizeof(TYPE) == 4 && __alignof__(TYPE) == 4)
+
+#define	__va_size(TYPE) ((sizeof(TYPE) + 3) >> 2)
+
+/* We cast to void * and then to TYPE * because this avoids
+   a warning about increasing the alignment requirement.  */
+#define va_arg(AP,TYPE)							   \
+  ( (AP).__va_arg = (((AP).__va_arg + (1 << (__alignof__(TYPE) >> 3)) - 1) \
+		     & ~((1 << (__alignof__(TYPE) >> 3)) - 1))		   \
+    + __va_size(TYPE),							   \
+    *((TYPE *) (void *) ((__va_reg_p(TYPE)				   \
+			  && (AP).__va_arg < 8 + __va_size(TYPE)	   \
+			  ? (AP).__va_reg : (AP).__va_stk)		   \
+			 + ((AP).__va_arg - __va_size(TYPE)))))
+
+#define va_end(AP)	((void)0)
+
+/* Copy __gnuc_va_list into another variable of this type.  */
+#define __va_copy(dest, src) (dest) = (src)
+
+#endif /* defined (_STDARG_H) || defined (_VARARGS_H) */

usr/local/nachos/lib/gcc-lib/decstation-ultrix/2.95.2/include/va-mips.h

@@ -0,0 +1,277 @@
+/* ---------------------------------------- */
+/*           VARARGS  for MIPS/GNU CC       */
+/*                                          */
+/*                                          */
+/*                                          */
+/*                                          */
+/* ---------------------------------------- */
+
+
+/* These macros implement varargs for GNU C--either traditional or ANSI.  */
+
+/* Define __gnuc_va_list.  */
+
+#ifndef __GNUC_VA_LIST
+#define __GNUC_VA_LIST
+#if defined (__mips_eabi) && ! defined (__mips_soft_float) && ! defined (__mips_single_float)
+
+typedef struct {
+  /* Pointer to FP regs.  */
+  char *__fp_regs;
+  /* Number of FP regs remaining.  */
+  int __fp_left;
+  /* Pointer to GP regs followed by stack parameters.  */
+  char *__gp_regs;
+} __gnuc_va_list;
+
+#else /* ! (defined (__mips_eabi) && ! defined (__mips_soft_float) && ! defined (__mips_single_float)) */
+
+typedef char * __gnuc_va_list;
+
+#endif /* ! (defined (__mips_eabi) && ! defined (__mips_soft_float) && ! defined (__mips_single_float)) */
+#endif /* not __GNUC_VA_LIST */
+
+/* If this is for internal libc use, don't define anything but
+   __gnuc_va_list.  */
+#if defined (_STDARG_H) || defined (_VARARGS_H)
+
+#ifndef _VA_MIPS_H_ENUM
+#define _VA_MIPS_H_ENUM
+enum {
+  __no_type_class = -1,
+  __void_type_class,
+  __integer_type_class,
+  __char_type_class,
+  __enumeral_type_class,
+  __boolean_type_class,
+  __pointer_type_class,
+  __reference_type_class,
+  __offset_type_class,
+  __real_type_class,
+  __complex_type_class,
+  __function_type_class,
+  __method_type_class,
+  __record_type_class,
+  __union_type_class,
+  __array_type_class,
+  __string_type_class,
+  __set_type_class,
+  __file_type_class,
+  __lang_type_class
+};
+#endif
+
+/* In GCC version 2, we want an ellipsis at the end of the declaration
+   of the argument list.  GCC version 1 can't parse it.  */
+
+#if __GNUC__ > 1
+#define __va_ellipsis ...
+#else
+#define __va_ellipsis
+#endif
+
+#ifdef __mips64
+#define __va_rounded_size(__TYPE)  \
+  (((sizeof (__TYPE) + 8 - 1) / 8) * 8)
+#else
+#define __va_rounded_size(__TYPE)  \
+  (((sizeof (__TYPE) + sizeof (int) - 1) / sizeof (int)) * sizeof (int))
+#endif
+
+#ifdef __mips64
+#define __va_reg_size 8
+#else
+#define __va_reg_size 4
+#endif
+
+/* Get definitions for _MIPS_SIM_ABI64 etc.  */
+#ifdef _MIPS_SIM
+#include <sgidefs.h>
+#endif
+
+#ifdef _STDARG_H
+#if defined (__mips_eabi)
+#if ! defined (__mips_soft_float) && ! defined (__mips_single_float)
+#ifdef __mips64
+#define va_start(__AP, __LASTARG)					\
+  (__AP.__gp_regs = ((char *) __builtin_next_arg (__LASTARG)		\
+		     - (__builtin_args_info (2) < 8			\
+			? (8 - __builtin_args_info (2)) * __va_reg_size	\
+			: 0)),						\
+   __AP.__fp_left = 8 - __builtin_args_info (3),			\
+   __AP.__fp_regs = __AP.__gp_regs - __AP.__fp_left * __va_reg_size)
+#else /* ! defined (__mips64) */
+#define va_start(__AP, __LASTARG)					\
+  (__AP.__gp_regs = ((char *) __builtin_next_arg (__LASTARG)		\
+		     - (__builtin_args_info (2) < 8			\
+			? (8 - __builtin_args_info (2)) * __va_reg_size	\
+			: 0)),						\
+   __AP.__fp_left = (8 - __builtin_args_info (3)) / 2,			\
+   __AP.__fp_regs = __AP.__gp_regs - __AP.__fp_left * 8,		\
+   __AP.__fp_regs = (char *) ((int) __AP.__fp_regs & -8))
+#endif /* ! defined (__mips64) */
+#else /* ! (! defined (__mips_soft_float) && ! defined (__mips_single_float) ) */
+#define va_start(__AP, __LASTARG)					\
+  (__AP = ((__gnuc_va_list) __builtin_next_arg (__LASTARG)		\
+	   - (__builtin_args_info (2) >= 8 ? 0				\
+	      : (8 - __builtin_args_info (2)) * __va_reg_size)))
+#endif /* ! (! defined (__mips_soft_float) && ! defined (__mips_single_float) ) */
+#else /* ! defined (__mips_eabi) */
+#define va_start(__AP, __LASTARG) \
+  (__AP = (__gnuc_va_list) __builtin_next_arg (__LASTARG))
+#endif /* ! (defined (__mips_eabi) && ! defined (__mips_soft_float) && ! defined (__mips_single_float)) */
+#else /* ! _STDARG_H */
+#define va_alist  __builtin_va_alist
+#ifdef __mips64
+/* This assumes that `long long int' is always a 64 bit type.  */
+#define va_dcl    long long int __builtin_va_alist; __va_ellipsis
+#else
+#define va_dcl    int __builtin_va_alist; __va_ellipsis
+#endif
+#if defined (__mips_eabi)
+#if ! defined (__mips_soft_float) && ! defined (__mips_single_float)
+#ifdef __mips64
+#define va_start(__AP)							\
+  (__AP.__gp_regs = ((char *) __builtin_next_arg ()			\
+		     - (__builtin_args_info (2) < 8			\
+			? (8 - __builtin_args_info (2)) * __va_reg_size	\
+			: __va_reg_size)),				\
+   __AP.__fp_left = 8 - __builtin_args_info (3),			\
+   __AP.__fp_regs = __AP.__gp_regs - __AP.__fp_left * __va_reg_size)
+#else /* ! defined (__mips64) */
+#define va_start(__AP)							\
+  (__AP.__gp_regs = ((char *) __builtin_next_arg ()			\
+		     - (__builtin_args_info (2) < 8			\
+			? (8 - __builtin_args_info (2)) * __va_reg_size	\
+			: __va_reg_size)),				\
+   __AP.__fp_left = (8 - __builtin_args_info (3)) / 2,			\
+   __AP.__fp_regs = __AP.__gp_regs - __AP.__fp_left * 8,		\
+   __AP.__fp_regs = (char *) ((int) __AP.__fp_regs & -8))
+#endif /* ! defined (__mips64) */
+#else /* ! (! defined (__mips_soft_float) && ! defined (__mips_single_float)) */
+#define va_start(__AP)							\
+  (__AP = ((__gnuc_va_list) __builtin_next_arg ()			\
+	   - (__builtin_args_info (2) >= 8 ? __va_reg_size		\
+	      : (8 - __builtin_args_info (2)) * __va_reg_size)))
+#endif /* ! (! defined (__mips_soft_float) && ! defined (__mips_single_float)) */
+/* Need alternate code for _MIPS_SIM_ABI64.  */
+#elif defined(_MIPS_SIM) && (_MIPS_SIM == _MIPS_SIM_ABI64 || _MIPS_SIM == _MIPS_SIM_NABI32)
+#define va_start(__AP)							\
+  (__AP = (__gnuc_va_list) __builtin_next_arg ()			\
+   + (__builtin_args_info (2) >= 8 ? -8 : 0))
+#else
+#define va_start(__AP)  __AP = (char *) &__builtin_va_alist
+#endif
+#endif /* ! _STDARG_H */
+
+#ifndef va_end
+void va_end (__gnuc_va_list);		/* Defined in libgcc.a */
+#endif
+#define va_end(__AP)	((void)0)
+
+#if defined (__mips_eabi)
+
+#if ! defined (__mips_soft_float) && ! defined (__mips_single_float)
+#ifdef __mips64
+#define __va_next_addr(__AP, __type)					\
+  ((__builtin_classify_type (*(__type *) 0) == __real_type_class	\
+    && __AP.__fp_left > 0)						\
+   ? (--__AP.__fp_left, (__AP.__fp_regs += 8) - 8)			\
+   : (__AP.__gp_regs += __va_reg_size) - __va_reg_size)
+#else
+#define __va_next_addr(__AP, __type)					\
+  ((__builtin_classify_type (*(__type *) 0) == __real_type_class	\
+    && __AP.__fp_left > 0)						\
+   ? (--__AP.__fp_left, (__AP.__fp_regs += 8) - 8)			\
+   : (((__builtin_classify_type (* (__type *) 0) < __record_type_class	\
+	&& __alignof__ (__type) > 4)					\
+       ? __AP.__gp_regs = (char *) (((int) __AP.__gp_regs + 8 - 1) & -8) \
+       : (char *) 0),							\
+      (__builtin_classify_type (* (__type *) 0) >= __record_type_class	\
+       ? (__AP.__gp_regs += __va_reg_size) - __va_reg_size		\
+       : ((__AP.__gp_regs += __va_rounded_size (__type))		\
+	  - __va_rounded_size (__type)))))
+#endif
+#else /* ! (! defined (__mips_soft_float) && ! defined (__mips_single_float)) */
+#ifdef __mips64
+#define __va_next_addr(__AP, __type)					\
+  ((__AP += __va_reg_size) - __va_reg_size)
+#else
+#define __va_next_addr(__AP, __type)					\
+  (((__builtin_classify_type (* (__type *) 0) < __record_type_class	\
+     && __alignof__ (__type) > 4)					\
+    ? __AP = (char *) (((__PTRDIFF_TYPE__) __AP + 8 - 1) & -8)		\
+    : (char *) 0),							\
+   (__builtin_classify_type (* (__type *) 0) >= __record_type_class	\
+    ? (__AP += __va_reg_size) - __va_reg_size				\
+    : ((__AP += __va_rounded_size (__type))				\
+       - __va_rounded_size (__type))))
+#endif
+#endif /* ! (! defined (__mips_soft_float) && ! defined (__mips_single_float)) */
+
+#ifdef __MIPSEB__
+#define va_arg(__AP, __type)						\
+  ((__va_rounded_size (__type) <= __va_reg_size)			\
+   ? *(__type *) (void *) (__va_next_addr (__AP, __type)		\
+			   + __va_reg_size				\
+			   - sizeof (__type))				\
+   : (__builtin_classify_type (*(__type *) 0) >= __record_type_class	\
+      ? **(__type **) (void *) (__va_next_addr (__AP, __type)		\
+				+ __va_reg_size				\
+				- sizeof (char *))			\
+      : *(__type *) (void *) __va_next_addr (__AP, __type)))
+#else
+#define va_arg(__AP, __type)						\
+  ((__va_rounded_size (__type) <= __va_reg_size)			\
+   ? *(__type *) (void *) __va_next_addr (__AP, __type)		\
+   : (__builtin_classify_type (* (__type *) 0) >= __record_type_class	\
+      ? **(__type **) (void *) __va_next_addr (__AP, __type)		\
+      : *(__type *) (void *) __va_next_addr (__AP, __type)))
+#endif
+
+#else /* ! defined (__mips_eabi) */
+
+/* We cast to void * and then to TYPE * because this avoids
+   a warning about increasing the alignment requirement.  */
+/* The __mips64 cases are reversed from the 32 bit cases, because the standard
+   32 bit calling convention left-aligns all parameters smaller than a word,
+   whereas the __mips64 calling convention does not (and hence they are
+   right aligned).  */
+#ifdef __mips64
+#ifdef __MIPSEB__
+#define va_arg(__AP, __type)                                    \
+  ((__type *) (void *) (__AP = (char *)                         \
+                       ((((__PTRDIFF_TYPE__)__AP + 8 - 1) & -8) \
+			   + __va_rounded_size (__type))))[-1]
+#else
+#define va_arg(__AP, __type)                                    \
+  ((__AP = (char *) ((((__PTRDIFF_TYPE__)__AP + 8 - 1) & -8)	\
+		     + __va_rounded_size (__type))),		\
+   *(__type *) (void *) (__AP - __va_rounded_size (__type)))
+#endif
+
+#else /* not __mips64 */
+
+#ifdef __MIPSEB__
+/* For big-endian machines.  */
+#define va_arg(__AP, __type)					\
+  ((__AP = (char *) ((__alignof__ (__type) > 4			\
+		      ? ((__PTRDIFF_TYPE__)__AP + 8 - 1) & -8	\
+		      : ((__PTRDIFF_TYPE__)__AP + 4 - 1) & -4)	\
+		     + __va_rounded_size (__type))),		\
+   *(__type *) (void *) (__AP - __va_rounded_size (__type)))
+#else
+/* For little-endian machines.  */
+#define va_arg(__AP, __type)						    \
+  ((__type *) (void *) (__AP = (char *) ((__alignof__(__type) > 4	    \
+				? ((__PTRDIFF_TYPE__)__AP + 8 - 1) & -8	    \
+				: ((__PTRDIFF_TYPE__)__AP + 4 - 1) & -4)    \
+					 + __va_rounded_size(__type))))[-1]
+#endif
+#endif
+#endif /* ! defined (__mips_eabi)  */
+
+/* Copy __gnuc_va_list into another variable of this type.  */
+#define __va_copy(dest, src) (dest) = (src)
+
+#endif /* defined (_STDARG_H) || defined (_VARARGS_H) */

usr/local/nachos/lib/gcc-lib/decstation-ultrix/2.95.2/include/va-mn10200.h

@@ -0,0 +1,37 @@
+/* CYGNUS LOCAL entire file/law */
+/* Define __gnuc_va_list. */
+
+#ifndef __GNUC_VA_LIST
+#define __GNUC_VA_LIST
+typedef void *__gnuc_va_list;
+#endif /* not __GNUC_VA_LIST */
+
+/* If this is for internal libc use, don't define anything but
+   __gnuc_va_list.  */
+#if defined (_STDARG_H) || defined (_VARARGS_H)
+#define __gnuc_va_start(AP) (AP = (__gnuc_va_list)__builtin_saveregs())
+#define __va_ellipsis ...
+
+#ifdef _STDARG_H
+#define va_start(AP, LASTARG) \
+ (AP = ((__gnuc_va_list) __builtin_next_arg (LASTARG)))
+#else
+#define va_alist __builtin_va_alist
+#define va_dcl int __builtin_va_alist; __va_ellipsis
+#define va_start(AP)  AP=(char *) &__builtin_va_alist
+#endif
+
+/* Now stuff common to both varargs & stdarg implementations.  */
+#define __va_rounded_size(TYPE)						\
+  (((sizeof (TYPE) + sizeof (int) - 1) / sizeof (int)) * sizeof (int))
+#undef va_end
+void va_end (__gnuc_va_list);
+#define va_end(AP) ((void)0)
+#define va_arg(AP, TYPE)						\
+ (sizeof (TYPE) > 8							\
+  ? (AP = (__gnuc_va_list) ((char *) (AP) + __va_rounded_size (char *)),\
+    **((TYPE **) (void *) ((char *) (AP) - __va_rounded_size (char *))))\
+  : (AP = (__gnuc_va_list) ((char *) (AP) + __va_rounded_size (TYPE)),	\
+    *((TYPE *) (void *) ((char *) (AP) - __va_rounded_size (TYPE)))))
+#endif
+/* END CYGNUS LOCAL */

usr/local/nachos/lib/gcc-lib/decstation-ultrix/2.95.2/include/va-mn10300.h

@@ -0,0 +1,35 @@
+/* Define __gnuc_va_list. */
+
+#ifndef __GNUC_VA_LIST
+#define __GNUC_VA_LIST
+typedef void *__gnuc_va_list;
+#endif /* not __GNUC_VA_LIST */
+
+/* If this is for internal libc use, don't define anything but
+   __gnuc_va_list.  */
+#if defined (_STDARG_H) || defined (_VARARGS_H)
+#define __gnuc_va_start(AP) (AP = (__gnuc_va_list)__builtin_saveregs())
+#define __va_ellipsis ...
+
+#ifdef _STDARG_H
+#define va_start(AP, LASTARG) \
+  (__builtin_next_arg (LASTARG), __gnuc_va_start (AP))
+#else
+#define va_alist __builtin_va_alist
+#define va_dcl int __builtin_va_alist; __va_ellipsis
+#define va_start(AP)  AP=(char *) &__builtin_va_alist
+#endif
+
+/* Now stuff common to both varargs & stdarg implementations.  */
+#define __va_rounded_size(TYPE)						\
+  (((sizeof (TYPE) + sizeof (int) - 1) / sizeof (int)) * sizeof (int))
+#undef va_end
+void va_end (__gnuc_va_list);
+#define va_end(AP) ((void)0)
+#define va_arg(AP, TYPE)						\
+ (sizeof (TYPE) > 8							\
+  ? (AP = (__gnuc_va_list) ((char *) (AP) + __va_rounded_size (char *)),\
+    **((TYPE **) (void *) ((char *) (AP) - __va_rounded_size (char *))))\
+  : (AP = (__gnuc_va_list) ((char *) (AP) + __va_rounded_size (TYPE)),	\
+    *((TYPE *) (void *) ((char *) (AP) - __va_rounded_size (TYPE)))))
+#endif

usr/local/nachos/lib/gcc-lib/decstation-ultrix/2.95.2/include/va-pa.h

@@ -0,0 +1,52 @@
+
+/* Define __gnuc_va_list. */
+
+#ifndef __GNUC_VA_LIST
+#define __GNUC_VA_LIST
+
+typedef void *__gnuc_va_list;
+#endif /* not __GNUC_VA_LIST */
+
+/* If this is for internal libc use, don't define anything but
+   __gnuc_va_list.  */
+#if defined (_STDARG_H) || defined (_VARARGS_H)
+#if __GNUC__ > 1
+#define __va_ellipsis ...
+#define __gnuc_va_start(AP) ((AP) = (va_list)__builtin_saveregs())
+#else
+#define va_alist __va_a__, __va_b__, __va_c__, __va_d__
+#define __va_ellipsis 
+#define __gnuc_va_start(AP)\
+  (AP) = (double *) &__va_a__, &__va_b__, &__va_c__, &__va_d__, \
+  (AP) = (double *)((char *)(AP) + 4)
+#endif /* __GNUC__ > 1 */
+
+/* Call __builtin_next_arg even though we aren't using its value, so that
+   we can verify that LASTARG is correct.  */
+#ifdef _STDARG_H
+#define va_start(AP,LASTARG) \
+  (__builtin_next_arg (LASTARG), __gnuc_va_start (AP))
+#else
+/* The ... causes current_function_varargs to be set in cc1.  */
+#define va_dcl long va_alist; __va_ellipsis
+#define va_start(AP) __gnuc_va_start (AP)
+#endif
+
+#define va_arg(AP,TYPE)						\
+  (*(sizeof(TYPE) > 8 ?						\
+   ((AP = (__gnuc_va_list) ((char *)AP - sizeof (int))),	\
+    (((TYPE *) (void *) (*((int *) (AP))))))			\
+   :((AP =							\
+      (__gnuc_va_list) ((long)((char *)AP - sizeof (TYPE))	\
+			& (sizeof(TYPE) > 4 ? ~0x7 : ~0x3))),	\
+     (((TYPE *) (void *) ((char *)AP + ((8 - sizeof(TYPE)) % 4)))))))
+
+#ifndef va_end
+void va_end (__gnuc_va_list);		/* Defined in libgcc.a */
+#endif
+#define va_end(AP)	((void)0)
+
+/* Copy __gnuc_va_list into another variable of this type.  */
+#define __va_copy(dest, src) (dest) = (src)
+
+#endif /* defined (_STDARG_H) || defined (_VARARGS_H) */

usr/local/nachos/lib/gcc-lib/decstation-ultrix/2.95.2/include/va-ppc.h

@@ -0,0 +1,255 @@
+/* GNU C varargs support for the PowerPC with either the V.4 or Windows NT calling sequences */
+
+#ifndef _WIN32
+/* System V.4 support */
+/* Define __gnuc_va_list.  */
+
+#ifndef __GNUC_VA_LIST
+#define __GNUC_VA_LIST
+
+#ifndef _SYS_VA_LIST_H
+#define _SYS_VA_LIST_H		/* Solaris sys/va_list.h */
+
+/* Solaris decided to rename overflow_arg_area to input_arg_area,
+   so handle it via a macro.  */
+#define __va_overflow(AP) (AP)->overflow_arg_area
+
+/* Note that the names in this structure are in the user's namespace, but
+   that the V.4 abi explicitly states that these names should be used.  */
+typedef struct __va_list_tag {
+  unsigned char gpr;		/* index into the array of 8 GPRs stored in the
+				   register save area gpr=0 corresponds to r3,
+				   gpr=1 to r4, etc. */
+  unsigned char fpr;		/* index into the array of 8 FPRs stored in the
+				   register save area fpr=0 corresponds to f1,
+				   fpr=1 to f2, etc. */
+  char *overflow_arg_area;	/* location on stack that holds the next
+				   overflow argument */
+  char *reg_save_area;		/* where r3:r10 and f1:f8, if saved are stored */
+} __va_list[1], __gnuc_va_list[1];
+
+#else /* _SYS_VA_LIST */
+
+typedef __va_list __gnuc_va_list;
+#define __va_overflow(AP) (AP)->input_arg_area
+
+#endif /* not _SYS_VA_LIST */
+#endif /* not __GNUC_VA_LIST */
+
+/* If this is for internal libc use, don't define anything but
+   __gnuc_va_list.  */
+#if defined (_STDARG_H) || defined (_VARARGS_H)
+
+/* Register save area located below the frame pointer */
+#ifndef __VA_PPC_H__
+#define __VA_PPC_H__
+typedef struct {
+  long   __gp_save[8];		/* save area for GP registers */
+  double __fp_save[8];		/* save area for FP registers */
+} __va_regsave_t;
+
+/* Macros to access the register save area */
+/* We cast to void * and then to TYPE * because this avoids
+   a warning about increasing the alignment requirement.  */
+#define __VA_FP_REGSAVE(AP,OFS,TYPE)					\
+  ((TYPE *) (void *) (&(((__va_regsave_t *)				\
+			 (AP)->reg_save_area)->__fp_save[OFS])))
+
+#define __VA_GP_REGSAVE(AP,OFS,TYPE)					\
+  ((TYPE *) (void *) (&(((__va_regsave_t *)				\
+			 (AP)->reg_save_area)->__gp_save[OFS])))
+
+/* Common code for va_start for both varargs and stdarg.  We allow all
+   the work to be done by __builtin_saveregs.  It returns a pointer to
+   a va_list that was constructed on the stack; we must simply copy it
+   to the user's variable.  */
+
+#define __va_start_common(AP, FAKE) \
+  __builtin_memcpy ((AP), __builtin_saveregs (), sizeof(__gnuc_va_list))
+
+#ifdef _STDARG_H /* stdarg.h support */
+
+/* Calling __builtin_next_arg gives the proper error message if LASTARG is
+   not indeed the last argument.  */
+#define va_start(AP,LASTARG) \
+  (__builtin_next_arg (LASTARG), __va_start_common (AP, 0))
+
+#else /* varargs.h support */
+
+#define va_start(AP) __va_start_common (AP, 1)
+#define va_alist __va_1st_arg
+#define va_dcl register int va_alist; ...
+
+#endif /* _STDARG_H */
+
+#ifdef _SOFT_FLOAT
+#define __va_float_p(TYPE)	0
+#else
+#define __va_float_p(TYPE)	(__builtin_classify_type(*(TYPE *)0) == 8)
+#endif
+
+#define __va_aggregate_p(TYPE)	(__builtin_classify_type(*(TYPE *)0) >= 12)
+#define __va_size(TYPE)		((sizeof(TYPE) + sizeof (long) - 1) / sizeof (long))
+
+/* This symbol isn't defined.  It is used to flag type promotion violations
+   at link time.  We can only do this when optimizing.  Use __builtin_trap
+   instead of abort so that we don't require a prototype for abort.
+
+   __builtin_trap stuff is not available on the gcc-2.95 branch, so we just
+   avoid calling it for now.  */
+
+#ifdef __OPTIMIZE__
+extern void __va_arg_type_violation(void) __attribute__((__noreturn__));
+#else
+#define __va_arg_type_violation()
+#endif
+
+#define va_arg(AP,TYPE)							   \
+__extension__ (*({							   \
+  register TYPE *__ptr;							   \
+									   \
+  if (__va_float_p (TYPE) && sizeof (TYPE) < 16)			   \
+    {									   \
+      unsigned char __fpr = (AP)->fpr;					   \
+      if (__fpr < 8)							   \
+	{								   \
+	  __ptr = __VA_FP_REGSAVE (AP, __fpr, TYPE);			   \
+	  (AP)->fpr = __fpr + 1;					   \
+	}								   \
+      else if (sizeof (TYPE) == 8)					   \
+	{								   \
+	  unsigned long __addr = (unsigned long) (__va_overflow (AP));	   \
+	  __ptr = (TYPE *)((__addr + 7) & -8);				   \
+	  __va_overflow (AP) = (char *)(__ptr + 1);			   \
+	}								   \
+      else								   \
+	{								   \
+	  /* float is promoted to double.  */				   \
+	  __va_arg_type_violation ();					   \
+	}								   \
+    }									   \
+									   \
+  /* Aggregates and long doubles are passed by reference.  */		   \
+  else if (__va_aggregate_p (TYPE) || __va_float_p (TYPE))		   \
+    {									   \
+      unsigned char __gpr = (AP)->gpr;					   \
+      if (__gpr < 8)							   \
+	{								   \
+	  __ptr = * __VA_GP_REGSAVE (AP, __gpr, TYPE *);		   \
+	  (AP)->gpr = __gpr + 1;					   \
+	}								   \
+      else								   \
+	{								   \
+	  TYPE **__pptr = (TYPE **) (__va_overflow (AP));		   \
+	  __ptr = * __pptr;						   \
+	  __va_overflow (AP) = (char *) (__pptr + 1);			   \
+	}								   \
+    }									   \
+									   \
+  /* Only integrals remaining.  */					   \
+  else									   \
+    {									   \
+      /* longlong is aligned.  */					   \
+      if (sizeof (TYPE) == 8)						   \
+	{								   \
+	  unsigned char __gpr = (AP)->gpr;				   \
+	  if (__gpr < 7)						   \
+	    {								   \
+	      __gpr += __gpr & 1;					   \
+	      __ptr = __VA_GP_REGSAVE (AP, __gpr, TYPE);		   \
+	      (AP)->gpr = __gpr + 2;					   \
+	    }								   \
+	  else								   \
+	    {								   \
+	      unsigned long __addr = (unsigned long) (__va_overflow (AP)); \
+	      __ptr = (TYPE *)((__addr + 7) & -8);			   \
+	      (AP)->gpr = 8;						   \
+	      __va_overflow (AP) = (char *)(__ptr + 1);			   \
+	    }								   \
+	}								   \
+      else if (sizeof (TYPE) == 4)					   \
+	{								   \
+	  unsigned char __gpr = (AP)->gpr;				   \
+	  if (__gpr < 8)						   \
+	    {								   \
+	      __ptr = __VA_GP_REGSAVE (AP, __gpr, TYPE);		   \
+	      (AP)->gpr = __gpr + 1;					   \
+	    }								   \
+	  else								   \
+	    {								   \
+	      __ptr = (TYPE *) __va_overflow (AP);			   \
+	      __va_overflow (AP) = (char *)(__ptr + 1);			   \
+	    }								   \
+	}								   \
+      else								   \
+	{								   \
+	  /* Everything else was promoted to int.  */			   \
+	  __va_arg_type_violation ();					   \
+	}								   \
+    }									   \
+  __ptr;								   \
+}))
+
+#define va_end(AP)	((void)0)
+
+/* Copy __gnuc_va_list into another variable of this type.  */
+#define __va_copy(dest, src) *(dest) = *(src)
+
+#endif /* __VA_PPC_H__ */
+#endif /* defined (_STDARG_H) || defined (_VARARGS_H) */
+
+
+#else
+/* Windows NT */
+/* Define __gnuc_va_list.  */
+
+#ifndef __GNUC_VA_LIST
+#define __GNUC_VA_LIST
+typedef char *__gnuc_va_list;
+#endif /* not __GNUC_VA_LIST */
+
+/* If this is for internal libc use, don't define anything but
+   __gnuc_va_list.  */
+#if defined (_STDARG_H) || defined (_VARARGS_H)
+
+#define __va_start_common(AP, LASTARG, FAKE)				\
+  ((__builtin_saveregs ()), ((AP) = ((char *) &LASTARG) + __va_rounded_size (AP)), 0)
+
+#ifdef _STDARG_H /* stdarg.h support */
+
+/* Calling __builtin_next_arg gives the proper error message if LASTARG is
+   not indeed the last argument.  */
+#define va_start(AP,LASTARG)						\
+  (__builtin_saveregs (),						\
+   (AP) = __builtin_next_arg (LASTARG),					\
+   0)
+
+#else /* varargs.h support */
+
+#define va_start(AP)							\
+  (__builtin_saveregs (),						\
+   (AP) = __builtin_next_arg (__va_1st_arg) - sizeof (int),		\
+   0)
+
+#define va_alist __va_1st_arg
+#define va_dcl register int __va_1st_arg; ...
+
+#endif /* _STDARG_H */
+
+#define __va_rounded_size(TYPE) ((sizeof (TYPE) + 3) & ~3)
+#define __va_align(AP, TYPE)						\
+     ((((unsigned long)(AP)) + ((sizeof (TYPE) >= 8) ? 7 : 3))		\
+      & ~((sizeof (TYPE) >= 8) ? 7 : 3))
+
+#define va_arg(AP,TYPE)							\
+( *(TYPE *)((AP = (char *) (__va_align(AP, TYPE)			\
+			    + __va_rounded_size(TYPE)))			\
+	    - __va_rounded_size(TYPE)))
+
+#define va_end(AP)	((void)0)
+
+/* Copy __gnuc_va_list into another variable of this type.  */
+#define __va_copy(dest, src) (dest) = (src)
+
+#endif /* defined (_STDARG_H) || defined (_VARARGS_H) */
+#endif /* Windows NT */

usr/local/nachos/lib/gcc-lib/decstation-ultrix/2.95.2/include/va-pyr.h

@@ -0,0 +1,130 @@
+/**
+ *
+ * 	Varargs for PYR/GNU CC
+ *
+ * WARNING -- WARNING -- DANGER
+ *
+ * The code in this file implements varargs for gcc on a pyr in
+ * a way that is compatible with code compiled by the Pyramid Technology
+ * C compiler.
+ * As such, it depends strongly on the Pyramid conventions for
+ * parameter passing.ct and independent implementation. 
+ * These (somewhat bizarre) parameter-passing conventions are described
+ * in the ``OSx Operating System Porting Guide''.
+ * 
+ * A quick summary is useful:
+ * 12 of the 48 register-windowed regs available for
+ * parameter passing.  Parameters of a function call that are eligible
+ * to be passed in registers are assigned registers from TR0/PR0 onwards;
+ * all other arguments are passed on the stack.
+ * Structure and union parameters are *never* passed in registers,
+ * even if they are small enough to fit.  They are always passed on
+ * the stack.
+ *
+ * Double-sized parameters cannot be passed in TR11, because
+ * TR12 is not used for passing parameters.  If, in the absence of this
+ * rule, a double-sized param would have been passed in TR11,
+ * that parameter is passed on the stack and no parameters are
+ * passed in TR11.
+ * 
+ * It is only known to work for passing 32-bit integer quantities
+ * (ie chars, shorts, ints/enums, longs), doubles, or pointers. 
+ * Passing structures on a Pyramid via varargs is a loser.
+ * Passing an object larger than 8 bytes on a pyramid via varargs may
+ * also be a loser.
+ * 
+ */
+
+
+/*
+ *  pointer to next stack parameter in __va_buf[0]
+ *  pointer to next parameter register in __va_buf[1]
+ *  Count of registers seen at __va_buf[2]
+ *  saved pr0..pr11 in __va_buf[3..14]
+ *  # of calls to va_arg (debugging) at __va_buf[15]
+ */
+
+/* Define __gnuc_va_list.  */
+
+#ifndef __GNUC_VA_LIST
+#define __GNUC_VA_LIST
+
+typedef void *__voidptr;
+#if 1
+
+typedef struct __va_regs {
+      __voidptr __stackp,__regp,__count;
+      __voidptr __pr0,__pr1,__pr2,__pr3,__pr4,__pr5,__pr6,__pr7,__pr8,__pr9,__pr10,__pr11;
+  } __va_regs;
+
+typedef __va_regs __va_buf;
+#else
+
+/* __va_buf[0] = address of next arg passed on the stack
+   __va_buf[1] = address of next arg passed in a register
+   __va_buf[2] = register-# of next arg passed in a register
+ */
+typedef __voidptr(*__va_buf);
+
+#endif
+
+typedef __va_buf __gnuc_va_list;
+
+#endif /* not __GNUC_VA_LIST */
+
+/* If this is for internal libc use, don't define anything but
+   __gnuc_va_list.  */
+#if defined (_STDARG_H) || defined (_VARARGS_H)
+
+/* In GCC version 2, we want an ellipsis at the end of the declaration
+   of the argument list.  GCC version 1 can't parse it.  */
+
+#if __GNUC__ > 1
+#define __va_ellipsis ...
+#else
+#define __va_ellipsis
+#endif
+
+#define va_alist \
+  __va0,__va1,__va2,__va3,__va4,__va5,__va6,__va7,__va8,__va9,__va10,__va11, \
+ __builtin_va_alist
+
+/* The ... causes current_function_varargs to be set in cc1.  */
+#define va_dcl __voidptr va_alist; __va_ellipsis
+
+
+/* __asm ("rcsp %0" : "=r" ( _AP [0]));*/
+
+#define va_start(_AP)  \
+  _AP =  ((struct __va_regs) {						\
+   &(_AP.__pr0), (void*)&__builtin_va_alist, (void*)0,			\
+        __va0,__va1,__va2,__va3,__va4,__va5,				\
+	__va6,__va7,__va8,__va9,__va10,__va11})
+
+
+/* Avoid errors if compiling GCC v2 with GCC v1.  */
+#if __GNUC__ == 1
+#define __extension__
+#endif
+
+/* We cast to void * and then to TYPE * because this avoids
+   a warning about increasing the alignment requirement.  */
+#define va_arg(_AP, _MODE)	\
+__extension__								\
+(*({__voidptr *__ap = (__voidptr*)&_AP;					\
+  register int __size = sizeof (_MODE);					\
+  register int __onstack =						\
+	  (__size > 8 || ( (int)(__ap[2]) > 11) ||			\
+	    (__size==8 && (int)(__ap[2])==11));				\
+  register int* __param_addr =  ((int*)((__ap) [__onstack]));		\
+									\
+  ((void *)__ap[__onstack])+=__size;					\
+    if (__onstack==0 || (int)(__ap[2])==11)				\
+      __ap[2]+= (__size >> 2);						\
+  (( _MODE *) (void *) __param_addr);					\
+}))
+
+void va_end (__gnuc_va_list);		/* Defined in libgcc.a */
+#define va_end(_X)	((void)0)
+
+#endif /* defined (_STDARG_H) || defined (_VARARGS_H) */

usr/local/nachos/lib/gcc-lib/decstation-ultrix/2.95.2/include/va-sh.h

@@ -0,0 +1,229 @@
+/* The ! __SH3E_VARG case is similar to the default gvarargs.h .  */
+
+#if (defined (__SH3E__) || defined (__SH4_SINGLE__) || defined (__SH4__) || defined (__SH4_SINGLE_ONLY__)) && ! defined (__HITACHI__)
+#define __SH3E_VARG
+#endif
+
+/* Define __gnuc_va_list.  */
+
+#ifndef __GNUC_VA_LIST
+#define __GNUC_VA_LIST
+
+#ifdef __SH3E_VARG
+
+typedef long __va_greg;
+typedef float __va_freg;
+
+typedef struct {
+  __va_greg * __va_next_o;		/* next available register */
+  __va_greg * __va_next_o_limit;	/* past last available register */
+  __va_freg * __va_next_fp;		/* next available fp register */
+  __va_freg * __va_next_fp_limit;	/* last available fp register */
+  __va_greg * __va_next_stack;		/* next extended word on stack */
+} __gnuc_va_list;
+
+#else /* ! SH3E */
+
+typedef void *__gnuc_va_list;
+
+#endif /* ! SH3E */
+
+#endif /* __GNUC_VA_LIST */
+
+/* If this is for internal libc use, don't define anything but
+   __gnuc_va_list.  */
+#if defined (_STDARG_H) || defined (_VARARGS_H)
+
+#ifdef _STDARG_H
+
+#ifdef __SH3E_VARG
+
+#define va_start(AP, LASTARG) \
+__extension__ \
+  ({ \
+     (AP).__va_next_fp = (__va_freg *) __builtin_saveregs (); \
+     (AP).__va_next_fp_limit = ((AP).__va_next_fp + \
+			      (__builtin_args_info (1) < 8 ? 8 - __builtin_args_info (1) : 0)); \
+     (AP).__va_next_o = (__va_greg *) (AP).__va_next_fp_limit; \
+     (AP).__va_next_o_limit = ((AP).__va_next_o + \
+			     (__builtin_args_info (0) < 4 ? 4 - __builtin_args_info (0) : 0)); \
+     (AP).__va_next_stack = (__va_greg *) __builtin_next_arg (LASTARG); \
+  })
+
+#else /* ! SH3E */
+
+#define va_start(AP, LASTARG) 						\
+ ((AP) = ((__gnuc_va_list) __builtin_next_arg (LASTARG)))
+
+#endif /* ! SH3E */
+
+#else /* _VARARGS_H */
+
+#define va_alist  __builtin_va_alist
+#define va_dcl    int __builtin_va_alist;...
+
+#ifdef __SH3E_VARG
+
+#define va_start(AP) \
+__extension__ \
+  ({ \
+     (AP).__va_next_fp = (__va_freg *) __builtin_saveregs (); \
+     (AP).__va_next_fp_limit = ((AP).__va_next_fp + \
+			      (__builtin_args_info (1) < 8 ? 8 - __builtin_args_info (1) : 0)); \
+     (AP).__va_next_o = (__va_greg *) (AP).__va_next_fp_limit; \
+     (AP).__va_next_o_limit = ((AP).__va_next_o + \
+			     (__builtin_args_info (0) < 4 ? 4 - __builtin_args_info (0) : 0)); \
+     (AP).__va_next_stack \
+       = ((__va_greg *) __builtin_next_arg (__builtin_va_alist) \
+	  - (__builtin_args_info (0) >= 4 || __builtin_args_info (1) >= 8 \
+	     ? 1 : 0)); \
+  })
+
+#else /* ! SH3E */
+
+#define va_start(AP)  ((AP) = (char *) &__builtin_va_alist)
+
+#endif /* ! SH3E */
+
+#endif /* _STDARG */
+
+#ifndef va_end
+void va_end (__gnuc_va_list);		/* Defined in libgcc.a */
+
+/* Values returned by __builtin_classify_type.  */
+
+enum __va_type_classes {
+  __no_type_class = -1,
+  __void_type_class,
+  __integer_type_class,
+  __char_type_class,
+  __enumeral_type_class,
+  __boolean_type_class,
+  __pointer_type_class,
+  __reference_type_class,
+  __offset_type_class,
+  __real_type_class,
+  __complex_type_class,
+  __function_type_class,
+  __method_type_class,
+  __record_type_class,
+  __union_type_class,
+  __array_type_class,
+  __string_type_class,
+  __set_type_class,
+  __file_type_class,
+  __lang_type_class
+};
+
+#endif
+#define va_end(pvar)	((void)0)
+
+#ifdef __LITTLE_ENDIAN__
+#define __LITTLE_ENDIAN_P 1
+#else
+#define __LITTLE_ENDIAN_P 0
+#endif
+
+#define __SCALAR_TYPE(TYPE)					\
+  ((TYPE) == __integer_type_class				\
+   || (TYPE) == __char_type_class				\
+   || (TYPE) == __enumeral_type_class)
+
+/* RECORD_TYPE args passed using the C calling convention are
+   passed by invisible reference.  ??? RECORD_TYPE args passed
+   in the stack are made to be word-aligned; for an aggregate that is
+   not word-aligned, we advance the pointer to the first non-reg slot.  */
+
+  /* When this is a smaller-than-int integer, using
+     auto-increment in the promoted (SImode) is fastest;
+     however, there is no way to express that is C.  Therefore,
+     we use an asm.
+     We want the MEM_IN_STRUCT_P bit set in the emitted RTL, therefore we
+     use unions even when it would otherwise be unnecessary.  */
+
+/* gcc has an extension that allows to use a casted lvalue as an lvalue,
+   But it doesn't work in C++ with -pedantic - even in the presence of
+   __extension__ .  We work around this problem by using a reference type.  */
+#ifdef __cplusplus
+#define __VA_REF &
+#else
+#define __VA_REF
+#endif
+
+#define __va_arg_sh1(AP, TYPE) __extension__ 				\
+({(sizeof (TYPE) == 1							\
+   ? ({union {TYPE t; char c;} __t;					\
+       __asm(""								\
+	     : "=r" (__t.c)						\
+	     : "0" ((((union { int i, j; } *__VA_REF) (AP))++)->i));	\
+       __t.t;})								\
+   : sizeof (TYPE) == 2							\
+   ? ({union {TYPE t; short s;} __t;					\
+       __asm(""								\
+	     : "=r" (__t.s)						\
+	     : "0" ((((union { int i, j; } *__VA_REF) (AP))++)->i));	\
+       __t.t;})								\
+   : sizeof (TYPE) >= 4 || __LITTLE_ENDIAN_P				\
+   ? (((union { TYPE t; int i;} *__VA_REF) (AP))++)->t			\
+   : ((union {TYPE t;TYPE u;}*) ((char *)++(int *__VA_REF)(AP) - sizeof (TYPE)))->t);})
+
+#ifdef __SH3E_VARG
+
+#define __PASS_AS_FLOAT(TYPE_CLASS,SIZE) \
+  (TYPE_CLASS == __real_type_class && SIZE == 4)
+
+#define __TARGET_SH4_P 0
+
+#if defined(__SH4__) || defined(__SH4_SINGLE__)
+#undef __PASS_AS_FLOAT
+#define __PASS_AS_FLOAT(TYPE_CLASS,SIZE) \
+  (TYPE_CLASS == __real_type_class && SIZE <= 8 \
+   || TYPE_CLASS == __complex_type_class && SIZE <= 16)
+#undef __TARGET_SH4_P
+#define __TARGET_SH4_P 1
+#endif
+
+#define va_arg(pvar,TYPE)					\
+__extension__							\
+({int __type = __builtin_classify_type (* (TYPE *) 0);		\
+  void * __result_p;						\
+  if (__PASS_AS_FLOAT (__type, sizeof(TYPE)))			\
+    {								\
+      if ((pvar).__va_next_fp < (pvar).__va_next_fp_limit)	\
+	{							\
+	  if (((__type == __real_type_class && sizeof (TYPE) > 4)\
+	       || sizeof (TYPE) > 8)				\
+	      && (((int) (pvar).__va_next_fp ^ (int) (pvar).__va_next_fp_limit)\
+		  & 4))						\
+	    (pvar).__va_next_fp++;				\
+	  __result_p = &(pvar).__va_next_fp;			\
+	}							\
+      else							\
+	__result_p = &(pvar).__va_next_stack;			\
+    }								\
+  else								\
+    {								\
+      if ((pvar).__va_next_o + ((sizeof (TYPE) + 3) / 4)	\
+	  <= (pvar).__va_next_o_limit) 				\
+	__result_p = &(pvar).__va_next_o;			\
+      else							\
+	{							\
+	  if (sizeof (TYPE) > 4)				\
+	   if (! __TARGET_SH4_P)				\
+	    (pvar).__va_next_o = (pvar).__va_next_o_limit;	\
+								\
+	  __result_p = &(pvar).__va_next_stack;			\
+	}							\
+    } 								\
+  __va_arg_sh1(*(void **)__result_p, TYPE);})
+
+#else /* ! SH3E */
+
+#define va_arg(AP, TYPE) __va_arg_sh1((AP), TYPE)
+
+#endif /* SH3E */
+
+/* Copy __gnuc_va_list into another variable of this type.  */
+#define __va_copy(dest, src) ((dest) = (src))
+
+#endif /* defined (_STDARG_H) || defined (_VARARGS_H) */

usr/local/nachos/lib/gcc-lib/decstation-ultrix/2.95.2/include/va-sparc.h

@@ -0,0 +1,165 @@
+/* This is just like the default gvarargs.h
+   except for differences described below.  */
+
+/* Define __gnuc_va_list.  */
+
+#ifndef __GNUC_VA_LIST
+#define __GNUC_VA_LIST
+#if ! defined (__svr4__) && ! defined (__linux__) && ! defined (__arch64__)
+/* This has to be a char * to be compatible with Sun.
+   i.e., we have to pass a `va_list' to vsprintf.  */
+typedef char * __gnuc_va_list;
+#else
+/* This has to be a void * to be compatible with Sun svr4.
+   i.e., we have to pass a `va_list' to vsprintf.  */
+typedef void * __gnuc_va_list;
+#endif
+#endif /* not __GNUC_VA_LIST */
+
+/* If this is for internal libc use, don't define anything but
+   __gnuc_va_list.  */
+#if defined (_STDARG_H) || defined (_VARARGS_H)
+
+#ifdef _STDARG_H
+
+/* Call __builtin_next_arg even though we aren't using its value, so that
+   we can verify that LASTARG is correct.  */
+#if defined (__GCC_NEW_VARARGS__) || defined (__arch64__)
+#define va_start(AP, LASTARG) \
+  (__builtin_next_arg (LASTARG), AP = (char *) __builtin_saveregs ())
+#else
+#define va_start(AP, LASTARG)					\
+  (__builtin_saveregs (), AP = ((char *) __builtin_next_arg (LASTARG)))
+#endif
+
+#else
+
+#define va_alist  __builtin_va_alist
+#define va_dcl    int __builtin_va_alist;...
+
+#if defined (__GCC_NEW_VARARGS__) || defined (__arch64__)
+#define va_start(AP)	((AP) = (char *) __builtin_saveregs ())
+#else
+#define va_start(AP) \
+  (__builtin_saveregs (), (AP) = ((char *) &__builtin_va_alist))
+#endif
+
+#endif
+
+#ifndef va_end
+void va_end (__gnuc_va_list);		/* Defined in libgcc.a */
+
+/* Values returned by __builtin_classify_type.  */
+
+enum __va_type_classes {
+  __no_type_class = -1,
+  __void_type_class,
+  __integer_type_class,
+  __char_type_class,
+  __enumeral_type_class,
+  __boolean_type_class,
+  __pointer_type_class,
+  __reference_type_class,
+  __offset_type_class,
+  __real_type_class,
+  __complex_type_class,
+  __function_type_class,
+  __method_type_class,
+  __record_type_class,
+  __union_type_class,
+  __array_type_class,
+  __string_type_class,
+  __set_type_class,
+  __file_type_class,
+  __lang_type_class
+};
+
+#endif
+#define va_end(pvar)	((void)0)
+
+/* Avoid errors if compiling GCC v2 with GCC v1.  */
+#if __GNUC__ == 1
+#define __extension__
+#endif
+
+/* RECORD_TYPE args passed using the C calling convention are
+   passed by invisible reference.  ??? RECORD_TYPE args passed
+   in the stack are made to be word-aligned; for an aggregate that is
+   not word-aligned, we advance the pointer to the first non-reg slot.  */
+
+#ifdef __arch64__
+
+typedef unsigned int __ptrint __attribute__ ((__mode__ (__DI__)));
+
+/* ??? TODO: little endian support */
+
+#define va_arg(pvar, TYPE) \
+__extension__							\
+(*({int __type = __builtin_classify_type (* (TYPE *) 0);	\
+  char * __result;						\
+  if (__type == __real_type_class)		/* float? */	\
+    {								\
+      if (__alignof__ (TYPE) == 16)				\
+	(pvar) = (void *) (((__ptrint) (pvar) + 15) & -16);	\
+      __result = (pvar);					\
+      (pvar) = (char *) (pvar) + sizeof (TYPE);			\
+    }								\
+  else if (__type < __record_type_class)	/* integer? */	\
+    {								\
+      (pvar) = (char *) (pvar) + 8;				\
+      __result = (char *) (pvar) - sizeof (TYPE);		\
+    }								\
+  else /* aggregate object */					\
+    {								\
+      if (sizeof (TYPE) <= 8)					\
+	{							\
+	  __result = (pvar);					\
+	  (pvar) = (char *) (pvar) + 8;				\
+	}							\
+      else if (sizeof (TYPE) <= 16)				\
+	{							\
+	  if (__alignof__ (TYPE) == 16)				\
+	    (pvar) = (void *) (((__ptrint) (pvar) + 15) & -16);	\
+	  __result = (pvar);					\
+	  (pvar) = (char *) (pvar) + 16;			\
+	}							\
+      else							\
+	{							\
+	  __result = * (void **) (pvar);			\
+	  (pvar) = (char *) (pvar) + 8;				\
+	}							\
+    }								\
+  (TYPE *) __result;}))
+
+#else /* not __arch64__ */
+
+#define __va_rounded_size(TYPE)  \
+  (((sizeof (TYPE) + sizeof (int) - 1) / sizeof (int)) * sizeof (int))
+
+/* We don't declare the union member `d' to have type TYPE
+   because that would lose in C++ if TYPE has a constructor.  */
+/* We cast to void * and then to TYPE * because this avoids
+   a warning about increasing the alignment requirement.
+   The casts to char * avoid warnings about invalid pointer arithmetic.  */
+#define va_arg(pvar,TYPE)					\
+__extension__							\
+(*({((__builtin_classify_type (*(TYPE*) 0) >= __record_type_class \
+      || (__builtin_classify_type (*(TYPE*) 0) == __real_type_class \
+	  && sizeof (TYPE) == 16))				\
+    ? ((pvar) = (char *)(pvar) + __va_rounded_size (TYPE *),	\
+       *(TYPE **) (void *) ((char *)(pvar) - __va_rounded_size (TYPE *))) \
+    : __va_rounded_size (TYPE) == 8				\
+    ? ({ union {char __d[sizeof (TYPE)]; int __i[2];} __u;	\
+	 __u.__i[0] = ((int *) (void *) (pvar))[0];		\
+	 __u.__i[1] = ((int *) (void *) (pvar))[1];		\
+	 (pvar) = (char *)(pvar) + 8;				\
+	 (TYPE *) (void *) __u.__d; })				\
+    : ((pvar) = (char *)(pvar) + __va_rounded_size (TYPE),	\
+       ((TYPE *) (void *) ((char *)(pvar) - __va_rounded_size (TYPE)))));}))
+
+#endif /* not __arch64__ */
+
+/* Copy __gnuc_va_list into another variable of this type.  */
+#define __va_copy(dest, src) (dest) = (src)
+
+#endif /* defined (_STDARG_H) || defined (_VARARGS_H) */

usr/local/nachos/lib/gcc-lib/decstation-ultrix/2.95.2/include/va-spur.h

@@ -0,0 +1,64 @@
+/*  varargs.h for SPUR */
+
+/* NB.  This is NOT the definition needed for the new ANSI proposed
+   standard */
+ 
+
+struct __va_struct { char __regs[20]; };
+
+#define va_alist __va_regs, __va_stack
+
+/* In GCC version 2, we want an ellipsis at the end of the declaration
+   of the argument list.  GCC version 1 can't parse it.  */
+
+#if __GNUC__ > 1
+#define __va_ellipsis ...
+#else
+#define __va_ellipsis
+#endif
+
+/* The ... causes current_function_varargs to be set in cc1.  */
+#define va_dcl struct __va_struct __va_regs; int __va_stack; 
+
+typedef struct {
+    int __pnt;
+    char *__regs;
+    char *__stack;
+} va_list;
+
+#define va_start(pvar) \
+     ((pvar).__pnt = 0, (pvar).__regs = __va_regs.__regs, \
+      (pvar).__stack = (char *) &__va_stack)
+#define va_end(pvar)	((void)0)
+
+/* Avoid errors if compiling GCC v2 with GCC v1.  */
+#if __GNUC__ == 1
+#define __extension__
+#endif
+
+#define va_arg(pvar,type)  \
+__extension__ \
+    (*({  type *__va_result; \
+        if ((pvar).__pnt >= 20) { \
+           __va_result = ( (type *) ((pvar).__stack + (pvar).__pnt - 20)); \
+	   (pvar).__pnt += (sizeof(type) + 7) & ~7; \
+	} \
+	else if ((pvar).__pnt + sizeof(type) > 20) { \
+	   __va_result = (type *) (pvar).__stack; \
+	   (pvar).__pnt = 20 + ( (sizeof(type) + 7) & ~7); \
+	} \
+	else if (sizeof(type) == 8) { \
+	   union {double d; int i[2];} __u; \
+	   __u.i[0] = *(int *) ((pvar).__regs + (pvar).__pnt); \
+	   __u.i[1] = *(int *) ((pvar).__regs + (pvar).__pnt + 4); \
+	   __va_result = (type *) &__u; \
+	   (pvar).__pnt += 8; \
+	} \
+	else { \
+	   __va_result = (type *) ((pvar).__regs + (pvar).__pnt); \
+	   (pvar).__pnt += (sizeof(type) + 3) & ~3; \
+	} \
+	__va_result; }))
+
+/* Copy __gnuc_va_list into another variable of this type.  */
+#define __va_copy(dest, src) (dest) = (src)