gcc.texi

GCC

GNU debugger, GDB, works with this information in the object code to
give you comprehensive C++ source-level editing capabilities
(@pxref{C,,C and C++,gdb.info, Debugging with GDB}).

@c FIXME!  Someone who knows something about Objective C ought to put in
@c a paragraph or two about it here, and move the index entry down when
@c there is more to point to than the general mention in the 1st par.

@node Standards
@chapter Language Standards Supported by GCC
@cindex C standard
@cindex C standards
@cindex ANSI C standard
@cindex ANSI C
@cindex ANSI C89
@cindex C89
@cindex ANSI X3.159-1989
@cindex X3.159-1989
@cindex ISO C standard
@cindex ISO C
@cindex ISO C89
@cindex ISO C90
@cindex ISO/IEC 9899
@cindex ISO 9899
@cindex C90
@cindex ISO C94
@cindex C94
@cindex ISO C95
@cindex C95
@cindex ISO C99
@cindex C99
@cindex ISO C9X
@cindex C9X
@cindex Technical Corrigenda
@cindex TC1
@cindex Technical Corrigendum 1
@cindex TC2
@cindex Technical Corrigendum 2
@cindex AMD1
@cindex freestanding implementation
@cindex freestanding environment
@cindex hosted implementation
@cindex hosted environment
@findex __STDC_HOSTED__

For each language compiled by GCC for which there is a standard, GCC
attempts to follow one or more versions of that standard, possibly
with some exceptions, and possibly with some extensions.

GCC supports three versions of the C standard, although support for
the most recent version is not yet complete.

@opindex std
@opindex ansi
@opindex pedantic
@opindex pedantic-errors
The original ANSI C standard (X3.159-1989) was ratified in 1989 and
published in 1990.  This standard was ratified as an ISO standard
(ISO/IEC 9899:1990) later in 1990.  There were no technical
differences between these publications, although the sections of the
ANSI standard were renumbered and became clauses in the ISO standard.
This standard, in both its forms, is commonly known as @dfn{C89}, or
occasionally as @dfn{C90}, from the dates of ratification.  The ANSI
standard, but not the ISO standard, also came with a Rationale
document.  To select this standard in GCC, use one of the options
@option{-ansi}, @option{-std=c89} or @option{-std=iso9899:1990}; to obtain
all the diagnostics required by the standard, you should also specify
@option{-pedantic} (or @option{-pedantic-errors} if you want them to be
errors rather than warnings).  @xref{C Dialect Options,,Options
Controlling C Dialect}.

Errors in the 1990 ISO C standard were corrected in two Technical
Corrigenda published in 1994 and 1996.  GCC does not support the
uncorrected version.

An amendment to the 1990 standard was published in 1995.  This
amendment added digraphs and @code{__STDC_VERSION__} to the language,
but otherwise concerned the library.  This amendment is commonly known
as @dfn{AMD1}; the amended standard is sometimes known as @dfn{C94} or
@dfn{C95}.  To select this standard in GCC, use the option
@option{-std=iso9899:199409} (with, as for other standard versions,
@option{-pedantic} to receive all required diagnostics).

A new edition of the ISO C standard was published in 1999 as ISO/IEC
9899:1999, and is commonly known as @dfn{C99}.  GCC has incomplete
support for this standard version; see
@uref{http://gcc.gnu.org/gcc-3.0/c99status.html} for details.  To select this
standard, use @option{-std=c99} or @option{-std=iso9899:1999}.  (While in
development, drafts of this standard version were referred to as
@dfn{C9X}.)

@opindex traditional
GCC also has some limited support for traditional (pre-ISO) C with the
@option{-traditional} option.  This support may be of use for compiling
some very old programs that have not been updated to ISO C, but should
not be used for new programs.  It will not work with some modern C
libraries such as the GNU C library.

By default, GCC provides some extensions to the C language that on
rare occasions conflict with the C standard.  @xref{C
Extensions,,Extensions to the C Language Family}.  Use of the
@option{-std} options listed above will disable these extensions where
they conflict with the C standard version selected.  You may also
select an extended version of the C language explicitly with
@option{-std=gnu89} (for C89 with GNU extensions) or @option{-std=gnu99}
(for C99 with GNU extensions).  The default, if no C language dialect
options are given, is @option{-std=gnu89}; this will change to
@option{-std=gnu99} in some future release when the C99 support is
complete.  Some features that are part of the C99 standard are
accepted as extensions in C89 mode.

The ISO C standard defines (in clause 4) two classes of conforming
implementation.  A @dfn{conforming hosted implementation} supports the
whole standard including all the library facilities; a @dfn{conforming
freestanding implementation} is only required to provide certain
library facilities: those in @code{<float.h>}, @code{<limits.h>},
@code{<stdarg.h>}, and @code{<stddef.h>}; since AMD1, also those in
@code{<iso646.h>}; and in C99, also those in @code{<stdbool.h>} and
@code{<stdint.h>}.  In addition, complex types, added in C99, are not
required for freestanding implementations.  The standard also defines
two environments for programs, a @dfn{freestanding environment},
required of all implementations and which may not have library
facilities beyond those required of freestanding implementations,
where the handling of program startup and termination are
implementation-defined, and a @dfn{hosted environment}, which is not
required, in which all the library facilities are provided and startup
is through a function @code{int main (void)} or @code{int main (int,
char *[])}.  An OS kernel would be a freestanding environment; a
program using the facilities of an operating system would normally be
in a hosted implementation.

@opindex ffreestanding
GNU CC aims towards being usable as a conforming freestanding
implementation, or as the compiler for a conforming hosted
implementation.  By default, it will act as the compiler for a hosted
implementation, defining @code{__STDC_HOSTED__} as @code{1} and
presuming that when the names of ISO C functions are used, they have
the semantics defined in the standard.  To make it act as a conforming
freestanding implementation for a freestanding environment, use the
option @option{-ffreestanding}; it will then define
@code{__STDC_HOSTED__} to @code{0} and not make assumptions about the
meanings of function names from the standard library.  To build an OS
kernel, you may well still need to make your own arrangements for
linking and startup.  @xref{C Dialect Options,,Options Controlling C
Dialect}.

GNU CC does not provide the library facilities required only of hosted
implementations, nor yet all the facilities required by C99 of
freestanding implementations; to use the facilities of a hosted
environment, you will need to find them elsewhere (for example, in the
GNU C library).  @xref{Standard Libraries,,Standard Libraries}.

For references to Technical Corrigenda, Rationale documents and
information concerning the history of C that is available online, see
@uref{http://gcc.gnu.org/readings.html}

@c FIXME: details of C++ standard.

There is no formal written standard for Objective-C.  The most
authoritative manual is ``Object-Oriented Programming and the
Objective-C Language'', available at a number of web sites;
@uref{http://developer.apple.com/techpubs/macosx/Cocoa/ObjectiveC/} has a
recent version, while @uref{http://www.toodarkpark.org/computers/objc/}
is an older example.  @uref{http://www.gnustep.org} includes useful
information as well.

@xref{Language,,The GNU Fortran Language, g77, Using and Porting GNU
Fortran}, for details of the Fortran language supported by GCC.

@xref{Compatibility,,Compatibility with the Java Platform, gcj, GNU gcj},
for details of compatibility between @code{gcj} and the Java Platform.

@include invoke.texi

@include install-old.texi

@include extend.texi

@include objc.texi

@include gcov.texi

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

This section describes known problems that affect users of GCC.  Most
of these are not GCC 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.
* Cross-Compiler Problems::   Common problems of cross compiling with GCC.
* Interoperation::      Problems using GCC with other compilers,
			   and with certain linkers, assemblers and debuggers.
* External Bugs::	Problems compiling certain programs.
* Incompatibilities::   GCC is incompatible with traditional C.
* Fixed Headers::       GNU C uses corrected versions of system header files.
                           This is necessary, but doesn't always work smoothly.
* Standard Libraries::  GNU C uses the system C library, which might not be
                           compliant with the ISO C standard.
* Disappointments::     Regrettable things we can't change, but not quite bugs.
* C++ Misunderstandings::     Common misunderstandings with GNU C++.
* Protoize Caveats::    Things to watch out for when using @code{protoize}.
* Non-bugs::		Things we think are right, but some others disagree.
* Warnings and Errors:: Which problems in your code get warnings,
                         and which get errors.
@end menu

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

@itemize @bullet
@item
The @code{fixincludes} script interacts badly with automounters; if the
directory of system header files is automounted, it tends to be
unmounted while @code{fixincludes} is running.  This would seem to be a
bug in the automounter.  We don't know any good way to work around it.

@item
The @code{fixproto} script will sometimes add prototypes for the
@code{sigsetjmp} and @code{siglongjmp} functions that reference the
@code{jmp_buf} type before that type is defined.  To work around this,
edit the offending file and place the typedef in front of the
prototypes.

@item
@opindex pedantic-errors
When @option{-pedantic-errors} is specified, GCC will incorrectly give
an error message when a function name is specified in an expression
involving the comma operator.
@end itemize

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

You may run into problems with cross compilation on certain machines,
for several reasons.

@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.)

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.
@ifset INTERNALS
@xref{Cross-compilation}.
@end ifset
@ifclear INTERNALS
@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
Objective C does not work on the RS/6000.

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

This effect is intentional, to protect you from more subtle problems.
Compilers differ as to many internal details of C++ implementation,
including: how class instances are laid out, how multiple inheritance is
implemented, and how virtual function calls are handled.  If the name
encoding were made the same, your programs would link against libraries
provided from other compilers---but the programs would then crash when
run.  Incompatible libraries are then detected at link time, rather than
at run time.

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

@item
@cindex DBX
DBX rejects some files produced by GCC, 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 @option{-I/usr/include} may cause trouble.

Many systems come with header files that won't work with GCC unless
corrected by @code{fixincludes}.  The corrected header files go in a new
directory; GCC searches this directory before @file{/usr/include}.
If you use @option{-I/usr/include}, this tells GCC 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 (when compiling C programs):