Delete old versions of GCC.

Change-Id: I710f125d905290e1024cbd67f48299861790c66c

1 files changed, 0 insertions, 478 deletions

diff --git a/gcc-4.2.1-5666.3/gcc/doc/objc.texi b/gcc-4.2.1-5666.3/gcc/doc/objc.texi
deleted file mode 100644
index c15c1acf8..000000000
--- a/gcc-4.2.1-5666.3/gcc/doc/objc.texi
+++ /dev/null
@@ -1,478 +0,0 @@
-@c Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
-@c 1999, 2000, 2001, 2002, 2003, 2004, 2005 Free Software Foundation, Inc.
-@c This is part of the GCC manual.
-@c For copying conditions, see the file gcc.texi.
-
-@node Objective-C
-@comment  node-name,  next,  previous,  up
-
-@chapter GNU Objective-C runtime features
-
-This document is meant to describe some of the GNU Objective-C runtime
-features.  It is not intended to teach you Objective-C, there are several
-resources on the Internet that present the language.  Questions and
-comments about this document to Ovidiu Predescu
-@email{ovidiu@@cup.hp.com}.
-
-@menu
-* Executing code before main::
-* Type encoding::
-* Garbage Collection::
-* Constant string objects::
-* compatibility_alias::
-@end menu
-
-@node Executing code before main, Type encoding, Objective-C, Objective-C
-@section @code{+load}: Executing code before main
-
-The GNU Objective-C runtime provides a way that allows you to execute
-code before the execution of the program enters the @code{main}
-function.  The code is executed on a per-class and a per-category basis,
-through a special class method @code{+load}.
-
-This facility is very useful if you want to initialize global variables
-which can be accessed by the program directly, without sending a message
-to the class first.  The usual way to initialize global variables, in the
-@code{+initialize} method, might not be useful because
-@code{+initialize} is only called when the first message is sent to a
-class object, which in some cases could be too late.
-
-Suppose for example you have a @code{FileStream} class that declares
-@code{Stdin}, @code{Stdout} and @code{Stderr} as global variables, like
-below:
-
-@smallexample
-
-FileStream *Stdin = nil;
-FileStream *Stdout = nil;
-FileStream *Stderr = nil;
-
-@@implementation FileStream
-
-+ (void)initialize
-@{
-    Stdin = [[FileStream new] initWithFd:0];
-    Stdout = [[FileStream new] initWithFd:1];
-    Stderr = [[FileStream new] initWithFd:2];
-@}
-
-/* @r{Other methods here} */
-@@end
-
-@end smallexample
-
-In this example, the initialization of @code{Stdin}, @code{Stdout} and
-@code{Stderr} in @code{+initialize} occurs too late.  The programmer can
-send a message to one of these objects before the variables are actually
-initialized, thus sending messages to the @code{nil} object.  The
-@code{+initialize} method which actually initializes the global
-variables is not invoked until the first message is sent to the class
-object.  The solution would require these variables to be initialized
-just before entering @code{main}.
-
-The correct solution of the above problem is to use the @code{+load}
-method instead of @code{+initialize}:
-
-@smallexample
-
-@@implementation FileStream
-
-+ (void)load
-@{
-    Stdin = [[FileStream new] initWithFd:0];
-    Stdout = [[FileStream new] initWithFd:1];
-    Stderr = [[FileStream new] initWithFd:2];
-@}
-
-/* @r{Other methods here} */
-@@end
-
-@end smallexample
-
-The @code{+load} is a method that is not overridden by categories.  If a
-class and a category of it both implement @code{+load}, both methods are
-invoked.  This allows some additional initializations to be performed in
-a category.
-
-This mechanism is not intended to be a replacement for @code{+initialize}.
-You should be aware of its limitations when you decide to use it
-instead of @code{+initialize}.
-
-@menu
-* What you can and what you cannot do in +load::
-@end menu
-
-
-@node What you can and what you cannot do in +load,  , Executing code before main, Executing code before main
-@subsection What you can and what you cannot do in @code{+load}
-
-The @code{+load} implementation in the GNU runtime guarantees you the following
-things:
-
-@itemize @bullet
-
-@item
-you can write whatever C code you like;
-
-@item
-you can send messages to Objective-C constant strings (@code{@@"this is a
-constant string"});
-
-@item
-you can allocate and send messages to objects whose class is implemented
-in the same file;
-
-@item
-the @code{+load} implementation of all super classes of a class are executed before the @code{+load} of that class is executed;
-
-@item
-the @code{+load} implementation of a class is executed before the
-@code{+load} implementation of any category.
-
-@end itemize
-
-In particular, the following things, even if they can work in a
-particular case, are not guaranteed:
-
-@itemize @bullet
-
-@item
-allocation of or sending messages to arbitrary objects;
-
-@item
-allocation of or sending messages to objects whose classes have a
-category implemented in the same file;
-
-@end itemize
-
-You should make no assumptions about receiving @code{+load} in sibling
-classes when you write @code{+load} of a class.  The order in which
-sibling classes receive @code{+load} is not guaranteed.
-
-The order in which @code{+load} and @code{+initialize} are called could
-be problematic if this matters.  If you don't allocate objects inside
-@code{+load}, it is guaranteed that @code{+load} is called before
-@code{+initialize}.  If you create an object inside @code{+load} the
-@code{+initialize} method of object's class is invoked even if
-@code{+load} was not invoked.  Note if you explicitly call @code{+load}
-on a class, @code{+initialize} will be called first.  To avoid possible
-problems try to implement only one of these methods.
-
-The @code{+load} method is also invoked when a bundle is dynamically
-loaded into your running program.  This happens automatically without any
-intervening operation from you.  When you write bundles and you need to
-write @code{+load} you can safely create and send messages to objects whose
-classes already exist in the running program.  The same restrictions as
-above apply to classes defined in bundle.
-
-
-
-@node Type encoding, Garbage Collection, Executing code before main, Objective-C
-@section Type encoding
-
-The Objective-C compiler generates type encodings for all the
-types.  These type encodings are used at runtime to find out information
-about selectors and methods and about objects and classes.
-
-The types are encoded in the following way:
-
-@c @sp 1
-
-@multitable @columnfractions .25 .75
-@item @code{_Bool}
-@tab @code{B}
-@item @code{char}
-@tab @code{c}
-@item @code{unsigned char}
-@tab @code{C}
-@item @code{short}
-@tab @code{s}
-@item @code{unsigned short}
-@tab @code{S}
-@item @code{int}
-@tab @code{i}
-@item @code{unsigned int}
-@tab @code{I}
-@item @code{long}
-@tab @code{l}
-@item @code{unsigned long}
-@tab @code{L}
-@item @code{long long}
-@tab @code{q}
-@item @code{unsigned long long}
-@tab @code{Q}
-@item @code{float}
-@tab @code{f}
-@item @code{double}
-@tab @code{d}
-@item @code{void}
-@tab @code{v}
-@item @code{id}
-@tab @code{@@}
-@item @code{Class}
-@tab @code{#}
-@item @code{SEL}
-@tab @code{:}
-@item @code{char*}
-@tab @code{*}
-@item unknown type
-@tab @code{?}
-@item Complex types
-@tab @code{j} followed by the inner type.  For example @code{_Complex double} is encoded as "jd".
-@item bit-fields
-@tab @code{b} followed by the starting position of the bit-field, the type of the bit-field and the size of the bit-field (the bit-fields encoding was changed from the NeXT's compiler encoding, see below)
-@end multitable
-
-@c @sp 1
-
-The encoding of bit-fields has changed to allow bit-fields to be properly
-handled by the runtime functions that compute sizes and alignments of
-types that contain bit-fields.  The previous encoding contained only the
-size of the bit-field.  Using only this information it is not possible to
-reliably compute the size occupied by the bit-field.  This is very
-important in the presence of the Boehm's garbage collector because the
-objects are allocated using the typed memory facility available in this
-collector.  The typed memory allocation requires information about where
-the pointers are located inside the object.
-
-The position in the bit-field is the position, counting in bits, of the
-bit closest to the beginning of the structure.
-
-The non-atomic types are encoded as follows:
-
-@c @sp 1
-
-@multitable @columnfractions .2 .8
-@item pointers
-@tab @samp{^} followed by the pointed type.
-@item arrays
-@tab @samp{[} followed by the number of elements in the array followed by the type of the elements followed by @samp{]}
-@item structures
-@tab @samp{@{} followed by the name of the structure (or @samp{?} if the structure is unnamed), the @samp{=} sign, the type of the members and by @samp{@}}
-@item unions
-@tab @samp{(} followed by the name of the structure (or @samp{?} if the union is unnamed), the @samp{=} sign, the type of the members followed by @samp{)}
-@end multitable
-
-Here are some types and their encodings, as they are generated by the
-compiler on an i386 machine:
-
-@sp 1
-
-@multitable @columnfractions .25 .75
-@item Objective-C type
-@tab Compiler encoding
-@item
-@smallexample
-int a[10];
-@end smallexample
-@tab @code{[10i]}
-@item
-@smallexample
-struct @{
-  int i;
-  float f[3];
-  int a:3;
-  int b:2;
-  char c;
-@}
-@end smallexample
-@tab @code{@{?=i[3f]b128i3b131i2c@}}
-@end multitable
-
-@sp 1
-
-In addition to the types the compiler also encodes the type
-specifiers.  The table below describes the encoding of the current
-Objective-C type specifiers:
-
-@sp 1
-
-@multitable @columnfractions .25 .75
-@item Specifier
-@tab Encoding
-@item @code{const}
-@tab @code{r}
-@item @code{in}
-@tab @code{n}
-@item @code{inout}
-@tab @code{N}
-@item @code{out}
-@tab @code{o}
-@item @code{bycopy}
-@tab @code{O}
-@item @code{oneway}
-@tab @code{V}
-@end multitable
-
-@sp 1
-
-The type specifiers are encoded just before the type.  Unlike types
-however, the type specifiers are only encoded when they appear in method
-argument types.
-
-
-@node Garbage Collection, Constant string objects, Type encoding, Objective-C
-@section Garbage Collection
-
-Support for a new memory management policy has been added by using a
-powerful conservative garbage collector, known as the
-Boehm-Demers-Weiser conservative garbage collector.  It is available from
-@w{@uref{http://www.hpl.hp.com/personal/Hans_Boehm/gc/}}.
-
-To enable the support for it you have to configure the compiler using an
-additional argument, @w{@option{--enable-objc-gc}}.  You need to have
-garbage collector installed before building the compiler.  This will
-build an additional runtime library which has several enhancements to
-support the garbage collector.  The new library has a new name,
-@file{libobjc_gc.a} to not conflict with the non-garbage-collected
-library.
-
-When the garbage collector is used, the objects are allocated using the
-so-called typed memory allocation mechanism available in the
-Boehm-Demers-Weiser collector.  This mode requires precise information on
-where pointers are located inside objects.  This information is computed
-once per class, immediately after the class has been initialized.
-
-There is a new runtime function @code{class_ivar_set_gcinvisible()}
-which can be used to declare a so-called @dfn{weak pointer}
-reference.  Such a pointer is basically hidden for the garbage collector;
-this can be useful in certain situations, especially when you want to
-keep track of the allocated objects, yet allow them to be
-collected.  This kind of pointers can only be members of objects, you
-cannot declare a global pointer as a weak reference.  Every type which is
-a pointer type can be declared a weak pointer, including @code{id},
-@code{Class} and @code{SEL}.
-
-Here is an example of how to use this feature.  Suppose you want to
-implement a class whose instances hold a weak pointer reference; the
-following class does this:
-
-@smallexample
-
-@@interface WeakPointer : Object
-@{
-    const void* weakPointer;
-@}
-
-- initWithPointer:(const void*)p;
-- (const void*)weakPointer;
-@@end
-
-
-@@implementation WeakPointer
-
-+ (void)initialize
-@{
-  class_ivar_set_gcinvisible (self, "weakPointer", YES);
-@}
-
-- initWithPointer:(const void*)p
-@{
-  weakPointer = p;
-  return self;
-@}
-
-- (const void*)weakPointer
-@{
-  return weakPointer;
-@}
-
-@@end
-
-@end smallexample
-
-Weak pointers are supported through a new type character specifier
-represented by the @samp{!} character.  The
-@code{class_ivar_set_gcinvisible()} function adds or removes this
-specifier to the string type description of the instance variable named
-as argument.
-
-@c =========================================================================
-@node Constant string objects
-@section Constant string objects
-
-GNU Objective-C provides constant string objects that are generated
-directly by the compiler.  You declare a constant string object by
-prefixing a C constant string with the character @samp{@@}:
-
-@smallexample
-  id myString = @@"this is a constant string object";
-@end smallexample
-
-The constant string objects are by default instances of the
-@code{NXConstantString} class which is provided by the GNU Objective-C
-runtime.  To get the definition of this class you must include the
-@file{objc/NXConstStr.h} header file.
-
-User defined libraries may want to implement their own constant string
-class.  To be able to support them, the GNU Objective-C compiler provides
-a new command line options @option{-fconstant-string-class=@var{class-name}}.
-The provided class should adhere to a strict structure, the same
-as @code{NXConstantString}'s structure:
-
-@smallexample
-
-@@interface MyConstantStringClass
-@{
-  Class isa;
-  char *c_string;
-  unsigned int len;
-@}
-@@end
-
-@end smallexample
-
-@code{NXConstantString} inherits from @code{Object}; user class
-libraries may choose to inherit the customized constant string class
-from a different class than @code{Object}.  There is no requirement in
-the methods the constant string class has to implement, but the final
-ivar layout of the class must be the compatible with the given
-structure.
-
-When the compiler creates the statically allocated constant string
-object, the @code{c_string} field will be filled by the compiler with
-the string; the @code{length} field will be filled by the compiler with
-the string length; the @code{isa} pointer will be filled with
-@code{NULL} by the compiler, and it will later be fixed up automatically
-at runtime by the GNU Objective-C runtime library to point to the class
-which was set by the @option{-fconstant-string-class} option when the
-object file is loaded (if you wonder how it works behind the scenes, the
-name of the class to use, and the list of static objects to fixup, are
-stored by the compiler in the object file in a place where the GNU
-runtime library will find them at runtime).
-
-As a result, when a file is compiled with the
-@option{-fconstant-string-class} option, all the constant string objects
-will be instances of the class specified as argument to this option.  It
-is possible to have multiple compilation units referring to different
-constant string classes, neither the compiler nor the linker impose any
-restrictions in doing this.
-
-@c =========================================================================
-@node compatibility_alias
-@section compatibility_alias
-
-This is a feature of the Objective-C compiler rather than of the
-runtime, anyway since it is documented nowhere and its existence was
-forgotten, we are documenting it here.
-
-The keyword @code{@@compatibility_alias} allows you to define a class name
-as equivalent to another class name.  For example:
-
-@smallexample
-@@compatibility_alias WOApplication GSWApplication;
-@end smallexample
-
-tells the compiler that each time it encounters @code{WOApplication} as
-a class name, it should replace it with @code{GSWApplication} (that is,
-@code{WOApplication} is just an alias for @code{GSWApplication}).
-
-There are some constraints on how this can be used---
-
-@itemize @bullet
-
-@item @code{WOApplication} (the alias) must not be an existing class;
-
-@item @code{GSWApplication} (the real class) must be an existing class.
-
-@end itemize