gcc.texi

早期freebsd实现

@smallexample
-fcall-saved-r2 -fcall-saved-r3 -fcall-saved-r4 -fcall-saved-r5
@end smallexample

@item
On the WE32k, you may find that programs compiled with GNU CC do not
work with the standard shared C ilbrary.  You may need to link with
the ordinary C compiler.  If you do so, you must specify the following
options:

@smallexample
-L/usr/local/lib/gcc-lib/we32k-att-sysv/2.3 -lgcc -lc_s
@end smallexample

The first specifies where to find the library @file{libgcc.a}
specified with the @samp{-lgcc} option.

GNU CC does linking by invoking @code{ld}, just as @code{cc} does, and
there is no reason why it @emph{should} matter which compilation program
you use to invoke @code{ld}.  If someone tracks this problem down,
it can probably be fixed easily.
@end itemize

@node Incompatibilities
@section Incompatibilities of GNU CC
@cindex incompatibilities of GNU CC

There are several noteworthy incompatibilities between GNU C and most
existing (non-ANSI) versions of C.  The @samp{-traditional} option
eliminates many of these incompatibilities, @emph{but not all}, by
telling GNU C to behave like the other C compilers.

@itemize @bullet
@cindex string constants
@cindex read-only strings
@cindex shared strings
@item
GNU CC normally makes string constants read-only.  If several
identical-looking string constants are used, GNU CC stores only one
copy of the string.

@cindex @code{mktemp}, and constant strings
One consequence is that you cannot call @code{mktemp} with a string
constant argument.  The function @code{mktemp} always alters the
string its argument points to.

@cindex @code{sscanf}, and constant strings
@cindex @code{fscanf}, and constant strings
@cindex @code{scanf}, and constant strings
Another consequence is that @code{sscanf} does not work on some systems
when passed a string constant as its format control string or input.
This is because @code{sscanf} incorrectly tries to write into the string
constant.  Likewise @code{fscanf} and @code{scanf}.

The best solution to these problems is to change the program to use
@code{char}-array variables with initialization strings for these
purposes instead of string constants.  But if this is not possible,
you can use the @samp{-fwritable-strings} flag, which directs GNU CC
to handle string constants the same way most C compilers do.
@samp{-traditional} also has this effect, among others.

@item
@code{-2147483648} is positive.

This is because 2147483648 cannot fit in the type @code{int}, so
(following the ANSI C rules) its data type is @code{unsigned long int}.
Negating this value yields 2147483648 again.

@item
GNU CC does not substitute macro arguments when they appear inside of
string constants.  For example, the following macro in GNU CC

@example
#define foo(a) "a"
@end example

@noindent
will produce output @code{"a"} regardless of what the argument @var{a} is.

The @samp{-traditional} option directs GNU CC to handle such cases
(among others) in the old-fashioned (non-ANSI) fashion.

@cindex @code{setjmp} incompatibilities
@cindex @code{longjmp} incompatibilities
@item
When you use @code{setjmp} and @code{longjmp}, the only automatic
variables guaranteed to remain valid are those declared
@code{volatile}.  This is a consequence of automatic register
allocation.  Consider this function:

@example
jmp_buf j;

foo ()
@{
  int a, b;

  a = fun1 ();
  if (setjmp (j))
    return a;

  a = fun2 ();
  /* @r{@code{longjmp (j)} may occur in @code{fun3}.} */
  return a + fun3 ();
@}
@end example

Here @code{a} may or may not be restored to its first value when the
@code{longjmp} occurs.  If @code{a} is allocated in a register, then
its first value is restored; otherwise, it keeps the last value stored
in it.

If you use the @samp{-W} option with the @samp{-O} option, you will
get a warning when GNU CC thinks such a problem might be possible.

The @samp{-traditional} option directs GNU C to put variables in
the stack by default, rather than in registers, in functions that
call @code{setjmp}.  This results in the behavior found in
traditional C compilers.

@item
Programs that use preprocessor directives in the middle of macro
arguments do not work with GNU CC.  For example, a program like this
will not work:

@example
foobar (
#define luser
        hack)
@end example

ANSI C does not permit such a construct.  It would make sense to support
it when @samp{-traditional} is used, but it is too much work to
implement.

@cindex external declaration scope
@cindex scope of external declarations
@cindex declaration scope
@item
Declarations of external variables and functions within a block apply
only to the block containing the declaration.  In other words, they
have the same scope as any other declaration in the same place.

In some other C compilers, a @code{extern} declaration affects all the
rest of the file even if it happens within a block.

The @samp{-traditional} option directs GNU C to treat all @code{extern}
declarations as global, like traditional compilers.

@item
In traditional C, you can combine @code{long}, etc., with a typedef name,
as shown here:

@example
typedef int foo;
typedef long foo bar;
@end example

In ANSI C, this is not allowed: @code{long} and other type modifiers
require an explicit @code{int}.  Because this criterion is expressed
by Bison grammar rules rather than C code, the @samp{-traditional}
flag cannot alter it.

@cindex typedef names as function parameters
@item
PCC allows typedef names to be used as function parameters.  The
difficulty described immediately above applies here too.

@cindex whitespace
@item
PCC allows whitespace in the middle of compound assignment operators
such as @samp{+=}.  GNU CC, following the ANSI standard, does not
allow this.  The difficulty described immediately above applies here
too.

@cindex apostrophes
@cindex '
@item
GNU CC complains about unterminated character constants inside of
preprocessor conditionals that fail.  Some programs have English
comments enclosed in conditionals that are guaranteed to fail; if these
comments contain apostrophes, GNU CC will probably report an error.  For
example, this code would produce an error:

@example
#if 0
You can't expect this to work.
#endif
@end example

The best solution to such a problem is to put the text into an actual
C comment delimited by @samp{/*@dots{}*/}.  However,
@samp{-traditional} suppresses these error messages.

@item
Many user programs contain the declaration @samp{long time ();}.  In the
past, the system header files on many systems did not actually declare
@code{time}, so it did not matter what type your program declared it to
return.  But in systems with ANSI C headers, @code{time} is declared to
return @code{time_t}, and if that is not the same as @code{long}, then
@samp{long time ();} is erroneous.

The solution is to change your program to use @code{time_t} as the return
type of @code{time}.

@cindex @code{float} as function value type
@item
When compiling functions that return @code{float}, PCC converts it to
a double.  GNU CC actually returns a @code{float}.  If you are concerned
with PCC compatibility, you should declare your functions to return
@code{double}; you might as well say what you mean.

@cindex structures
@cindex unions
@item
When compiling functions that return structures or unions, GNU CC
output code normally uses a method different from that used on most
versions of Unix.  As a result, code compiled with GNU CC cannot call
a structure-returning function compiled with PCC, and vice versa.

The method used by GNU CC is as follows: a structure or union which is
1, 2, 4 or 8 bytes long is returned like a scalar.  A structure or union
with any other size is stored into an address supplied by the caller
(usually in a special, fixed register, but on some machines it is passed
on the stack).  The machine-description macros @code{STRUCT_VALUE} and
@code{STRUCT_INCOMING_VALUE} tell GNU CC where to pass this address.

By contrast, PCC on most target machines returns structures and unions
of any size by copying the data into an area of static storage, and then
returning the address of that storage as if it were a pointer value.
The caller must copy the data from that memory area to the place where
the value is wanted.  GNU CC does not use this method because it is
slower and nonreentrant.

On some newer machines, PCC uses a reentrant convention for all
structure and union returning.  GNU CC on most of these machines uses a
compatible convention when returning structures and unions in memory,
but still returns small structures and unions in registers.

You can tell GNU CC to use a compatible convention for all structure and
union returning with the option @samp{-fpcc-struct-return}.
@end itemize

@node Disappointments
@section Disappointments and Misunderstandings

These problems are perhaps regrettable, but we don't know any practical
way around them.

@itemize @bullet
@item
Certain local variables aren't recognized by debuggers when you compile
with optimization.

This occurs because sometimes GNU CC optimizes the variable out of
existence.  There is no way to tell the debugger how to compute the
value such a variable ``would have had'', and it is not clear that would
be desirable anyway.  So GNU CC simply does not mention the eliminated
variable when it writes debugging information.

You have to expect a certain amount of disagreement between the
executable and your source code, when you use optimization.

@cindex conflicting types
@cindex scope of declaration
@item
Users often think it is a bug when GNU CC reports an error for code
like this:

@example
int foo (struct mumble *);

struct mumble @{ @dots{} @};

int foo (struct mumble *x)
@{ @dots{} @}
@end example

This code really is erroneous, because the scope of @code{struct
mumble} in the prototype is limited to the argument list containing it.
It does not refer to the @code{struct mumble} defined with file scope
immediately below---they are two unrelated types with similar names in
different scopes.

But in the definition of @code{foo}, the file-scope type is used
because that is available to be inherited.  Thus, the definition and
the prototype do not match, and you get an error.

This behavior may seem silly, but it's what the ANSI standard specifies.
It is easy enough for you to make your code work by moving the
definition of @code{struct mumble} above the prototype.  It's not worth
being incompatible with ANSI C just to avoid an error for the example
shown above.

@item
Accesses to bitfields even in volatile objects works by accessing larger
objects, such as a byte or a word.  You cannot rely on what size of
object is accessed in order to read or write the bitfield; it may even
vary for a given bitfield according to the precise usage.

If you care about controlling the amount of memory that is accessed, use
volatile but do not use bitfields.

@item
On 68000 systems, you can get paradoxical results if you test the
precise values of floating point numbers.  For example, you can find
that a floating point value which is not a NaN is not equal to itself.
This results from the fact that the the floating point registers hold a
few more bits of precision than fit in a @code{double} in memory.
Compiled code moves values between memory and floating point registers
at its convenience, and moving them into memory truncates them.

You can partially avoid this problem by using the option
@samp{-ffloat-store} (@pxref{Optimize Options}).

@item
On the MIPS, variable argument functions using @file{varargs.h}
cannot have a floating point value for the first argument.  The
reason for this is that in the absence of a prototype in scope,
if the first argument is a floating point, it is passed in a
floating point register, rather than an integer resgister.

If the code is rewritten to use the ANSI standard @file{stdarg.h}
method of variable arguments, and the prototype is in scope at
the time of the call, everything will work fine.
@end itemize

@node Protoize Caveats
@section Caveats of using @code{protoize}

The conversion programs @code{protoize} and @code{unprotoize} can
sometimes change a source file in a way that won't work unless you
rearrange it.

@itemize @bullet
@item
@code{protoize} can insert references to a type name or type tag before
the definition, or in a fi