gcc.texi

GCC

(which thus replaces the malloc that comes with the system).  GNU malloc
is available as a separate package, and also in the file
@file{src/gmalloc.c} in the GNU Emacs 19 distribution.

If you have installed GNU malloc as a separate library package, use this
option when you relink GCC:

@example
MALLOC=/usr/local/lib/libgmalloc.a
@end example

Alternatively, if you have compiled @file{gmalloc.c} from Emacs 19, copy
the object file to @file{gmalloc.o} and use this option when you relink
GCC:

@example
MALLOC=gmalloc.o
@end example
@end itemize

@node Incompatibilities
@section Incompatibilities of GCC
@cindex incompatibilities of GCC
@opindex traditional

There are several noteworthy incompatibilities between GNU C and K&R
(non-ISO) versions of C.  The @option{-traditional} option
eliminates many of these incompatibilities, @emph{but not all}, by
telling GNU C to behave like a K&R C compiler.

@itemize @bullet
@cindex string constants
@cindex read-only strings
@cindex shared strings
@item
GCC normally makes string constants read-only.  If several
identical-looking string constants are used, GCC 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}.

@opindex fwritable-strings
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 @option{-fwritable-strings} flag, which directs GCC
to handle string constants the same way most C compilers do.
@option{-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 ISO C rules) its data type is @code{unsigned long int}.
Negating this value yields 2147483648 again.

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

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

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

The @option{-traditional} option directs GCC to handle such cases
(among others) in the old-fashioned (non-ISO) 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.

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

The @option{-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 preprocessing directives in the middle of macro
arguments do not work with GCC.  For example, a program like this
will not work:

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

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

@item
K&R compilers allow comments to cross over an inclusion boundary (i.e.
started in an include file and ended in the including file).  I think
this would be quite ugly and can't imagine it could be needed.

@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 @option{-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 ISO 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 @option{-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.

@item
When in @option{-traditional} mode, GCC allows the following erroneous
pair of declarations to appear together in a given scope:

@example
typedef int foo;
typedef foo foo;
@end example

@item
GCC treats all characters of identifiers as significant, even when in
@option{-traditional} mode.  According to K&R-1 (2.2), ``No more than the
first eight characters are significant, although more may be used.''.
Also according to K&R-1 (2.2), ``An identifier is a sequence of letters
and digits; the first character must be a letter.  The underscore _
counts as a letter.'', but GCC also allows dollar signs in identifiers.

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

@cindex apostrophes
@cindex '
@item
GCC complains about unterminated character constants inside of
preprocessing conditionals that fail.  Some programs have English
comments enclosed in conditionals that are guaranteed to fail; if these
comments contain apostrophes, GCC 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,
@option{-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 ISO 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 appropriate system headers
(@code{<time.h>} on systems with ISO C headers) and not to declare
@code{time} if the system header files declare it, or failing that 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.  GCC 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, GCC
output code normally uses a method different from that used on most
versions of Unix.  As a result, code compiled with GCC cannot call
a structure-returning function compiled with PCC, and vice versa.

The method used by GCC 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 GCC 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.  GCC 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.  GCC 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.

@opindex fpcc-struct-return
You can tell GCC to use a compatible convention for all structure and
union returning with the option @option{-fpcc-struct-return}.

@cindex preprocessing tokens
@cindex preprocessing numbers
@item
GNU C complains about program fragments such as @samp{0x74ae-0x4000}
which appear to be two hexadecimal constants separated by the minus
operator.  Actually, this string is a single @dfn{preprocessing token}.
Each such token must correspond to one token in C.  Since this does not,
GNU C prints an error message.  Although it may appear obvious that what
is meant is an operator and two values, the ISO C standard specifically
requires that this be treated as erroneous.

A @dfn{preprocessing token} is a @dfn{preprocessing number} if it
begins with a digit and is followed by letters, underscores, digits,
periods and @samp{e+}, @samp{e-}, @samp{E+}, @samp{E-}, @samp{p+},
@samp{p-}, @samp{P+}, or @samp{P-} character sequences.  (In strict C89
mode, the sequences @samp{p+}, @samp{p-}, @samp{P+} and @samp{P-} cannot
appear in preprocessing numbers.)

To make the above program fragment valid, place whitespace in front of
the minus sign.  This whitespace will end the preprocessing number.
@end itemize

@node Fixed Headers
@section Fixed Header Files

GCC needs to install corrected versions of some system header files.
This is because most target systems have some header files that won't
work with GCC unless they are changed.  Some have bugs, some are
incompatible with ISO C, and some depend on special features of other
compilers.

Installing GCC automatically creates and installs the fixed header
files, by running a program called @code{fixincludes} (or for certain
targets an alternative such as @code{fixinc.svr4}).  Normally, you
don't need to pay attention to this.  But there are cases where it
doesn't do the right thing automatically.

@itemize @bullet
@item
If you update the system's header files, such as by installing a new
system version, the fixed header files of GCC are not automatically
updated.  The easiest way to update them is to reinstall GCC.  (If
you want to be clever, look in the makefile and you can find a
shortcut.)

@item
On some systems, in particular SunOS 4, header file directories contain
machine-specific symbolic links in certain places.  This makes it
possible to share most of the header files among hosts running the
same version of SunOS 4 on different machine models.

The programs that fix the header files do not understand this special
way of using symbolic links; therefore, the directory of fixed header
files is good only for the machine model used to build it.

In SunOS 4, only programs that look inside the kernel will notice the
difference between machine models.  Therefore, for most purposes, you
need not be concerned about this.

It is possible to make separate sets of fixed header files for the
different machine models, and arrange a structure of symbolic links so
as to use the proper set, but you'll have to do this by hand.

@item
On Lynxos, GCC by default does not fix the header files.  This is
because bugs in the shell cause the @code{fixincludes} script to fail.

This means you will encounter problems due to bugs in the system header
files.  It may be no comfort that they aren't GCC's fault, but it