+10.9 Common Misunderstandings with GNU C++
+==========================================
+
+C++ is a complex language and an evolving one, and its standard
+definition (the ISO C++ standard) was only recently completed. As a
+result, your C++ compiler may occasionally surprise you, even when its
+behavior is correct. This section discusses some areas that frequently
+give rise to questions of this sort.
+
+* Menu:
+
+* Static Definitions:: Static member declarations are not definitions
+* Temporaries:: Temporaries may vanish before you expect
+* Copy Assignment:: Copy Assignment operators copy virtual bases twice
+
+\1f
+File: gcc.info, Node: Static Definitions, Next: Temporaries, Up: C++ Misunderstandings
+
+10.9.1 Declare _and_ Define Static Members
+------------------------------------------
+
+When a class has static data members, it is not enough to _declare_ the
+static member; you must also _define_ it. For example:
+
+ class Foo
+ {
+ ...
+ void method();
+ static int bar;
+ };
+
+ This declaration only establishes that the class `Foo' has an `int'
+named `Foo::bar', and a member function named `Foo::method'. But you
+still need to define _both_ `method' and `bar' elsewhere. According to
+the ISO standard, you must supply an initializer in one (and only one)
+source file, such as:
+
+ int Foo::bar = 0;
+
+ Other C++ compilers may not correctly implement the standard
+behavior. As a result, when you switch to `g++' from one of these
+compilers, you may discover that a program that appeared to work
+correctly in fact does not conform to the standard: `g++' reports as
+undefined symbols any static data members that lack definitions.
+
+\1f
+File: gcc.info, Node: Temporaries, Next: Copy Assignment, Prev: Static Definitions, Up: C++ Misunderstandings
+
+10.9.2 Temporaries May Vanish Before You Expect
+-----------------------------------------------
+
+It is dangerous to use pointers or references to _portions_ of a
+temporary object. The compiler may very well delete the object before
+you expect it to, leaving a pointer to garbage. The most common place
+where this problem crops up is in classes like string classes,
+especially ones that define a conversion function to type `char *' or
+`const char *'--which is one reason why the standard `string' class
+requires you to call the `c_str' member function. However, any class
+that returns a pointer to some internal structure is potentially
+subject to this problem.
+
+ For example, a program may use a function `strfunc' that returns
+`string' objects, and another function `charfunc' that operates on
+pointers to `char':
+
+ string strfunc ();
+ void charfunc (const char *);
+
+ void
+ f ()
+ {
+ const char *p = strfunc().c_str();
+ ...
+ charfunc (p);
+ ...
+ charfunc (p);
+ }
+
+In this situation, it may seem reasonable to save a pointer to the C
+string returned by the `c_str' member function and use that rather than
+call `c_str' repeatedly. However, the temporary string created by the
+call to `strfunc' is destroyed after `p' is initialized, at which point
+`p' is left pointing to freed memory.
+
+ Code like this may run successfully under some other compilers,
+particularly obsolete cfront-based compilers that delete temporaries
+along with normal local variables. However, the GNU C++ behavior is
+standard-conforming, so if your program depends on late destruction of
+temporaries it is not portable.
+
+ The safe way to write such code is to give the temporary a name,
+which forces it to remain until the end of the scope of the name. For
+example:
+
+ string& tmp = strfunc ();
+ charfunc (tmp.c_str ());
+
+\1f
+File: gcc.info, Node: Copy Assignment, Prev: Temporaries, Up: C++ Misunderstandings
+
+10.9.3 Implicit Copy-Assignment for Virtual Bases
+-------------------------------------------------
+
+When a base class is virtual, only one subobject of the base class
+belongs to each full object. Also, the constructors and destructors are
+invoked only once, and called from the most-derived class. However,
+such objects behave unspecified when being assigned. For example:
+
+ struct Base{
+ char *name;
+ Base(char *n) : name(strdup(n)){}
+ Base& operator= (const Base& other){
+ free (name);
+ name = strdup (other.name);
+ }
+ };
+
+ struct A:virtual Base{
+ int val;
+ A():Base("A"){}
+ };
+
+ struct B:virtual Base{
+ int bval;
+ B():Base("B"){}
+ };
+
+ struct Derived:public A, public B{
+ Derived():Base("Derived"){}
+ };
+
+ void func(Derived &d1, Derived &d2)
+ {
+ d1 = d2;
+ }
+
+ The C++ standard specifies that `Base::Base' is only called once
+when constructing or copy-constructing a Derived object. It is
+unspecified whether `Base::operator=' is called more than once when the
+implicit copy-assignment for Derived objects is invoked (as it is
+inside `func' in the example).
+
+ g++ implements the "intuitive" algorithm for copy-assignment: assign
+all direct bases, then assign all members. In that algorithm, the
+virtual base subobject can be encountered many times. In the example,
+copying proceeds in the following order: `val', `name' (via `strdup'),
+`bval', and `name' again.
+
+ If application code relies on copy-assignment, a user-defined
+copy-assignment operator removes any uncertainties. With such an
+operator, the application can define whether and how the virtual base
+subobject is assigned.
+
+\1f
+File: gcc.info, Node: Protoize Caveats, Next: Non-bugs, Prev: C++ Misunderstandings, Up: Trouble
+
+10.10 Caveats of using `protoize'
+=================================
+
+The conversion programs `protoize' and `unprotoize' can sometimes
+change a source file in a way that won't work unless you rearrange it.
+
+ * `protoize' can insert references to a type name or type tag before
+ the definition, or in a file where they are not defined.
+
+ If this happens, compiler error messages should show you where the
+ new references are, so fixing the file by hand is straightforward.
+
+ * There are some C constructs which `protoize' cannot figure out.
+ For example, it can't determine argument types for declaring a
+ pointer-to-function variable; this you must do by hand. `protoize'
+ inserts a comment containing `???' each time it finds such a
+ variable; so you can find all such variables by searching for this
+ string. ISO C does not require declaring the argument types of
+ pointer-to-function types.
+
+ * Using `unprotoize' can easily introduce bugs. If the program
+ relied on prototypes to bring about conversion of arguments, these
+ conversions will not take place in the program without prototypes.
+ One case in which you can be sure `unprotoize' is safe is when you
+ are removing prototypes that were made with `protoize'; if the
+ program worked before without any prototypes, it will work again
+ without them.
+
+ You can find all the places where this problem might occur by
+ compiling the program with the `-Wconversion' option. It prints a
+ warning whenever an argument is converted.
+
+ * Both conversion programs can be confused if there are macro calls
+ in and around the text to be converted. In other words, the
+ standard syntax for a declaration or definition must not result
+ from expanding a macro. This problem is inherent in the design of
+ C and cannot be fixed. If only a few functions have confusing
+ macro calls, you can easily convert them manually.
+
+ * `protoize' cannot get the argument types for a function whose
+ definition was not actually compiled due to preprocessing
+ conditionals. When this happens, `protoize' changes nothing in
+ regard to such a function. `protoize' tries to detect such
+ instances and warn about them.
+
+ You can generally work around this problem by using `protoize' step
+ by step, each time specifying a different set of `-D' options for
+ compilation, until all of the functions have been converted.
+ There is no automatic way to verify that you have got them all,
+ however.
+
+ * Confusion may result if there is an occasion to convert a function
+ declaration or definition in a region of source code where there
+ is more than one formal parameter list present. Thus, attempts to
+ convert code containing multiple (conditionally compiled) versions
+ of a single function header (in the same vicinity) may not produce
+ the desired (or expected) results.
+
+ If you plan on converting source files which contain such code, it
+ is recommended that you first make sure that each conditionally
+ compiled region of source code which contains an alternative
+ function header also contains at least one additional follower
+ token (past the final right parenthesis of the function header).
+ This should circumvent the problem.
+
+ * `unprotoize' can become confused when trying to convert a function
+ definition or declaration which contains a declaration for a
+ pointer-to-function formal argument which has the same name as the
+ function being defined or declared. We recommend you avoid such
+ choices of formal parameter names.
+
+ * You might also want to correct some of the indentation by hand and
+ break long lines. (The conversion programs don't write lines
+ longer than eighty characters in any case.)
+
+\1f
+File: gcc.info, Node: Non-bugs, Next: Warnings and Errors, Prev: Protoize Caveats, Up: Trouble
+
+10.11 Certain Changes We Don't Want to Make
+===========================================
+
+This section lists changes that people frequently request, but which we
+do not make because we think GCC is better without them.
+
+ * Checking the number and type of arguments to a function which has
+ an old-fashioned definition and no prototype.
+
+ Such a feature would work only occasionally--only for calls that
+ appear in the same file as the called function, following the
+ definition. The only way to check all calls reliably is to add a
+ prototype for the function. But adding a prototype eliminates the
+ motivation for this feature. So the feature is not worthwhile.
+
+ * Warning about using an expression whose type is signed as a shift
+ count.
+
+ Shift count operands are probably signed more often than unsigned.
+ Warning about this would cause far more annoyance than good.
+
+ * Warning about assigning a signed value to an unsigned variable.
+
+ Such assignments must be very common; warning about them would
+ cause more annoyance than good.
+
+ * Warning when a non-void function value is ignored.
+
+ Coming as I do from a Lisp background, I balk at the idea that
+ there is something dangerous about discarding a value. There are
+ functions that return values which some callers may find useful;
+ it makes no sense to clutter the program with a cast to `void'
+ whenever the value isn't useful.
+
+ * Making `-fshort-enums' the default.
+
+ This would cause storage layout to be incompatible with most other
+ C compilers. And it doesn't seem very important, given that you
+ can get the same result in other ways. The case where it matters
+ most is when the enumeration-valued object is inside a structure,
+ and in that case you can specify a field width explicitly.
+
+ * Making bit-fields unsigned by default on particular machines where
+ "the ABI standard" says to do so.
+
+ The ISO C standard leaves it up to the implementation whether a
+ bit-field declared plain `int' is signed or not. This in effect
+ creates two alternative dialects of C.
+
+ The GNU C compiler supports both dialects; you can specify the
+ signed dialect with `-fsigned-bitfields' and the unsigned dialect
+ with `-funsigned-bitfields'. However, this leaves open the
+ question of which dialect to use by default.
+
+ Currently, the preferred dialect makes plain bit-fields signed,
+ because this is simplest. Since `int' is the same as `signed int'
+ in every other context, it is cleanest for them to be the same in
+ bit-fields as well.
+
+ Some computer manufacturers have published Application Binary
+ Interface standards which specify that plain bit-fields should be
+ unsigned. It is a mistake, however, to say anything about this
+ issue in an ABI. This is because the handling of plain bit-fields
+ distinguishes two dialects of C. Both dialects are meaningful on
+ every type of machine. Whether a particular object file was
+ compiled using signed bit-fields or unsigned is of no concern to
+ other object files, even if they access the same bit-fields in the
+ same data structures.
+
+ A given program is written in one or the other of these two
+ dialects. The program stands a chance to work on most any machine
+ if it is compiled with the proper dialect. It is unlikely to work
+ at all if compiled with the wrong dialect.
+
+ Many users appreciate the GNU C compiler because it provides an
+ environment that is uniform across machines. These users would be
+ inconvenienced if the compiler treated plain bit-fields
+ differently on certain machines.
+
+ Occasionally users write programs intended only for a particular
+ machine type. On these occasions, the users would benefit if the
+ GNU C compiler were to support by default the same dialect as the
+ other compilers on that machine. But such applications are rare.
+ And users writing a program to run on more than one type of
+ machine cannot possibly benefit from this kind of compatibility.
+
+ This is why GCC does and will treat plain bit-fields in the same
+ fashion on all types of machines (by default).
+
+ There are some arguments for making bit-fields unsigned by default
+ on all machines. If, for example, this becomes a universal de
+ facto standard, it would make sense for GCC to go along with it.
+ This is something to be considered in the future.
+
+ (Of course, users strongly concerned about portability should
+ indicate explicitly in each bit-field whether it is signed or not.
+ In this way, they write programs which have the same meaning in
+ both C dialects.)
+
+ * Undefining `__STDC__' when `-ansi' is not used.
+
+ Currently, GCC defines `__STDC__' as long as you don't use
+ `-traditional'. This provides good results in practice.
+
+ Programmers normally use conditionals on `__STDC__' to ask whether
+ it is safe to use certain features of ISO C, such as function
+ prototypes or ISO token concatenation. Since plain `gcc' supports
+ all the features of ISO C, the correct answer to these questions is
+ "yes".
+
+ Some users try to use `__STDC__' to check for the availability of
+ certain library facilities. This is actually incorrect usage in
+ an ISO C program, because the ISO C standard says that a conforming
+ freestanding implementation should define `__STDC__' even though it
+ does not have the library facilities. `gcc -ansi -pedantic' is a
+ conforming freestanding implementation, and it is therefore
+ required to define `__STDC__', even though it does not come with
+ an ISO C library.
+
+ Sometimes people say that defining `__STDC__' in a compiler that
+ does not completely conform to the ISO C standard somehow violates
+ the standard. This is illogical. The standard is a standard for
+ compilers that claim to support ISO C, such as `gcc -ansi'--not
+ for other compilers such as plain `gcc'. Whatever the ISO C
+ standard says is relevant to the design of plain `gcc' without
+ `-ansi' only for pragmatic reasons, not as a requirement.
+
+ GCC normally defines `__STDC__' to be 1, and in addition defines
+ `__STRICT_ANSI__' if you specify the `-ansi' option, or a `-std'
+ option for strict conformance to some version of ISO C. On some
+ hosts, system include files use a different convention, where
+ `__STDC__' is normally 0, but is 1 if the user specifies strict
+ conformance to the C Standard. GCC follows the host convention
+ when processing system include files, but when processing user
+ files it follows the usual GNU C convention.
+
+ * Undefining `__STDC__' in C++.
+
+ Programs written to compile with C++-to-C translators get the
+ value of `__STDC__' that goes with the C compiler that is
+ subsequently used. These programs must test `__STDC__' to
+ determine what kind of C preprocessor that compiler uses: whether
+ they should concatenate tokens in the ISO C fashion or in the
+ traditional fashion.
+
+ These programs work properly with GNU C++ if `__STDC__' is defined.
+ They would not work otherwise.
+
+ In addition, many header files are written to provide prototypes
+ in ISO C but not in traditional C. Many of these header files can
+ work without change in C++ provided `__STDC__' is defined. If
+ `__STDC__' is not defined, they will all fail, and will all need
+ to be changed to test explicitly for C++ as well.
+
+ * Deleting "empty" loops.
+
+ Historically, GCC has not deleted "empty" loops under the
+ assumption that the most likely reason you would put one in a
+ program is to have a delay, so deleting them will not make real
+ programs run any faster.
+
+ However, the rationale here is that optimization of a nonempty loop
+ cannot produce an empty one, which holds for C but is not always
+ the case for C++.
+
+ Moreover, with `-funroll-loops' small "empty" loops are already
+ removed, so the current behavior is both sub-optimal and
+ inconsistent and will change in the future.
+
+ * Making side effects happen in the same order as in some other
+ compiler.
+
+ It is never safe to depend on the order of evaluation of side
+ effects. For example, a function call like this may very well
+ behave differently from one compiler to another:
+
+ void func (int, int);
+
+ int i = 2;
+ func (i++, i++);
+
+ There is no guarantee (in either the C or the C++ standard language
+ definitions) that the increments will be evaluated in any
+ particular order. Either increment might happen first. `func'
+ might get the arguments `2, 3', or it might get `3, 2', or even
+ `2, 2'.
+
+ * Not allowing structures with volatile fields in registers.
+
+ Strictly speaking, there is no prohibition in the ISO C standard
+ against allowing structures with volatile fields in registers, but
+ it does not seem to make any sense and is probably not what you
+ wanted to do. So the compiler will give an error message in this
+ case.
+
+ * Making certain warnings into errors by default.
+
+ Some ISO C testsuites report failure when the compiler does not
+ produce an error message for a certain program.
+
+ ISO C requires a "diagnostic" message for certain kinds of invalid
+ programs, but a warning is defined by GCC to count as a
+ diagnostic. If GCC produces a warning but not an error, that is
+ correct ISO C support. If test suites call this "failure", they
+ should be run with the GCC option `-pedantic-errors', which will
+ turn these warnings into errors.
+
+
+\1f
+File: gcc.info, Node: Warnings and Errors, Prev: Non-bugs, Up: Trouble
+
+10.12 Warning Messages and Error Messages
+=========================================
+
+The GNU compiler can produce two kinds of diagnostics: errors and
+warnings. Each kind has a different purpose:
+
+ "Errors" report problems that make it impossible to compile your
+ program. GCC reports errors with the source file name and line
+ number where the problem is apparent.
+
+ "Warnings" report other unusual conditions in your code that _may_
+ indicate a problem, although compilation can (and does) proceed.
+ Warning messages also report the source file name and line number,
+ but include the text `warning:' to distinguish them from error
+ messages.
+
+ Warnings may indicate danger points where you should check to make
+sure that your program really does what you intend; or the use of
+obsolete features; or the use of nonstandard features of GNU C or C++.
+Many warnings are issued only if you ask for them, with one of the `-W'
+options (for instance, `-Wall' requests a variety of useful warnings).
+
+ GCC always tries to compile your program if possible; it never
+gratuitously rejects a program whose meaning is clear merely because
+(for instance) it fails to conform to a standard. In some cases,
+however, the C and C++ standards specify that certain extensions are
+forbidden, and a diagnostic _must_ be issued by a conforming compiler.
+The `-pedantic' option tells GCC to issue warnings in such cases;
+`-pedantic-errors' says to make them errors instead. This does not
+mean that _all_ non-ISO constructs get warnings or errors.
+
+ *Note Options to Request or Suppress Warnings: Warning Options, for
+more detail on these and related command-line options.
+
+\1f
+File: gcc.info, Node: Bugs, Next: Service, Prev: Trouble, Up: Top
+
+11 Reporting Bugs
+*****************
+
+Your bug reports play an essential role in making GCC reliable.
+
+ When you encounter a problem, the first thing to do is to see if it
+is already known. *Note Trouble::. If it isn't known, then you should
+report the problem.
+
+ Reporting a bug may help you by bringing a solution to your problem,
+or it may not. (If it does not, look in the service directory; see
+*note Service::.) In any case, the principal function of a bug report
+is to help the entire community by making the next version of GCC work
+better. Bug reports are your contribution to the maintenance of GCC.
+
+ Since the maintainers are very overloaded, we cannot respond to every
+bug report. However, if the bug has not been fixed, we are likely to
+send you a patch and ask you to tell us whether it works.
+
+ In order for a bug report to serve its purpose, you must include the
+information that makes for fixing the bug.
+
+* Menu:
+
+* Criteria: Bug Criteria. Have you really found a bug?
+* Where: Bug Lists. Where to send your bug report.
+* Reporting: Bug Reporting. How to report a bug effectively.
+* GNATS: gccbug. You can use a bug reporting tool.
+* Known: Trouble. Known problems.
+* Help: Service. Where to ask for help.
+
+\1f
+File: gcc.info, Node: Bug Criteria, Next: Bug Lists, Up: Bugs
+
+11.1 Have You Found a Bug?
+==========================
+
+If you are not sure whether you have found a bug, here are some
+guidelines:
+
+ * If the compiler gets a fatal signal, for any input whatever, that
+ is a compiler bug. Reliable compilers never crash.
+
+ * If the compiler produces invalid assembly code, for any input
+ whatever (except an `asm' statement), that is a compiler bug,
+ unless the compiler reports errors (not just warnings) which would
+ ordinarily prevent the assembler from being run.
+
+ * If the compiler produces valid assembly code that does not
+ correctly execute the input source code, that is a compiler bug.
+
+ However, you must double-check to make sure, because you may have
+ run into an incompatibility between GNU C and traditional C (*note
+ Incompatibilities::). These incompatibilities might be considered
+ bugs, but they are inescapable consequences of valuable features.
+
+ Or you may have a program whose behavior is undefined, which
+ happened by chance to give the desired results with another C or
+ C++ compiler.
+
+ For example, in many nonoptimizing compilers, you can write `x;'
+ at the end of a function instead of `return x;', with the same
+ results. But the value of the function is undefined if `return'
+ is omitted; it is not a bug when GCC produces different results.
+
+ Problems often result from expressions with two increment
+ operators, as in `f (*p++, *p++)'. Your previous compiler might
+ have interpreted that expression the way you intended; GCC might
+ interpret it another way. Neither compiler is wrong. The bug is
+ in your code.
+
+ After you have localized the error to a single source line, it
+ should be easy to check for these things. If your program is
+ correct and well defined, you have found a compiler bug.
+
+ * If the compiler produces an error message for valid input, that is
+ a compiler bug.
+
+ * If the compiler does not produce an error message for invalid
+ input, that is a compiler bug. However, you should note that your
+ idea of "invalid input" might be my idea of "an extension" or
+ "support for traditional practice".
+
+ * If you are an experienced user of one of the languages GCC
+ supports, your suggestions for improvement of GCC are welcome in
+ any case.
+
+\1f
+File: gcc.info, Node: Bug Lists, Next: Bug Reporting, Prev: Bug Criteria, Up: Bugs
+
+11.2 Where to Report Bugs
+=========================
+
+Send bug reports for the GNU Compiler Collection to
+<gcc-bugs@gcc.gnu.org>. In accordance with the GNU-wide convention, in
+which bug reports for tool "foo" are sent to `bug-foo@gnu.org', the
+address <bug-gcc@gnu.org> may also be used; it will forward to the
+address given above.
+
+ Please read `http://gcc.gnu.org/bugs.html' for additional and/or
+more up-to-date bug reporting instructions before you post a bug report.
+
+\1f
+File: gcc.info, Node: Bug Reporting, Next: gccbug, Prev: Bug Lists, Up: Bugs
+
+11.3 How to Report Bugs
+=======================
+
+The fundamental principle of reporting bugs usefully is this: *report
+all the facts*. If you are not sure whether to state a fact or leave
+it out, state it!
+
+ Often people omit facts because they think they know what causes the
+problem and they conclude that some details don't matter. Thus, you
+might assume that the name of the variable you use in an example does
+not matter. Well, probably it doesn't, but one cannot be sure.
+Perhaps the bug is a stray memory reference which happens to fetch from
+the location where that name is stored in memory; perhaps, if the name
+were different, the contents of that location would fool the compiler
+into doing the right thing despite the bug. Play it safe and give a
+specific, complete example. That is the easiest thing for you to do,
+and the most helpful.
+
+ Keep in mind that the purpose of a bug report is to enable someone to
+fix the bug if it is not known. It isn't very important what happens if
+the bug is already known. Therefore, always write your bug reports on
+the assumption that the bug is not known.
+
+ Sometimes people give a few sketchy facts and ask, "Does this ring a
+bell?" This cannot help us fix a bug, so it is basically useless. We
+respond by asking for enough details to enable us to investigate. You
+might as well expedite matters by sending them to begin with.
+
+ Try to make your bug report self-contained. If we have to ask you
+for more information, it is best if you include all the previous
+information in your response, as well as the information that was
+missing.
+
+ Please report each bug in a separate message. This makes it easier
+for us to track which bugs have been fixed and to forward your bugs
+reports to the appropriate maintainer.
+
+ To enable someone to investigate the bug, you should include all
+these things:
+
+ * The version of GCC. You can get this by running it with the `-v'
+ option.
+
+ Without this, we won't know whether there is any point in looking
+ for the bug in the current version of GCC.
+
+ * A complete input file that will reproduce the bug. If the bug is
+ in the C preprocessor, send a source file and any header files
+ that it requires. If the bug is in the compiler proper (`cc1'),
+ send the preprocessor output generated by adding `-save-temps' to
+ the compilation command (*note Debugging Options::). When you do
+ this, use the same `-I', `-D' or `-U' options that you used in
+ actual compilation. Then send the INPUT.i or INPUT.ii files
+ generated.
+
+ A single statement is not enough of an example. In order to
+ compile it, it must be embedded in a complete file of compiler
+ input; and the bug might depend on the details of how this is done.
+
+ Without a real example one can compile, all anyone can do about
+ your bug report is wish you luck. It would be futile to try to
+ guess how to provoke the bug. For example, bugs in register
+ allocation and reloading frequently depend on every little detail
+ of the function they happen in.
+
+ Even if the input file that fails comes from a GNU program, you
+ should still send the complete test case. Don't ask the GCC
+ maintainers to do the extra work of obtaining the program in
+ question--they are all overworked as it is. Also, the problem may
+ depend on what is in the header files on your system; it is
+ unreliable for the GCC maintainers to try the problem with the
+ header files available to them. By sending CPP output, you can
+ eliminate this source of uncertainty and save us a certain
+ percentage of wild goose chases.
+
+ * The command arguments you gave GCC to compile that example and
+ observe the bug. For example, did you use `-O'? To guarantee you
+ won't omit something important, list all the options.
+
+ If we were to try to guess the arguments, we would probably guess
+ wrong and then we would not encounter the bug.
+
+ * The type of machine you are using, and the operating system name
+ and version number.
+
+ * The operands you gave to the `configure' command when you installed
+ the compiler.
+
+ * A complete list of any modifications you have made to the compiler
+ source. (We don't promise to investigate the bug unless it
+ happens in an unmodified compiler. But if you've made
+ modifications and don't tell us, then you are sending us on a wild
+ goose chase.)
+
+ Be precise about these changes. A description in English is not
+ enough--send a context diff for them.
+
+ Adding files of your own (such as a machine description for a
+ machine we don't support) is a modification of the compiler source.
+
+ * Details of any other deviations from the standard procedure for
+ installing GCC.
+
+ * A description of what behavior you observe that you believe is
+ incorrect. For example, "The compiler gets a fatal signal," or,
+ "The assembler instruction at line 208 in the output is incorrect."
+
+ Of course, if the bug is that the compiler gets a fatal signal,
+ then one can't miss it. But if the bug is incorrect output, the
+ maintainer might not notice unless it is glaringly wrong. None of
+ us has time to study all the assembler code from a 50-line C
+ program just on the chance that one instruction might be wrong.
+ We need _you_ to do this part!
+
+ Even if the problem you experience is a fatal signal, you should
+ still say so explicitly. Suppose something strange is going on,
+ such as, your copy of the compiler is out of synch, or you have
+ encountered a bug in the C library on your system. (This has
+ happened!) Your copy might crash and the copy here would not. If
+ you said to expect a crash, then when the compiler here fails to
+ crash, we would know that the bug was not happening. If you don't
+ say to expect a crash, then we would not know whether the bug was
+ happening. We would not be able to draw any conclusion from our
+ observations.
+
+ If the problem is a diagnostic when compiling GCC with some other
+ compiler, say whether it is a warning or an error.
+
+ Often the observed symptom is incorrect output when your program
+ is run. Sad to say, this is not enough information unless the
+ program is short and simple. None of us has time to study a large
+ program to figure out how it would work if compiled correctly,
+ much less which line of it was compiled wrong. So you will have
+ to do that. Tell us which source line it is, and what incorrect
+ result happens when that line is executed. A person who
+ understands the program can find this as easily as finding a bug
+ in the program itself.
+
+ * If you send examples of assembler code output from GCC, please use
+ `-g' when you make them. The debugging information includes
+ source line numbers which are essential for correlating the output
+ with the input.
+
+ * If you wish to mention something in the GCC source, refer to it by
+ context, not by line number.
+
+ The line numbers in the development sources don't match those in
+ your sources. Your line numbers would convey no useful
+ information to the maintainers.
+
+ * Additional information from a debugger might enable someone to
+ find a problem on a machine which he does not have available.
+ However, you need to think when you collect this information if
+ you want it to have any chance of being useful.
+
+ For example, many people send just a backtrace, but that is never
+ useful by itself. A simple backtrace with arguments conveys little
+ about GCC because the compiler is largely data-driven; the same
+ functions are called over and over for different RTL insns, doing
+ different things depending on the details of the insn.
+
+ Most of the arguments listed in the backtrace are useless because
+ they are pointers to RTL list structure. The numeric values of the
+ pointers, which the debugger prints in the backtrace, have no
+ significance whatever; all that matters is the contents of the
+ objects they point to (and most of the contents are other such
+ pointers).
+
+ In addition, most compiler passes consist of one or more loops that
+ scan the RTL insn sequence. The most vital piece of information
+ about such a loop--which insn it has reached--is usually in a
+ local variable, not in an argument.
+
+ What you need to provide in addition to a backtrace are the values
+ of the local variables for several stack frames up. When a local
+ variable or an argument is an RTX, first print its value and then
+ use the GDB command `pr' to print the RTL expression that it points
+ to. (If GDB doesn't run on your machine, use your debugger to call
+ the function `debug_rtx' with the RTX as an argument.) In
+ general, whenever a variable is a pointer, its value is no use
+ without the data it points to.
+
+ Here are some things that are not necessary:
+
+ * A description of the envelope of the bug.
+
+ Often people who encounter a bug spend a lot of time investigating
+ which changes to the input file will make the bug go away and which
+ changes will not affect it.
+
+ This is often time consuming and not very useful, because the way
+ we will find the bug is by running a single example under the
+ debugger with breakpoints, not by pure deduction from a series of
+ examples. You might as well save your time for something else.
+
+ Of course, if you can find a simpler example to report _instead_ of
+ the original one, that is a convenience. Errors in the output
+ will be easier to spot, running under the debugger will take less
+ time, etc. Most GCC bugs involve just one function, so the most
+ straightforward way to simplify an example is to delete all the
+ function definitions except the one where the bug occurs. Those
+ earlier in the file may be replaced by external declarations if
+ the crucial function depends on them. (Exception: inline
+ functions may affect compilation of functions defined later in the
+ file.)
+
+ However, simplification is not vital; if you don't want to do this,
+ report the bug anyway and send the entire test case you used.
+
+ * In particular, some people insert conditionals `#ifdef BUG' around
+ a statement which, if removed, makes the bug not happen. These
+ are just clutter; we won't pay any attention to them anyway.
+ Besides, you should send us cpp output, and that can't have
+ conditionals.
+
+ * A patch for the bug.
+
+ A patch for the bug is useful if it is a good one. But don't omit
+ the necessary information, such as the test case, on the
+ assumption that a patch is all we need. We might see problems
+ with your patch and decide to fix the problem another way, or we
+ might not understand it at all.
+
+ Sometimes with a program as complicated as GCC it is very hard to
+ construct an example that will make the program follow a certain
+ path through the code. If you don't send the example, we won't be
+ able to construct one, so we won't be able to verify that the bug
+ is fixed.
+
+ And if we can't understand what bug you are trying to fix, or why
+ your patch should be an improvement, we won't install it. A test
+ case will help us to understand.
+
+ See `http://gcc.gnu.org/contribute.html' for guidelines on how to
+ make it easy for us to understand and install your patches.
+
+ * A guess about what the bug is or what it depends on.
+
+ Such guesses are usually wrong. Even I can't guess right about
+ such things without first using the debugger to find the facts.
+
+ * A core dump file.
+
+ We have no way of examining a core dump for your type of machine
+ unless we have an identical system--and if we do have one, we
+ should be able to reproduce the crash ourselves.
+
+\1f
+File: gcc.info, Node: gccbug, Prev: Bug Reporting, Up: Bugs
+
+11.4 The gccbug script
+======================
+
+To simplify creation of bug reports, and to allow better tracking of
+reports, we use the GNATS bug tracking system. Part of that system is
+the `gccbug' script. This is a Unix shell script, so you need a shell
+to run it. It is normally installed in the same directory where `gcc'
+is installed.
+
+ The gccbug script is derived from send-pr, *note Creating new
+Problem Reports: (send-pr)using send-pr. When invoked, it starts a
+text editor so you can fill out the various fields of the report. When
+the you quit the editor, the report is automatically send to the bug
+reporting address.
+
+ A number of fields in this bug report form are specific to GCC, and
+are explained at `http://gcc.gnu.org/gnats.html'.
+
+\1f
+File: gcc.info, Node: Service, Next: Contributing, Prev: Bugs, Up: Top
+
+12 How To Get Help with GCC
+***************************
+
+If you need help installing, using or changing GCC, there are two ways
+to find it:
+
+ * Send a message to a suitable network mailing list. First try
+ <gcc-help@gcc.gnu.org> (for help installing or using GCC), and if
+ that brings no response, try <gcc@gcc.gnu.org>. For help changing
+ GCC, ask <gcc@gcc.gnu.org>. If you think you have found a bug in
+ GCC, please report it following the instructions at *note Bug
+ Reporting::.
+
+ * Look in the service directory for someone who might help you for a
+ fee. The service directory is found at
+ `http://www.gnu.org/prep/service.html'.
+
+\1f
+File: gcc.info, Node: Contributing, Next: VMS, Prev: Service, Up: Top
+
+13 Contributing to GCC Development
+**********************************
+
+If you would like to help pretest GCC releases to assure they work well,
+our current development sources are available by CVS (see
+`http://gcc.gnu.org/cvs.html'). Source and binary snapshots are also
+available for FTP; see `http://gcc.gnu.org/snapshots.html'.
+
+ If you would like to work on improvements to GCC, please read the
+advice at these URLs:
+
+ `http://gcc.gnu.org/contribute.html'
+ `http://gcc.gnu.org/contributewhy.html'
+
+for information on how to make useful contributions and avoid
+duplication of effort. Suggested projects are listed at
+`http://gcc.gnu.org/projects/'.
+
+\1f
+File: gcc.info, Node: VMS, Next: Funding, Prev: Contributing, Up: Top
+
+14 Using GCC on VMS
+*******************
+
+Here is how to use GCC on VMS.
+
+* Menu:
+
+* Include Files and VMS:: Where the preprocessor looks for the include files.
+* Global Declarations:: How to do globaldef, globalref and globalvalue with
+ GCC.
+* VMS Misc:: Misc information.
+
+\1f
+File: gcc.info, Node: Include Files and VMS, Next: Global Declarations, Up: VMS
+
+14.1 Include Files and VMS
+==========================
+
+Due to the differences between the filesystems of Unix and VMS, GCC
+attempts to translate file names in `#include' into names that VMS will
+understand. The basic strategy is to prepend a prefix to the
+specification of the include file, convert the whole filename to a VMS
+filename, and then try to open the file. GCC tries various prefixes
+one by one until one of them succeeds:
+
+ 1. The first prefix is the `GNU_CC_INCLUDE:' logical name: this is
+ where GNU C header files are traditionally stored. If you wish to
+ store header files in non-standard locations, then you can assign
+ the logical `GNU_CC_INCLUDE' to be a search list, where each
+ element of the list is suitable for use with a rooted logical.
+
+ 2. The next prefix tried is `SYS$SYSROOT:[SYSLIB.]'. This is where
+ VAX-C header files are traditionally stored.
+
+ 3. If the include file specification by itself is a valid VMS
+ filename, the preprocessor then uses this name with no prefix in
+ an attempt to open the include file.
+
+ 4. If the file specification is not a valid VMS filename (i.e. does
+ not contain a device or a directory specifier, and contains a `/'
+ character), the preprocessor tries to convert it from Unix syntax
+ to VMS syntax.
+
+ Conversion works like this: the first directory name becomes a
+ device, and the rest of the directories are converted into
+ VMS-format directory names. For example, the name `X11/foobar.h'
+ is translated to `X11:[000000]foobar.h' or `X11:foobar.h',
+ whichever one can be opened. This strategy allows you to assign a
+ logical name to point to the actual location of the header files.
+
+ 5. If none of these strategies succeeds, the `#include' fails.
+
+ Include directives of the form:
+
+ #include foobar
+
+are a common source of incompatibility between VAX-C and GCC. VAX-C
+treats this much like a standard `#include <foobar.h>' directive. That
+is incompatible with the ISO C behavior implemented by GCC: to expand
+the name `foobar' as a macro. Macro expansion should eventually yield
+one of the two standard formats for `#include':
+
+ #include "FILE"
+ #include <FILE>
+
+ If you have this problem, the best solution is to modify the source
+to convert the `#include' directives to one of the two standard forms.
+That will work with either compiler. If you want a quick and dirty fix,
+define the file names as macros with the proper expansion, like this:
+
+ #define stdio <stdio.h>
+
+This will work, as long as the name doesn't conflict with anything else
+in the program.
+
+ Another source of incompatibility is that VAX-C assumes that:
+
+ #include "foobar"
+
+is actually asking for the file `foobar.h'. GCC does not make this
+assumption, and instead takes what you ask for literally; it tries to
+read the file `foobar'. The best way to avoid this problem is to
+always specify the desired file extension in your include directives.
+
+ GCC for VMS is distributed with a set of include files that is
+sufficient to compile most general purpose programs. Even though the
+GCC distribution does not contain header files to define constants and
+structures for some VMS system-specific functions, there is no reason
+why you cannot use GCC with any of these functions. You first may have
+to generate or create header files, either by using the public domain
+utility `UNSDL' (which can be found on a DECUS tape), or by extracting
+the relevant modules from one of the system macro libraries, and using
+an editor to construct a C header file.
+
+ A `#include' file name cannot contain a DECNET node name. The
+preprocessor reports an I/O error if you attempt to use a node name,
+whether explicitly, or implicitly via a logical name.
+
+\1f
+File: gcc.info, Node: Global Declarations, Next: VMS Misc, Prev: Include Files and VMS, Up: VMS
+
+14.2 Global Declarations and VMS
+================================
+
+GCC does not provide the `globalref', `globaldef' and `globalvalue'
+keywords of VAX-C. You can get the same effect with an obscure feature
+of GAS, the GNU assembler. (This requires GAS version 1.39 or later.)
+The following macros allow you to use this feature in a fairly natural
+way:
+
+ #ifdef __GNUC__
+ #define GLOBALREF(TYPE,NAME) \
+ TYPE NAME \
+ asm ("_$$PsectAttributes_GLOBALSYMBOL$$" #NAME)
+ #define GLOBALDEF(TYPE,NAME,VALUE) \
+ TYPE NAME \
+ asm ("_$$PsectAttributes_GLOBALSYMBOL$$" #NAME) \
+ = VALUE
+ #define GLOBALVALUEREF(TYPE,NAME) \
+ const TYPE NAME[1] \
+ asm ("_$$PsectAttributes_GLOBALVALUE$$" #NAME)
+ #define GLOBALVALUEDEF(TYPE,NAME,VALUE) \
+ const TYPE NAME[1] \
+ asm ("_$$PsectAttributes_GLOBALVALUE$$" #NAME) \
+ = {VALUE}
+ #else
+ #define GLOBALREF(TYPE,NAME) \
+ globalref TYPE NAME
+ #define GLOBALDEF(TYPE,NAME,VALUE) \
+ globaldef TYPE NAME = VALUE
+ #define GLOBALVALUEDEF(TYPE,NAME,VALUE) \
+ globalvalue TYPE NAME = VALUE
+ #define GLOBALVALUEREF(TYPE,NAME) \
+ globalvalue TYPE NAME
+ #endif
+
+(The `_$$PsectAttributes_GLOBALSYMBOL' prefix at the start of the name
+is removed by the assembler, after it has modified the attributes of
+the symbol). These macros are provided in the VMS binaries
+distribution in a header file `GNU_HACKS.H'. An example of the usage
+is:
+
+ GLOBALREF (int, ijk);
+ GLOBALDEF (int, jkl, 0);
+
+ The macros `GLOBALREF' and `GLOBALDEF' cannot be used
+straightforwardly for arrays, since there is no way to insert the array
+dimension into the declaration at the right place. However, you can
+declare an array with these macros if you first define a typedef for the
+array type, like this:
+
+ typedef int intvector[10];
+ GLOBALREF (intvector, foo);
+
+ Array and structure initializers will also break the macros; you can
+define the initializer to be a macro of its own, or you can expand the
+`GLOBALDEF' macro by hand. You may find a case where you wish to use
+the `GLOBALDEF' macro with a large array, but you are not interested in
+explicitly initializing each element of the array. In such cases you
+can use an initializer like: `{0,}', which will initialize the entire
+array to `0'.
+
+ A shortcoming of this implementation is that a variable declared with
+`GLOBALVALUEREF' or `GLOBALVALUEDEF' is always an array. For example,
+the declaration:
+
+ GLOBALVALUEREF(int, ijk);
+
+declares the variable `ijk' as an array of type `int [1]'. This is
+done because a globalvalue is actually a constant; its "value" is what
+the linker would normally consider an address. That is not how an
+integer value works in C, but it is how an array works. So treating
+the symbol as an array name gives consistent results--with the
+exception that the value seems to have the wrong type. *Don't try to
+access an element of the array.* It doesn't have any elements. The
+array "address" may not be the address of actual storage.
+
+ The fact that the symbol is an array may lead to warnings where the
+variable is used. Insert type casts to avoid the warnings. Here is an
+example; it takes advantage of the ISO C feature allowing macros that
+expand to use the same name as the macro itself.
+
+ GLOBALVALUEREF (int, ss$_normal);
+ GLOBALVALUEDEF (int, xyzzy,123);
+ #ifdef __GNUC__
+ #define ss$_normal ((int) ss$_normal)
+ #define xyzzy ((int) xyzzy)
+ #endif
+
+ Don't use `globaldef' or `globalref' with a variable whose type is
+an enumeration type; this is not implemented. Instead, make the
+variable an integer, and use a `globalvaluedef' for each of the
+enumeration values. An example of this would be:
+
+ #ifdef __GNUC__
+ GLOBALDEF (int, color, 0);
+ GLOBALVALUEDEF (int, RED, 0);
+ GLOBALVALUEDEF (int, BLUE, 1);
+ GLOBALVALUEDEF (int, GREEN, 3);
+ #else
+ enum globaldef color {RED, BLUE, GREEN = 3};
+ #endif
+
+\1f
+File: gcc.info, Node: VMS Misc, Prev: Global Declarations, Up: VMS
+
+14.3 Other VMS Issues
+=====================
+
+GCC automatically arranges for `main' to return 1 by default if you
+fail to specify an explicit return value. This will be interpreted by
+VMS as a status code indicating a normal successful completion.
+Version 1 of GCC did not provide this default.
+
+ GCC on VMS works only with the GNU assembler, GAS. You need version
+1.37 or later of GAS in order to produce value debugging information for
+the VMS debugger. Use the ordinary VMS linker with the object files
+produced by GAS.
+
+ Under previous versions of GCC, the generated code would occasionally
+give strange results when linked to the sharable `VAXCRTL' library.
+Now this should work.
+
+ A caveat for use of `const' global variables: the `const' modifier
+must be specified in every external declaration of the variable in all
+of the source files that use that variable. Otherwise the linker will
+issue warnings about conflicting attributes for the variable. Your
+program will still work despite the warnings, but the variable will be
+placed in writable storage.
+
+ Although the VMS linker does distinguish between upper and lower case
+letters in global symbols, most VMS compilers convert all such symbols
+into upper case and most run-time library routines also have upper case
+names. To be able to reliably call such routines, GCC (by means of the
+assembler GAS) converts global symbols into upper case like other VMS
+compilers. However, since the usual practice in C is to distinguish
+case, GCC (via GAS) tries to preserve usual C behavior by augmenting
+each name that is not all lower case. This means truncating the name
+to at most 23 characters and then adding more characters at the end
+which encode the case pattern of those 23. Names which contain at
+least one dollar sign are an exception; they are converted directly into
+upper case without augmentation.
+
+ Name augmentation yields bad results for programs that use
+precompiled libraries (such as Xlib) which were generated by another
+compiler. You can use the compiler option `/NOCASE_HACK' to inhibit
+augmentation; it makes external C functions and variables
+case-independent as is usual on VMS. Alternatively, you could write
+all references to the functions and variables in such libraries using
+lower case; this will work on VMS, but is not portable to other
+systems. The compiler option `/NAMES' also provides control over
+global name handling.
+
+ Function and variable names are handled somewhat differently with
+G++. The GNU C++ compiler performs "name mangling" on function names,
+which means that it adds information to the function name to describe
+the data types of the arguments that the function takes. One result of
+this is that the name of a function can become very long. Since the
+VMS linker only recognizes the first 31 characters in a name, special
+action is taken to ensure that each function and variable has a unique
+name that can be represented in 31 characters.
+
+ If the name (plus a name augmentation, if required) is less than 32
+characters in length, then no special action is performed. If the name
+is longer than 31 characters, the assembler (GAS) will generate a hash
+string based upon the function name, truncate the function name to 23
+characters, and append the hash string to the truncated name. If the
+`/VERBOSE' compiler option is used, the assembler will print both the
+full and truncated names of each symbol that is truncated.
+
+ The `/NOCASE_HACK' compiler option should not be used when you are
+compiling programs that use libg++. libg++ has several instances of
+objects (i.e. `Filebuf' and `filebuf') which become indistinguishable
+in a case-insensitive environment. This leads to cases where you need
+to inhibit augmentation selectively (if you were using libg++ and Xlib
+in the same program, for example). There is no special feature for
+doing this, but you can get the result by defining a macro for each
+mixed case symbol for which you wish to inhibit augmentation. The
+macro should expand into the lower case equivalent of itself. For
+example:
+
+ #define StuDlyCapS studlycaps
+
+ These macro definitions can be placed in a header file to minimize
+the number of changes to your source code.
+
+\1f
+File: gcc.info, Node: Funding, Next: GNU Project, Prev: VMS, Up: Top
+
+Funding Free Software
+*********************
+
+If you want to have more free software a few years from now, it makes
+sense for you to help encourage people to contribute funds for its
+development. The most effective approach known is to encourage
+commercial redistributors to donate.
+
+ Users of free software systems can boost the pace of development by
+encouraging for-a-fee distributors to donate part of their selling price
+to free software developers--the Free Software Foundation, and others.
+
+ The way to convince distributors to do this is to demand it and
+expect it from them. So when you compare distributors, judge them
+partly by how much they give to free software development. Show
+distributors they must compete to be the one who gives the most.
+
+ To make this approach work, you must insist on numbers that you can
+compare, such as, "We will donate ten dollars to the Frobnitz project
+for each disk sold." Don't be satisfied with a vague promise, such as
+"A portion of the profits are donated," since it doesn't give a basis
+for comparison.
+
+ Even a precise fraction "of the profits from this disk" is not very
+meaningful, since creative accounting and unrelated business decisions
+can greatly alter what fraction of the sales price counts as profit.
+If the price you pay is $50, ten percent of the profit is probably less
+than a dollar; it might be a few cents, or nothing at all.
+
+ Some redistributors do development work themselves. This is useful
+too; but to keep everyone honest, you need to inquire how much they do,
+and what kind. Some kinds of development make much more long-term
+difference than others. For example, maintaining a separate version of
+a program contributes very little; maintaining the standard version of a
+program for the whole community contributes much. Easy new ports
+contribute little, since someone else would surely do them; difficult
+ports such as adding a new CPU to the GNU Compiler Collection
+contribute more; major new features or packages contribute the most.
+
+ By establishing the idea that supporting further development is "the
+proper thing to do" when distributing free software for a fee, we can
+assure a steady flow of resources into making more free software.
+
+ Copyright (C) 1994 Free Software Foundation, Inc.
+ Verbatim copying and redistribution of this section is permitted
+ without royalty; alteration is not permitted.
+
+\1f
+File: gcc.info, Node: GNU Project, Next: Copying, Prev: Funding, Up: Top
+
+The GNU Project and GNU/Linux
+*****************************
+
+The GNU Project was launched in 1984 to develop a complete Unix-like
+operating system which is free software: the GNU system. (GNU is a
+recursive acronym for "GNU's Not Unix"; it is pronounced "guh-NEW".)
+Variants of the GNU operating system, which use the kernel Linux, are
+now widely used; though these systems are often referred to as "Linux",
+they are more accurately called GNU/Linux systems.
+
+ For more information, see:
+ `http://www.gnu.org/'
+ `http://www.gnu.org/gnu/linux-and-gnu.html'
+
+\1f
+File: gcc.info, Node: Copying, Next: GNU Free Documentation License, Prev: GNU Project, 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) YEAR 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) YEAR 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.
+
+\1f
+File: gcc.info, Node: GNU Free Documentation License, Next: Contributors, Prev: Copying, Up: Top
+
+GNU Free Documentation License
+******************************
+
+ Version 1.1, March 2000
+
+ Copyright (C) 2000 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.
+
+ 0. PREAMBLE
+
+ The purpose of this License is to make a manual, textbook, or other
+ written document "free" in the sense of freedom: to assure everyone
+ the effective freedom to copy and redistribute it, with or without
+ modifying it, either commercially or noncommercially. Secondarily,
+ this License preserves for the author and publisher a way to get
+ credit for their work, while not being considered responsible for
+ modifications made by others.
+
+ This License is a kind of "copyleft", which means that derivative
+ works of the document must themselves be free in the same sense.
+ It complements the GNU General Public License, which is a copyleft
+ license designed for free software.
+
+ We have designed this License in order to use it for manuals for
+ free software, because free software needs free documentation: a
+ free program should come with manuals providing the same freedoms
+ that the software does. But this License is not limited to
+ software manuals; it can be used for any textual work, regardless
+ of subject matter or whether it is published as a printed book.
+ We recommend this License principally for works whose purpose is
+ instruction or reference.
+
+ 1. APPLICABILITY AND DEFINITIONS
+
+ This License applies to any manual or other work that contains a
+ notice placed by the copyright holder saying it can be distributed
+ under the terms of this License. The "Document", below, refers to
+ any such manual or work. Any member of the public is a licensee,
+ and is addressed as "you".
+
+ A "Modified Version" of the Document means any work containing the
+ Document or a portion of it, either copied verbatim, or with
+ modifications and/or translated into another language.
+
+ A "Secondary Section" is a named appendix or a front-matter
+ section of the Document that deals exclusively with the
+ relationship of the publishers or authors of the Document to the
+ Document's overall subject (or to related matters) and contains
+ nothing that could fall directly within that overall subject.
+ (For example, if the Document is in part a textbook of
+ mathematics, a Secondary Section may not explain any mathematics.)
+ The relationship could be a matter of historical connection with
+ the subject or with related matters, or of legal, commercial,
+ philosophical, ethical or political position regarding them.
+
+ The "Invariant Sections" are certain Secondary Sections whose
+ titles are designated, as being those of Invariant Sections, in
+ the notice that says that the Document is released under this
+ License.
+
+ The "Cover Texts" are certain short passages of text that are
+ listed, as Front-Cover Texts or Back-Cover Texts, in the notice
+ that says that the Document is released under this License.
+
+ A "Transparent" copy of the Document means a machine-readable copy,
+ represented in a format whose specification is available to the
+ general public, whose contents can be viewed and edited directly
+ and straightforwardly with generic text editors or (for images
+ composed of pixels) generic paint programs or (for drawings) some
+ widely available drawing editor, and that is suitable for input to
+ text formatters or for automatic translation to a variety of
+ formats suitable for input to text formatters. A copy made in an
+ otherwise Transparent file format whose markup has been designed
+ to thwart or discourage subsequent modification by readers is not
+ Transparent. A copy that is not "Transparent" is called "Opaque".
+
+ Examples of suitable formats for Transparent copies include plain
+ ASCII without markup, Texinfo input format, LaTeX input format,
+ SGML or XML using a publicly available DTD, and
+ standard-conforming simple HTML designed for human modification.
+ Opaque formats include PostScript, PDF, proprietary formats that
+ can be read and edited only by proprietary word processors, SGML
+ or XML for which the DTD and/or processing tools are not generally
+ available, and the machine-generated HTML produced by some word
+ processors for output purposes only.
+
+ The "Title Page" means, for a printed book, the title page itself,
+ plus such following pages as are needed to hold, legibly, the
+ material this License requires to appear in the title page. For
+ works in formats which do not have any title page as such, "Title
+ Page" means the text near the most prominent appearance of the
+ work's title, preceding the beginning of the body of the text.
+
+ 2. VERBATIM COPYING
+
+ You may copy and distribute the Document in any medium, either
+ commercially or noncommercially, provided that this License, the
+ copyright notices, and the license notice saying this License
+ applies to the Document are reproduced in all copies, and that you
+ add no other conditions whatsoever to those of this License. You
+ may not use technical measures to obstruct or control the reading
+ or further copying of the copies you make or distribute. However,
+ you may accept compensation in exchange for copies. If you
+ distribute a large enough number of copies you must also follow
+ the conditions in section 3.
+
+ You may also lend copies, under the same conditions stated above,
+ and you may publicly display copies.
+
+ 3. COPYING IN QUANTITY
+
+ If you publish printed copies of the Document numbering more than
+ 100, and the Document's license notice requires Cover Texts, you
+ must enclose the copies in covers that carry, clearly and legibly,
+ all these Cover Texts: Front-Cover Texts on the front cover, and
+ Back-Cover Texts on the back cover. Both covers must also clearly
+ and legibly identify you as the publisher of these copies. The
+ front cover must present the full title with all words of the
+ title equally prominent and visible. You may add other material
+ on the covers in addition. Copying with changes limited to the
+ covers, as long as they preserve the title of the Document and
+ satisfy these conditions, can be treated as verbatim copying in
+ other respects.
+
+ If the required texts for either cover are too voluminous to fit
+ legibly, you should put the first ones listed (as many as fit
+ reasonably) on the actual cover, and continue the rest onto
+ adjacent pages.
+
+ If you publish or distribute Opaque copies of the Document
+ numbering more than 100, you must either include a
+ machine-readable Transparent copy along with each Opaque copy, or
+ state in or with each Opaque copy a publicly-accessible
+ computer-network location containing a complete Transparent copy
+ of the Document, free of added material, which the general
+ network-using public has access to download anonymously at no
+ charge using public-standard network protocols. If you use the
+ latter option, you must take reasonably prudent steps, when you
+ begin distribution of Opaque copies in quantity, to ensure that
+ this Transparent copy will remain thus accessible at the stated
+ location until at least one year after the last time you
+ distribute an Opaque copy (directly or through your agents or
+ retailers) of that edition to the public.
+
+ It is requested, but not required, that you contact the authors of
+ the Document well before redistributing any large number of
+ copies, to give them a chance to provide you with an updated
+ version of the Document.
+
+ 4. MODIFICATIONS
+
+ You may copy and distribute a Modified Version of the Document
+ under the conditions of sections 2 and 3 above, provided that you
+ release the Modified Version under precisely this License, with
+ the Modified Version filling the role of the Document, thus
+ licensing distribution and modification of the Modified Version to
+ whoever possesses a copy of it. In addition, you must do these
+ things in the Modified Version:
+
+ A. Use in the Title Page (and on the covers, if any) a title
+ distinct from that of the Document, and from those of
+ previous versions (which should, if there were any, be listed
+ in the History section of the Document). You may use the
+ same title as a previous version if the original publisher of
+ that version gives permission.
+
+ B. List on the Title Page, as authors, one or more persons or
+ entities responsible for authorship of the modifications in
+ the Modified Version, together with at least five of the
+ principal authors of the Document (all of its principal
+ authors, if it has less than five).
+
+ C. State on the Title page the name of the publisher of the
+ Modified Version, as the publisher.
+
+ D. Preserve all the copyright notices of the Document.
+
+ E. Add an appropriate copyright notice for your modifications
+ adjacent to the other copyright notices.
+
+ F. Include, immediately after the copyright notices, a license
+ notice giving the public permission to use the Modified
+ Version under the terms of this License, in the form shown in
+ the Addendum below.
+
+ G. Preserve in that license notice the full lists of Invariant
+ Sections and required Cover Texts given in the Document's
+ license notice.
+
+ H. Include an unaltered copy of this License.
+
+ I. Preserve the section entitled "History", and its title, and
+ add to it an item stating at least the title, year, new
+ authors, and publisher of the Modified Version as given on
+ the Title Page. If there is no section entitled "History" in
+ the Document, create one stating the title, year, authors,
+ and publisher of the Document as given on its Title Page,
+ then add an item describing the Modified Version as stated in
+ the previous sentence.
+
+ J. Preserve the network location, if any, given in the Document
+ for public access to a Transparent copy of the Document, and
+ likewise the network locations given in the Document for
+ previous versions it was based on. These may be placed in
+ the "History" section. You may omit a network location for a
+ work that was published at least four years before the
+ Document itself, or if the original publisher of the version
+ it refers to gives permission.
+
+ K. In any section entitled "Acknowledgments" or "Dedications",
+ preserve the section's title, and preserve in the section all
+ the substance and tone of each of the contributor
+ acknowledgments and/or dedications given therein.
+
+ L. Preserve all the Invariant Sections of the Document,
+ unaltered in their text and in their titles. Section numbers
+ or the equivalent are not considered part of the section
+ titles.
+
+ M. Delete any section entitled "Endorsements". Such a section
+ may not be included in the Modified Version.
+
+ N. Do not retitle any existing section as "Endorsements" or to
+ conflict in title with any Invariant Section.
+
+ If the Modified Version includes new front-matter sections or
+ appendices that qualify as Secondary Sections and contain no
+ material copied from the Document, you may at your option
+ designate some or all of these sections as invariant. To do this,
+ add their titles to the list of Invariant Sections in the Modified
+ Version's license notice. These titles must be distinct from any
+ other section titles.
+
+ You may add a section entitled "Endorsements", provided it contains
+ nothing but endorsements of your Modified Version by various
+ parties--for example, statements of peer review or that the text
+ has been approved by an organization as the authoritative
+ definition of a standard.
+
+ You may add a passage of up to five words as a Front-Cover Text,
+ and a passage of up to 25 words as a Back-Cover Text, to the end
+ of the list of Cover Texts in the Modified Version. Only one
+ passage of Front-Cover Text and one of Back-Cover Text may be
+ added by (or through arrangements made by) any one entity. If the
+ Document already includes a cover text for the same cover,
+ previously added by you or by arrangement made by the same entity
+ you are acting on behalf of, you may not add another; but you may
+ replace the old one, on explicit permission from the previous
+ publisher that added the old one.
+
+ The author(s) and publisher(s) of the Document do not by this
+ License give permission to use their names for publicity for or to
+ assert or imply endorsement of any Modified Version.
+
+ 5. COMBINING DOCUMENTS
+
+ You may combine the Document with other documents released under
+ this License, under the terms defined in section 4 above for
+ modified versions, provided that you include in the combination
+ all of the Invariant Sections of all of the original documents,
+ unmodified, and list them all as Invariant Sections of your
+ combined work in its license notice.
+
+ The combined work need only contain one copy of this License, and
+ multiple identical Invariant Sections may be replaced with a single
+ copy. If there are multiple Invariant Sections with the same name
+ but different contents, make the title of each such section unique
+ by adding at the end of it, in parentheses, the name of the
+ original author or publisher of that section if known, or else a
+ unique number. Make the same adjustment to the section titles in
+ the list of Invariant Sections in the license notice of the
+ combined work.
+
+ In the combination, you must combine any sections entitled
+ "History" in the various original documents, forming one section
+ entitled "History"; likewise combine any sections entitled
+ "Acknowledgments", and any sections entitled "Dedications". You
+ must delete all sections entitled "Endorsements."
+
+ 6. COLLECTIONS OF DOCUMENTS
+
+ You may make a collection consisting of the Document and other
+ documents released under this License, and replace the individual
+ copies of this License in the various documents with a single copy
+ that is included in the collection, provided that you follow the
+ rules of this License for verbatim copying of each of the
+ documents in all other respects.
+
+ You may extract a single document from such a collection, and
+ distribute it individually under this License, provided you insert
+ a copy of this License into the extracted document, and follow
+ this License in all other respects regarding verbatim copying of
+ that document.
+
+ 7. AGGREGATION WITH INDEPENDENT WORKS
+
+ A compilation of the Document or its derivatives with other
+ separate and independent documents or works, in or on a volume of
+ a storage or distribution medium, does not as a whole count as a
+ Modified Version of the Document, provided no compilation
+ copyright is claimed for the compilation. Such a compilation is
+ called an "aggregate", and this License does not apply to the
+ other self-contained works thus compiled with the Document, on
+ account of their being thus compiled, if they are not themselves
+ derivative works of the Document.
+
+ If the Cover Text requirement of section 3 is applicable to these
+ copies of the Document, then if the Document is less than one
+ quarter of the entire aggregate, the Document's Cover Texts may be
+ placed on covers that surround only the Document within the
+ aggregate. Otherwise they must appear on covers around the whole
+ aggregate.
+
+ 8. TRANSLATION
+
+ Translation is considered a kind of modification, so you may
+ distribute translations of the Document under the terms of section
+ 4. Replacing Invariant Sections with translations requires special
+ permission from their copyright holders, but you may include
+ translations of some or all Invariant Sections in addition to the
+ original versions of these Invariant Sections. You may include a
+ translation of this License provided that you also include the
+ original English version of this License. In case of a
+ disagreement between the translation and the original English
+ version of this License, the original English version will prevail.
+
+ 9. TERMINATION
+
+ You may not copy, modify, sublicense, or distribute the Document
+ except as expressly provided for under this License. Any other
+ attempt to copy, modify, sublicense or distribute the Document 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.
+
+ 10. FUTURE REVISIONS OF THIS LICENSE
+
+ The Free Software Foundation may publish new, revised versions of
+ the GNU Free Documentation 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. See
+ `http://www.gnu.org/copyleft/'.
+
+ Each version of the License is given a distinguishing version
+ number. If the Document specifies that a particular numbered
+ version of this License "or any later version" applies to it, you
+ have the option of following the terms and conditions either of
+ that specified version or of any later version that has been
+ published (not as a draft) by the Free Software Foundation. If
+ the Document does not specify a version number of this License,
+ you may choose any version ever published (not as a draft) by the
+ Free Software Foundation.
+
+ADDENDUM: How to use this License for your documents
+====================================================
+
+To use this License in a document you have written, include a copy of
+the License in the document and put the following copyright and license
+notices just after the title page:
+
+ Copyright (C) YEAR YOUR NAME.
+ Permission is granted to copy, distribute and/or modify this document
+ under the terms of the GNU Free Documentation License, Version 1.1
+ or any later version published by the Free Software Foundation;
+ with the Invariant Sections being LIST THEIR TITLES, with the
+ Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST.
+ A copy of the license is included in the section entitled ``GNU
+ Free Documentation License''.
+
+ If you have no Invariant Sections, write "with no Invariant Sections"
+instead of saying which ones are invariant. If you have no Front-Cover
+Texts, write "no Front-Cover Texts" instead of "Front-Cover Texts being
+LIST"; likewise for Back-Cover Texts.
+
+ If your document contains nontrivial examples of program code, we
+recommend releasing these examples in parallel under your choice of
+free software license, such as the GNU General Public License, to
+permit their use in free software.