gcc.texi

早期freebsd实现

SR#4701-078451.  Anyway, the attached assembler uses the archive
library version of ``cvtnum(3c)'' and thus does not exhibit the bug.
@end quotation

This patch is also known as PHCO_0800.

@item
Another assembler problem on the HP PA results in an error message like
this while compiling part of @file{libgcc2.a}:

@example
as: /usr/tmp/cca08196.s @@line#30 [err#1060]
  Argument 1 or 3 in FARG upper
         - lookahead = RTNVAL=GR
@end example

This happens because HP changed the assembler syntax after system
release 8.02.  GNU CC assumes the newer syntax; if your assembler wants
the older syntax, comment out this line in the file @file{pa1-hpux.h}:

@example
#define HP_FP_ARG_DESCRIPTOR_REVERSED
@end example

@item
Some versions of the Pyramid C compiler are reported to be unable to
compile GNU CC.  You must use an older version of GNU CC for
bootstrapping.  One indication of this problem is if you get a crash
when GNU CC compiles the function @code{muldi3} in file @file{libgcc2.c}.

You may be able to succeed by getting GNU CC version 1, installing it,
and using it to compile GNU CC version 2.  The bug in the Pyramid C
compiler does not seem to affect GNU CC version 1.

@item
On the Tower models 4@var{n}0 and 6@var{n}0, by default a process is not
allowed to have more than one megabyte of memory.  GNU CC cannot compile
itself (or many other programs) with @samp{-O} in that much memory.

To solve this problem, reconfigure the kernel adding the following line
to the configuration file:

@example
MAXUMEM = 4096
@end example

@item
On the Altos 3068, programs compiled with GNU CC won't work unless you
fix a kernel bug.  This happens using system versions V.2.2 1.0gT1 and
V.2.2 1.0e and perhaps later versions as well.  See the file
@file{README.ALTOS}.

@item
You will get several sorts of compilation and linking errors on the
we32k if you don't follow the special instructions.  @xref{WE32K
Install}.
@end itemize

@node Cross-Compiler Problems
@section Cross-Compiler Problems

@itemize @bullet
@item
Cross compilation can run into trouble for certain machines because
some target machines' assemblers require floating point numbers to be
written as @emph{integer} constants in certain contexts.

The compiler writes these integer constants by examining the floating
point value as an integer and printing that integer, because this is
simple to write and independent of the details of the floating point
representation.  But this does not work if the compiler is running on
a different machine with an incompatible floating point format, or
even a different byte-ordering.

In addition, correct constant folding of floating point values
requires representing them in the target machine's format.
(The C standard does not quite require this, but in practice
it is the only way to win.)

@ifset INTERNALS
It is now possible to overcome these problems by defining macros such
as @code{REAL_VALUE_TYPE}.  But doing so is a substantial amount of
work for each target machine.  @xref{Cross-compilation}.
@end ifset
@ifclear INTERNALS
It is now possible to overcome these problems by defining macros such
as @code{REAL_VALUE_TYPE}.  But doing so is a substantial amount of
work for each target machine.  @xref{Cross-compilation,,Cross
Compilation and Floating Point Format, gcc.info, Using and Porting GCC}.
@end ifclear

@item
At present, the program @file{mips-tfile} which adds debug
support to object files on MIPS systems does not work in a cross
compile environment.
@end itemize

@node Interoperation
@section Interoperation

This section lists various difficulties encountered in using GNU C or
GNU C++ together with other compilers or with the assemblers, linkers,
libraries and debuggers on certain systems.

@itemize @bullet
@item
GNU C normally compiles functions to return small structures and unions
in registers.  Most other compilers arrange to return them just like
larger structures and unions.  This can lead to trouble when you link
together code compiled by different compilers. To avoid the problem, you
can use the option @samp{-fpcc-struct-return} when compiling with GNU CC.

@item
GNU C++ does not do name mangling in the same way as other C++
compilers.  This means that object files compiled with one compiler
cannot be used with another.

GNU C++ also uses different techniques for arranging virtual function
tables and the layout of class instances.  In general, therefore,
linking code compiled with different C++ compilers does not work.

@item
Older GDB versions sometimes fail to read the output of GNU CC version
2.  If you have trouble, get GDB version 4.4 or later.

@item
@cindex DBX
DBX rejects some files produced by GNU CC, though it accepts similar
constructs in output from PCC.  Until someone can supply a coherent
description of what is valid DBX input and what is not, there is
nothing I can do about these problems.  You are on your own.

@item
The GNU assembler (GAS) does not support PIC.  To generate PIC code, you
must use some other assembler, such as @file{/bin/as}.

@item
On some BSD systems including some versions of Ultrix, use of profiling
causes static variable destructors (currently used only in C++) not to
be run.

@item
Use of @samp{-I/usr/include} may cause trouble.

Many systems come with header files that won't work with GNU CC unless
corrected by @code{fixincludes}.  The corrected header files go in a new
directory; GNU CC searches this directory before @file{/usr/include}.
If you use @samp{-I/usr/include}, this tells GNU CC to search
@file{/usr/include} earlier on, before the corrected headers.  The
result is that you get the uncorrected header files.

Instead, you should use these options:

@example
-I/usr/local/lib/gcc-lib/@var{target}/@var{version}/include -I/usr/include
@end example

@ignore
@cindex @code{vfork}, for the Sun-4
@item
There is a bug in @code{vfork} on the Sun-4 which causes the registers
of the child process to clobber those of the parent.  Because of this,
programs that call @code{vfork} are likely to lose when compiled
optimized with GNU CC when the child code alters registers which contain
C variables in the parent.  This affects variables which are live in the
parent across the call to @code{vfork}.

If you encounter this, you can work around the problem by declaring
variables @code{volatile} in the function that calls @code{vfork}, until
the problem goes away, or by not declaring them @code{register} and not
using @samp{-O} for those source files.
@end ignore

@item
On a Sparc, GNU CC aligns all values of type @code{double} on an 8-byte
boundary, and it expects every @code{double} to be so aligned.  The Sun
compiler usually gives @code{double} values 8-byte alignment, with one
exception: function arguments of type @code{double} may not be aligned.

As a result, if a function compiled with Sun CC takes the address of an
argument of type @code{double} and passes this pointer of type
@code{double *} to a function compiled with GNU CC, dereferencing the
pointer may cause a fatal signal.

One way to solve this problem is to compile your entire program with GNU
CC.  Another solution is to modify the function that is compiled with
Sun CC to copy the argument into a local variable; local variables
are always properly aligned.  A third solution is to modify the function
that uses the pointer to dereference it via the following function
@code{access_double} instead of directly with @samp{*}:

@example
inline double
access_double (double *unaligned_ptr)
@{
  union d2i @{ double d; int i[2]; @};

  union d2i *p = (union d2i *) unaligned_ptr;
  union d2i u;

  u.i[0] = p->i[0];
  u.i[1] = p->i[1];

  return u.d;
@}
@end example

@noindent
Storing into the pointer can be done likewise with the same union.

@item
On a Sun, linking using GNU CC fails to find a shared library and
reports that the library doesn't exist at all.

This happens if you are using the GNU linker, because it does only
static linking and looks only for unshared libraries.  If you have a
shared library with no unshared counterpart, the GNU linker won't find
anything.

We hope to make a linker which supports Sun shared libraries, but please
don't ask when it will be finished---we don't know.

@item
Sun forgot to include a static version of @file{libdl.a} with some
versions of SunOS (mainly 4.1).  This results in undefined symbols when
linking static binaries (that is, if you use @samp{-static}).  If you
see undefined symbols @code{_dlclose}, @code{_dlsym} or @code{_dlopen}
when linking, compile and link against the file
@file{mit/util/misc/dlsym.c} from the MIT version of X windows.

@item
On the HP PA machine, ADB sometimes fails to work on functions compiled
with GNU CC.  Specifically, it fails to work on functions that use
@code{alloca} or variable-size arrays.  This is because GNU CC doesn't
generate HP-UX unwind descriptors for such functions.  It may even be
impossible to generate them.

@item 
Debugging (@samp{-g}) is not supported on the HP PA machine, unless you use 
the preliminary GNU tools (@pxref{Installation}).

@item
The HP-UX linker has a bug which can cause programs which make use of
@code{const} variables to fail in unusual ways.  If your program makes
use of global @code{const} variables, we suggest you compile with the
following additional options:

@example
-Dconst="" -D__const="" -D__const__="" -fwritable-strings
@end example

This will force the @code{const} variables into the DATA subspace which 
will avoid the linker bug.

Another option one might use to work around this problem is
@samp{-mkernel}.  @samp{-mkernel} changes how the address of variables
is computed to a sequence less likely to tickle the HP-UX linker bug.

We hope to work around this problem in GNU CC 2.4, if HP does not fix
it.

@item
Taking the address of a label may generate errors from the HP-UX
PA assembler.  GAS for the PA does not have this problem.

@item
GNU CC produced code will not yet link against HP-UX 8.0 shared libraries.
We expect to fix this problem in GNU CC 2.4.  

@item
The current version of the assembler (@file{/bin/as}) for the RS/6000
has certain problems that prevent the @samp{-g} option in GCC from
working.

IBM has produced a fixed version of the assembler.  The replacement
assembler is not a standard component of either AIX 3.1.5 or AIX 3.2,
but is expected to become standard in a future distribution.  This
assembler is available from IBM as APAR IX22829.  Yet more bugs have
been fixed in a newer assembler, which will shortly be available as APAR
IX26107.  See the file @file{README.RS6000} for more details on these
assemblers.

@item
On the IBM RS/6000, compiling code of the form

@example
extern int foo;

@dots{} foo @dots{}

static int foo;
@end example

@noindent
will cause the linker to report an undefined symbol @code{foo}.
Although this behavior differs from most other systems, it is not a
bug because redefining an @code{extern} variable as @code{static}
is undefined in ANSI C.

@item
On VMS, GAS versions 1.38.1 and earlier may cause spurious warning
messages from the linker.  These warning messages complain of mismatched
psect attributes.  You can ignore them.  @xref{VMS Install}.

@item
On NewsOS version 3, if you include both @file{stddef.h} and
@file{sys/types.h}, you get an error because there are two typedefs of
@code{size_t}.  You should change @file{sys/types.h} by adding these
lines around the definition of @code{size_t}:

@example
#ifndef _SIZE_T
#define _SIZE_T
@var{actual typedef here}
#endif
@end example

@cindex Alliant
@item
On the Alliant, the system's own convention for returning structures
and unions is unusual, and is not compatible with GNU CC no matter
what options are used.

@cindex RT PC
@cindex IBM RT PC
@item
On the IBM RT PC, the MetaWare HighC compiler (hc) uses yet another
convention for structure and union returning.  Use
@samp{-mhc-struct-return} to tell GNU CC to use a convention compatible
with it.

@cindex Vax calling convention
@cindex Ultrix calling convention
@item
On Ultrix, the Fortran compiler expects registers 2 through 5 to be saved
by function calls.  However, the C compiler uses conventions compatible
with BSD Unix: registers 2 through 5 may be clobbered by function calls.

GNU CC uses the same convention as the Ultrix C compiler.  You can use
these options to produce code compatible with the Fortran compiler: