gcc.texi

早期freebsd实现

implemented multiply-by-constant optimization and better long long
support, and improved leaf function register allocation.

@item
Mike Stump implemented the support for Elxsi 64 bit CPU.
@end itemize

@node Boycott
@chapter Protect Your Freedom---Fight ``Look And Feel''

@quotation
@i{This section is a political message from the League for Programming
Freedom to the users of GNU CC.  It is included here as an expression
of support for the League on the part of the Free Software Foundation.}
@end quotation

Apple and Lotus are trying to create a new form of legal monopoly: a
copyright on a class of user interfaces.  These monopolies would cause
serious problems for users and developers of computer software and
systems.  Xerox, too, has tried to make a monopoly for itself on window
systems; their suit against Apple was thrown out on a technicality, but
Xerox has not said anything to indicate it wouldn't try again.

Until a few years ago, the law seemed clear: no one could restrict
others from using a user interface; programmers were free to implement
any interface they chose.  Imitating interfaces, sometimes with changes,
was standard practice in the computer field.  The interfaces we know
evolved gradually in this way; for example, the Macintosh user interface
drew ideas from the Xerox interface, which in turn drew on work done at
Stanford and SRI.  1-2-3 imitated VisiCalc, and dBase imitated a
database program from JPL.

Most computer companies, and nearly all computer users, were happy with
this state of affairs.  The companies that are suing say it does not
offer ``enough incentive'' to develop their products, but they must have
considered it ``enough'' when they made their decision to do so.  It
seems they are not satisfied with the opportunity to continue to compete
in the marketplace---not even with a head start.

If companies like Xerox, Lotus, and Apple are permitted to make law
through the courts, the precedent will hobble the software industry:

@itemize @bullet
@item
Gratuitous incompatibilities will burden users.  Imagine if each
car manufacturer had to arrange the pedals in a different order.

@item
Software will become and remain more expensive.  Users will be
``locked in'' to proprietary interfaces, for which there is no real
competition.

@item
Large companies have an unfair advantage wherever lawsuits become
commonplace.  Since they can easily afford to sue, they can intimidate
small companies with threats even when they don't really have a case.

@item
User interface improvements will come slower, since incremental
evolution through creative imitation will no longer be permitted.

@item
Even Apple, etc., will find it harder to make improvements if
they can no longer adapt the good ideas that others introduce, for
fear of weakening their own legal positions.  Some users suggest that
this stagnation may already have started.

@item
If you use GNU software, you might find it of some concern that user
interface copyright will make it hard for the Free Software Foundation
to develop programs compatible with the interfaces that you already
know.
@end itemize

To protect our freedom from lawsuits like these, a group of programmers
and users have formed a new grass-roots political organization, the
League for Programming Freedom.

The purpose of the League is to oppose new monopolistic practices such
as user-interface copyright and software patents; it calls for a return
to the legal policies of the recent past, in which these practices were
not allowed.  The League is not concerned with free software as an
issue, and not affiliated with the Free Software Foundation.

The League's membership rolls include John McCarthy, inventor of Lisp,
Marvin Minsky, founder of the Artificial Intelligence lab, Guy L.
Steele, Jr., author of well-known books on Lisp and C, as well as
Richard Stallman, the developer of GNU CC.  Please join and add your
name to the list.  Membership dues in the League are $42 per year for
programmers, managers and professionals; $10.50 for students; $21 for
others.

The League needs both activist members and members who only pay their
dues.

To join, or for more information, phone [phone] or write to:

@display
League for Programming Freedom
1 Kendall Square #143
P.O. Box 9171
Cambridge, MA 02139
@end display

You can also send electronic mail to @code{league@@prep.ai.mit.edu}.

Here are some suggestions from the League for things you can do to
protect your freedom to write programs:

@itemize @bullet
@item
Don't buy from Xerox, Lotus or Apple.  Buy from their competitors or
from the defendants they are suing.

@item
Don't develop software to work with the systems made by these companies.

@item
Port your existing software to competing systems, so that you encourage
users to switch.

@item
Write letters to company presidents to let them know their conduct
is unacceptable.

@item
Tell your friends and colleagues about this issue and how it threatens
to ruin the computer industry.

@item
Above all, don't work for the look-and-feel plaintiffs, and don't
accept contracts from them.

@item
Write to Congress to explain the importance of this issue.

@display
House Subcommittee on Intellectual Property
2137 Rayburn Bldg
Washington, DC 20515

Senate Subcommittee on Patents, Trademarks and Copyrights
United States Senate
Washington, DC 20510
@end display

(These committees have received lots of mail already; let's give them
even more.)
@end itemize

Express your opinion!  You can make a difference.

@include invoke.texi

@include install.texi

@include extend.texi

@node Trouble
@chapter Known Causes of Trouble with GNU CC
@cindex bugs, known
@cindex installation trouble
@cindex known causes of trouble

This section describes known problems that affect users of GNU CC.  Most
of these are not GNU CC bugs per se---if they were, we would fix them.
But the result for a user may be like the result of a bug.

Some of these problems are due to bugs in other software, some are
missing features that are too much work to add, and some are places
where people's opinions differ as to what is best.

@menu
* Actual Bugs::		      Bugs we will fix later.
* Installation Problems::     Problems that manifest when you install GNU CC.
* Cross-Compiler Problems::   Common problems of cross compiling with GNU CC.
* Interoperation::      Problems using GNU CC with other compilers,
			   and with certain linkers, assemblers and debuggers.
* Incompatibilities::   GNU CC is incompatible with traditional C.
* Disappointments::     Regrettable things we can't change, but not quite bugs.
* Protoize Caveats::    Things to watch out for when using @code{protoize}.
* Non-bugs::		Things we think are right, but some others disagree.
@end menu

@node Actual Bugs
@section Actual Bugs We Haven't Fixed Yet

@itemize @bullet
@item
Loop unrolling doesn't work properly for certain C++ programs.  This is
because of difficulty in updating the debugging information within the
loop being unrolled.  We plan to revamp the representation of debugging
information so that this will work properly, but we have not done this
in version 2.3 because we don't want to delay it any further.
@end itemize

@node Installation Problems
@section Installation Problems

This is a list of problems (and some apparent problems which don't
really mean anything is wrong) that show up during installation of GNU
CC.

@itemize @bullet
@item
On certain systems, defining certain environment variables such as
@code{CC} can interfere with the functioning of @code{make}.

@item
If you encounter seemingly strange errors when trying to build the
compiler in a directory other than the source directory, it could be
because you have previously configured the compiler in the source
directory.  Make sure you have done all the necessary preparations.
@xref{Other Dir}.

@item
In previous versions of GNU CC, the @code{gcc} driver program looked for
@code{as} and @code{ld} in various places such as files beginning with
@file{/usr/local/lib/gcc-}.  GNU CC version 2 looks for them in the
directory @file{/usr/local/lib/gcc-lib/@var{target}/@var{version}}.

Thus, to use a version of @code{as} or @code{ld} that is not the system
default, for example @code{gas} or GNU @code{ld}, you must put them in
that directory (or make links to them from that directory).

@item
Some commands executed when making the compiler may fail (return a
non-zero status) and be ignored by @code{make}.  These failures, which
are often due to files that were not found, are expected, and can safely
be ignored.

@item
It is normal to have warnings in compiling certain files about
unreachable code and about enumeration type clashes.  These files' names
begin with @samp{insn-}.

@item
Sometimes @code{make} recompiles parts of the compiler when installing
the compiler.  In one case, this was traced down to a bug in
@code{make}.  Either ignore the problem or switch to GNU Make.

@item
On some 386 systems, building the compiler never finishes because
@code{enquire} hangs due to a hardware problem in the motherboard---it
reports floating point exceptions to the kernel incorrectly.  You can
install GNU CC except for @file{float.h} by patching out the command to
run @code{enquire}.  You may also be able to fix the problem for real by
getting a replacement motherboard.  This problem was observed in
Revision E of the Micronics motherboard, and is fixed in Revision F.

@item
On some 386 systems, GNU CC crashes trying to compile @file{enquire.c}.
This happens on machines that don't have a 387 FPU chip.  On 386
machines, the system kernel is supposed to emulate the 387 when you
don't have one.  The crash is due to a bug in the emulator.

One of these systems is the Unix from Interactive Systems: 386/ix.
On this system, an alternate emulator is provided, and it does work.
To use it, execute this command as super-user:

@example
ln /etc/emulator.rel1 /etc/emulator
@end example

@noindent
and then reboot the system.  (The default emulator file remains present
under the name @file{emulator.dflt}.)

If you have such a problem on the SCO system, try using
@file{/etc/emulator.att}.

Another system which has this problem is Esix.  We don't know whether it
has an alternate emulator that works.

@cindex @code{genflags}, crash on Sun 4
@item
Sometimes on a Sun 4 you may observe a crash in the program
@code{genflags} or @code{genoutput} while building GNU CC.  This is said to
be due to a bug in @code{sh}.  You can probably get around it by running
@code{genflags} or @code{genoutput} manually and then retrying the
@code{make}.

@item
If you use the 1.31 version of the MIPS assembler (such as was shipped
with Ultrix 3.1), you will need to use the -fno-delayed-branch switch
when optimizing floating point code.  Otherwise, the assembler will
complain when the GCC compiler fills a branch delay slot with a
floating point instruction, such as add.d.

@item
Users have reported some problems with version 2.0 of the MIPS
compiler tools that were shipped with Ultrix 4.1.  Version 2.10
which came with Ultrix 4.2 seems to work fine.

@item
Some versions of the MIPS linker will issue an assertion failure
when linking code that uses @code{alloca} against shared
libraries on RISC-OS 5.0, and DEC's OSF/1 systems.  This is a bug
in the linker, that is supposed to be fixed in future revisions.
To protect against this, GCC passes @samp{-non_shared} to the
linker unless you pass an explicit @samp{-shared} or
@samp{-call_shared} switch.

@item
On System V release 3, you may get this error message
while linking:

@smallexample
ld fatal: failed to write symbol name @var{something} 
 in strings table for file @var{whatever}
@end smallexample

This indicates that the disk is full or your ULIMIT won't allow
the file to be as large as it needs to be.

@item
On HP 9000 series 300 or 400 running HP-UX release 8.0, there is a bug
in the assembler that must be fixed before GNU CC can be built.  This
bug manifests itself during the first stage of compilation, while
building @file{libgcc2.a}:

@example
_floatdisf
cc1: warning: `-g' option not supported on this version of GCC
cc1: warning: `-g1' option not supported on this version of GCC
./gcc: Internal compiler error: program as got fatal signal 11
@end example

A patched version of the assembler is available by anonymous ftp from
@code{altdorf.ai.mit.edu} as the file
@file{archive/cph/hpux-8.0-assembler}.  If you have HP software support,
the patch can also be obtained directly from HP, as described in the
following note:

@quotation
This is the patched assembler, to patch SR#1653-010439, where the
assembler aborts on floating point constants.

The bug is not really in the assembler, but in the shared library
version of the function ``cvtnum(3c)''.  The bug on ``cvtnum(3c)'' is