This is doc/gcc.info, produced by makeinfo version 4.5 from
doc/gcc.texi.

INFO-DIR-SECTION Programming
START-INFO-DIR-ENTRY
* gcc: (gcc).                  The GNU Compiler Collection.
END-INFO-DIR-ENTRY
   This file documents the use of the GNU compilers.

   Published by the Free Software Foundation
59 Temple Place - Suite 330
Boston, MA 02111-1307 USA

   Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
1999, 2000, 2001, 2002 Free Software Foundation, Inc.

   Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.1 or
any later version published by the Free Software Foundation; with the
Invariant Sections being "GNU General Public License" and "Funding Free
Software", the Front-Cover texts being (a) (see below), and with the
Back-Cover Texts being (b) (see below).  A copy of the license is
included in the section entitled "GNU Free Documentation License".

   (a) The FSF's Front-Cover Text is:

   A GNU Manual

   (b) The FSF's Back-Cover Text is:

   You have freedom to copy and modify this GNU Manual, like GNU
software.  Copies published by the Free Software Foundation raise
funds for GNU development.


File: gcc.info,  Node: Bug Reporting,  Next: gccbug,  Prev: Bug Lists,  Up: Bugs

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.


File: gcc.info,  Node: gccbug,  Prev: Bug Reporting,  Up: Bugs

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'.


File: gcc.info,  Node: Service,  Next: Contributing,  Prev: Bugs,  Up: Top

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'.


File: gcc.info,  Node: Contributing,  Next: VMS,  Prev: Service,  Up: Top

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/'.


File: gcc.info,  Node: VMS,  Next: Funding,  Prev: Contributing,  Up: Top

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.


File: gcc.info,  Node: Include Files and VMS,  Next: Global Declarations,  Up: VMS

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.


File: gcc.info,  Node: Global Declarations,  Next: VMS Misc,  Prev: Include Files and VMS,  Up: VMS

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


File: gcc.info,  Node: VMS Misc,  Prev: Global Declarations,  Up: VMS

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.


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.


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'


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.

