@c Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
-@c 1999, 2000, 2001 Free Software Foundation, Inc.
+@c 1999, 2000, 2001, 2003, 2004, 2005, 2006, 2007, 2008
+@c Free Software Foundation, Inc.
@c This is part of the GCC manual.
@c For copying conditions, see the file gcc.texi.
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.
+* 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.
+ and with certain linkers, assemblers and debuggers.
* Incompatibilities:: GCC is incompatible with traditional C.
* Fixed Headers:: GCC uses corrected versions of system header files.
- This is necessary, but doesn't always work smoothly.
+ This is necessary, but doesn't always work smoothly.
* Standard Libraries:: GCC uses the system C library, which might not be
- compliant with the ISO C standard.
+ compliant with the ISO C standard.
* Disappointments:: Regrettable things we can't change, but not quite bugs.
-* C++ Misunderstandings:: Common misunderstandings with GNU C++.
+* 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.
+* 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.
+ and which get errors.
@end menu
@node Actual Bugs
@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
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.
-@xref{Cross-compilation,,Cross Compilation and Floating Point,
-gccint, GNU Compiler Collection (GCC) Internals}.
-
@item
At present, the program @file{mips-tfile} which adds debug
support to object files on MIPS systems does not work in a cross
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.
-@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 GCC 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 @option{-O} for those source files.
-@end ignore
-
@item
On some SGI systems, when you use @option{-lgl_s} as an option,
it gets translated magically to @samp{-lgl_s -lX11_s -lc_s}.
You must specify all three options explicitly.
@item
-On a Sparc, GCC aligns all values of type @code{double} on an 8-byte
+On a SPARC, GCC 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.
@item
On Solaris, the @code{malloc} function in the @file{libmalloc.a} library
may allocate memory that is only 4 byte aligned. Since GCC on the
-Sparc assumes that doubles are 8 byte aligned, this may result in a
+SPARC assumes that doubles are 8 byte aligned, this may result in a
fatal signal if doubles are stored in memory allocated by the
@file{libmalloc.a} library.
@code{malloc} and related functions from @file{libc.a}; they do not have
this problem.
-@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 @option{-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
-The 128-bit long double format that the Sparc port supports currently
-works by using the architecturally defined quad-word floating point
-instructions. Since there is no hardware that supports these
-instructions they must be emulated by the operating system. Long
-doubles do not work in Sun OS versions 4.0.3 and earlier, because the
-kernel emulator uses an obsolete and incompatible format. Long doubles
-do not work in Sun OS version 4.1.1 due to a problem in a Sun library.
-Long doubles do work on Sun OS versions 4.1.2 and higher, but GCC
-does not enable them by default. Long doubles appear to work in Sun OS
-5.x (Solaris 2.x).
-
-@item
-On HP-UX version 9.01 on the HP PA, the HP compiler @code{cc} does not
-compile GCC correctly. We do not yet know why. However, GCC
-compiled on earlier HP-UX versions works properly on HP-UX 9.01 and can
-compile itself properly on 9.01.
-
@item
On the HP PA machine, ADB sometimes fails to work on functions compiled
with GCC@. Specifically, it fails to work on functions that use
These warnings are harmless and can be safely ignored.
-@item
-On the IBM RS/6000, compiling code of the form
-
-@smallexample
-extern int foo;
-
-@dots{} foo @dots{}
-
-static int foo;
-@end smallexample
-
-@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 ISO C@.
-
@item
In extremely rare cases involving some very large functions you may
receive errors from the AIX Assembler complaining about a displacement
@option{-Wl,-brtl} flag on the link line. G++ cannot impose this
because this option may interfere with the semantics of the user
program and users may not always use @samp{g++} to link his or her
-application. Applications are not required to use the
+application. Applications are not required to use the
@option{-Wl,-brtl} flag on the link line---the rest of the
@file{libstdc++.a} library which is not dependent on the symbol
merging semantics will continue to function correctly.
@item
An application can interpose its own definition of functions for
functions invoked by @file{libstdc++.a} with ``runtime-linking''
-enabled on AIX. To accomplish this the application must be linked
+enabled on AIX@. To accomplish this the application must be linked
with ``runtime-linking'' option and the functions explicitly must be
exported by the application (@option{-Wl,-brtl,-bE:exportfile}).
the United States. Compilers and assemblers use NLS to support
locale-specific representations of various objects including
floating-point numbers (@samp{.} vs @samp{,} for separating decimal
-fractions). There have been problems reported where the library linked
+fractions). There have been problems reported where the library linked
with GCC does not produce the same floating-point formats that the
-assembler accepts. If you have this problem, set the @env{LANG}
+assembler accepts. If you have this problem, set the @env{LANG}
environment variable to @samp{C} or @samp{En_US}.
@item
to a restriction in the IBM assembler. GAS supports these
identifiers.
-@item
-@opindex mno-serialize-volatile
-There is an assembler bug in versions of DG/UX prior to 5.4.2.01 that
-occurs when the @samp{fldcr} instruction is used. GCC uses
-@samp{fldcr} on the 88100 to serialize volatile memory references. Use
-the option @option{-mno-serialize-volatile} if your version of the
-assembler has this bug.
-
-@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.
-
-@item
-On NewsOS version 3, if you include both of the files @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}:
-
-@smallexample
-#ifndef _SIZE_T
-#define _SIZE_T
-@var{actual-typedef-here}
-#endif
-@end smallexample
-
-@cindex Alliant
-@item
-On the Alliant, the system's own convention for returning structures
-and unions is unusual, and is not compatible with GCC no matter
-what options are used.
-
-@cindex RT PC
-@cindex IBM RT PC
-@item
-@opindex mhc-struct-return
-On the IBM RT PC, the MetaWare HighC compiler (hc) uses a different
-convention for structure and union returning. Use the option
-@option{-mhc-struct-return} to tell GCC to use a convention compatible
-with it.
-
-@cindex VAX calling convention
-@cindex Ultrix calling convention
-@item
-@opindex fcall-saved
-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.
-
-GCC uses the same convention as the Ultrix C compiler. You can use
-these options to produce code compatible with the Fortran compiler:
-
-@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 GCC do not
-work with the standard shared C library. 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.8.1 -lgcc -lc_s
-@end smallexample
-
-The first specifies where to find the library @file{libgcc.a}
-specified with the @option{-lgcc} option.
-
-GCC does linking by invoking @command{ld}, just as @command{cc} does, and
-there is no reason why it @emph{should} matter which compilation program
-you use to invoke @command{ld}. If someone tracks this problem down,
-it can probably be fixed easily.
-
-@item
-On the Alpha, you may get assembler errors about invalid syntax as a
-result of floating point constants. This is due to a bug in the C
-library functions @code{ecvt}, @code{fcvt} and @code{gcvt}. Given valid
-floating point numbers, they sometimes print @samp{NaN}.
-
-@item
-On Irix 4.0.5F (and perhaps in some other versions), an assembler bug
-sometimes reorders instructions incorrectly when optimization is turned
-on. If you think this may be happening to you, try using the GNU
-assembler; GAS version 2.1 supports ECOFF on Irix.
-
-@opindex noasmopt
-Or use the @option{-noasmopt} option when you compile GCC with itself,
-and then again when you compile your program. (This is a temporary
-kludge to turn off assembler optimization on Irix.) If this proves to
-be what you need, edit the assembler spec in the file @file{specs} so
-that it unconditionally passes @option{-O0} to the assembler, and never
-passes @option{-O2} or @option{-O3}.
-@end itemize
-
-@node External Bugs
-@section Problems Compiling Certain Programs
-
-@c prevent bad page break with this line
-Certain programs have problems compiling.
-
-@itemize @bullet
-@item
-Parse errors may occur compiling X11 on a Decstation running Ultrix 4.2
-because of problems in DEC's versions of the X11 header files
-@file{X11/Xlib.h} and @file{X11/Xutil.h}. People recommend adding
-@option{-I/usr/include/mit} to use the MIT versions of the header files,
-using the @option{-traditional} switch to turn off ISO C, or fixing the
-header files by adding this:
-
-@example
-#ifdef __STDC__
-#define NeedFunctionPrototypes 0
-#endif
-@end example
-
-@item
-On various 386 Unix systems derived from System V, including SCO, ISC,
-and ESIX, you may get error messages about running out of virtual memory
-while compiling certain programs.
-
-You can prevent this problem by linking GCC with the GNU malloc
-(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
@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 GCC to behave like a K&R C compiler.
+(non-ISO) versions of C@.
@itemize @bullet
@cindex string constants
@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}.
+Another consequence is that @code{sscanf} does not work on some very
+old 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
+The 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.
+purposes instead of string constants.
@item
@code{-2147483648} is positive.
GCC does not substitute macro arguments when they appear inside of
string constants. For example, the following macro in GCC
-@example
+@smallexample
#define foo(a) "a"
-@end example
+@end smallexample
@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
@code{volatile}. This is a consequence of automatic register
allocation. Consider this function:
-@example
+@smallexample
jmp_buf j;
foo ()
/* @r{@code{longjmp (j)} may occur in @code{fun3}.} */
return a + fun3 ();
@}
-@end example
+@end smallexample
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
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 GCC 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
+@smallexample
@group
foobar (
#define luser
hack)
@end group
-@end example
+@end smallexample
-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.
+ISO C does not permit such a construct.
@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.
+(i.e.@: started in an include file and ended in the including file).
@cindex external declaration scope
@cindex scope of external declarations
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 GCC 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
+@smallexample
typedef int foo;
typedef long foo bar;
-@end example
+@end smallexample
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.
+require an explicit @code{int}.
@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.
+PCC allows typedef names to be used as function parameters.
@item
-When in @option{-traditional} mode, GCC allows the following erroneous
-pair of declarations to appear together in a given scope:
+Traditional C allows the following erroneous pair of declarations to
+appear together in a given scope:
-@example
+@smallexample
typedef int foo;
typedef foo foo;
-@end example
+@end smallexample
@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.
+GCC treats all characters of identifiers as significant. 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.
+allow this.
@cindex apostrophes
@cindex '
comments contain apostrophes, GCC will probably report an error. For
example, this code would produce an error:
-@example
+@smallexample
#if 0
You can't expect this to work.
#endif
-@end example
+@end smallexample
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.
+C comment delimited by @samp{/*@dots{}*/}.
@item
Many user programs contain the declaration @samp{long time ();}. In the
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.
+on the stack). The target hook @code{TARGET_STRUCT_VALUE_RTX}
+tells 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
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
+files, by running a program called @code{fixincludes}. Normally, you
don't need to pay attention to this. But there are cases where it
doesn't do the right thing automatically.
@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.)
+updated. They can be updated using the @command{mkheaders} script
+installed in
+@file{@var{libexecdir}/gcc/@var{target}/@var{version}/install-tools/}.
@item
-On some systems, in particular SunOS 4, header file directories contain
+On some systems, 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.
+same version of the system 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
-does mean that there's nothing for us to do about them.
@end itemize
@node Standard Libraries
Users often think it is a bug when GCC reports an error for code
like this:
-@example
+@smallexample
int foo (struct mumble *);
struct mumble @{ @dots{} @};
int foo (struct mumble *x)
@{ @dots{} @}
-@end example
+@end smallexample
This code really is erroneous, because the scope of @code{struct
mumble} in the prototype is limited to the argument list containing it.
files for the problem cases that we know about.
If new system header files are installed, nothing automatically arranges
-to update the corrected header files. You will have to reinstall GCC
-to fix the new header files. More specifically, go to the build
-directory and delete the files @file{stmp-fixinc} and
-@file{stmp-headers}, and the subdirectory @code{include}; then do
-@samp{make install} again.
+to update the corrected header files. They can be updated using the
+@command{mkheaders} script installed in
+@file{@var{libexecdir}/gcc/@var{target}/@var{version}/install-tools/}.
@item
@cindex floating point precision
You can partially avoid this problem by using the @option{-ffloat-store}
option (@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 register.
-
-If the code is rewritten to use the ISO standard @file{stdarg.h}
-method of variable arguments, and the prototype is in scope at
-the time of the call, everything will work fine.
-
-@item
-On the H8/300 and H8/300H, variable argument functions must be
-implemented using the ISO standard @file{stdarg.h} method of
-variable arguments. Furthermore, calls to functions using @file{stdarg.h}
-variable arguments must have a prototype for the called function
-in scope at the time of the call.
-
@item
On AIX and other platforms without weak symbol support, templates
need to be instantiated explicitly and symbols for static members
of templates will not be generated.
+
+@item
+On AIX, GCC scans object files and library archives for static
+constructors and destructors when linking an application before the
+linker prunes unreferenced symbols. This is necessary to prevent the
+AIX linker from mistakenly assuming that static constructor or
+destructor are unused and removing them before the scanning can occur.
+All static constructors and destructors found will be referenced even
+though the modules in which they occur may not be used by the program.
+This may lead to both increased executable size and unexpected symbol
+references.
@end itemize
@node C++ Misunderstandings
@menu
* Static Definitions:: Static member declarations are not definitions
+* Name lookup:: Name lookup, templates, and accessing members of base classes
* Temporaries:: Temporaries may vanish before you expect
* Copy Assignment:: Copy Assignment operators copy virtual bases twice
@end menu
When a class has static data members, it is not enough to @emph{declare}
the static member; you must also @emph{define} it. For example:
-@example
+@smallexample
class Foo
@{
@dots{}
void method();
static int bar;
@};
-@end example
+@end smallexample
This declaration only establishes that the class @code{Foo} has an
@code{int} named @code{Foo::bar}, and a member function named
standard, you must supply an initializer in one (and only one) source
file, such as:
-@example
+@smallexample
int Foo::bar = 0;
-@end example
+@end smallexample
Other C++ compilers may not correctly implement the standard behavior.
-As a result, when you switch to @code{g++} from one of these compilers,
+As a result, when you switch to @command{g++} from one of these compilers,
you may discover that a program that appeared to work correctly in fact
-does not conform to the standard: @code{g++} reports as undefined
+does not conform to the standard: @command{g++} reports as undefined
symbols any static data members that lack definitions.
+
+@node Name lookup
+@subsection Name lookup, templates, and accessing members of base classes
+
+@cindex base class members
+@cindex two-stage name lookup
+@cindex dependent name lookup
+
+The C++ standard prescribes that all names that are not dependent on
+template parameters are bound to their present definitions when parsing
+a template function or class.@footnote{The C++ standard just uses the
+term ``dependent'' for names that depend on the type or value of
+template parameters. This shorter term will also be used in the rest of
+this section.} Only names that are dependent are looked up at the point
+of instantiation. For example, consider
+
+@smallexample
+ void foo(double);
+
+ struct A @{
+ template <typename T>
+ void f () @{
+ foo (1); // @r{1}
+ int i = N; // @r{2}
+ T t;
+ t.bar(); // @r{3}
+ foo (t); // @r{4}
+ @}
+
+ static const int N;
+ @};
+@end smallexample
+
+Here, the names @code{foo} and @code{N} appear in a context that does
+not depend on the type of @code{T}. The compiler will thus require that
+they are defined in the context of use in the template, not only before
+the point of instantiation, and will here use @code{::foo(double)} and
+@code{A::N}, respectively. In particular, it will convert the integer
+value to a @code{double} when passing it to @code{::foo(double)}.
+
+Conversely, @code{bar} and the call to @code{foo} in the fourth marked
+line are used in contexts that do depend on the type of @code{T}, so
+they are only looked up at the point of instantiation, and you can
+provide declarations for them after declaring the template, but before
+instantiating it. In particular, if you instantiate @code{A::f<int>},
+the last line will call an overloaded @code{::foo(int)} if one was
+provided, even if after the declaration of @code{struct A}.
+
+This distinction between lookup of dependent and non-dependent names is
+called two-stage (or dependent) name lookup. G++ implements it
+since version 3.4.
+
+Two-stage name lookup sometimes leads to situations with behavior
+different from non-template codes. The most common is probably this:
+
+@smallexample
+ template <typename T> struct Base @{
+ int i;
+ @};
+
+ template <typename T> struct Derived : public Base<T> @{
+ int get_i() @{ return i; @}
+ @};
+@end smallexample
+
+In @code{get_i()}, @code{i} is not used in a dependent context, so the
+compiler will look for a name declared at the enclosing namespace scope
+(which is the global scope here). It will not look into the base class,
+since that is dependent and you may declare specializations of
+@code{Base} even after declaring @code{Derived}, so the compiler can't
+really know what @code{i} would refer to. If there is no global
+variable @code{i}, then you will get an error message.
+
+In order to make it clear that you want the member of the base class,
+you need to defer lookup until instantiation time, at which the base
+class is known. For this, you need to access @code{i} in a dependent
+context, by either using @code{this->i} (remember that @code{this} is of
+type @code{Derived<T>*}, so is obviously dependent), or using
+@code{Base<T>::i}. Alternatively, @code{Base<T>::i} might be brought
+into scope by a @code{using}-declaration.
+
+Another, similar example involves calling member functions of a base
+class:
+
+@smallexample
+ template <typename T> struct Base @{
+ int f();
+ @};
+
+ template <typename T> struct Derived : Base<T> @{
+ int g() @{ return f(); @};
+ @};
+@end smallexample
+
+Again, the call to @code{f()} is not dependent on template arguments
+(there are no arguments that depend on the type @code{T}, and it is also
+not otherwise specified that the call should be in a dependent context).
+Thus a global declaration of such a function must be available, since
+the one in the base class is not visible until instantiation time. The
+compiler will consequently produce the following error message:
+
+@smallexample
+ x.cc: In member function `int Derived<T>::g()':
+ x.cc:6: error: there are no arguments to `f' that depend on a template
+ parameter, so a declaration of `f' must be available
+ x.cc:6: error: (if you use `-fpermissive', G++ will accept your code, but
+ allowing the use of an undeclared name is deprecated)
+@end smallexample
+
+To make the code valid either use @code{this->f()}, or
+@code{Base<T>::f()}. Using the @option{-fpermissive} flag will also let
+the compiler accept the code, by marking all function calls for which no
+declaration is visible at the time of definition of the template for
+later lookup at instantiation time, as if it were a dependent call.
+We do not recommend using @option{-fpermissive} to work around invalid
+code, and it will also only catch cases where functions in base classes
+are called, not where variables in base classes are used (as in the
+example above).
+
+Note that some compilers (including G++ versions prior to 3.4) get these
+examples wrong and accept above code without an error. Those compilers
+do not implement two-stage name lookup correctly.
+
+
@node Temporaries
@subsection Temporaries May Vanish Before You Expect
@code{string} objects, and another function @code{charfunc} that
operates on pointers to @code{char}:
-@example
+@smallexample
string strfunc ();
void charfunc (const char *);
@dots{}
charfunc (p);
@}
-@end example
+@end smallexample
@noindent
In this situation, it may seem reasonable to save a pointer to the C
forces it to remain until the end of the scope of the name. For
example:
-@example
-string& tmp = strfunc ();
+@smallexample
+const string& tmp = strfunc ();
charfunc (tmp.c_str ());
-@end example
+@end smallexample
@node Copy Assignment
@subsection Implicit Copy-Assignment for Virtual Bases
invoked only once, and called from the most-derived class. However, such
objects behave unspecified when being assigned. For example:
-@example
+@smallexample
struct Base@{
char *name;
Base(char *n) : name(strdup(n))@{@}
@{
d1 = d2;
@}
-@end example
+@end smallexample
The C++ standard specifies that @samp{Base::Base} is only called once
when constructing or copy-constructing a Derived object. It is
the implicit copy-assignment for Derived objects is invoked (as it is
inside @samp{func} in the example).
-g++ implements the ``intuitive'' algorithm for copy-assignment: assign all
+G++ implements the ``intuitive'' algorithm for copy-assignment: assign all
direct bases, then assign all members. In that algorithm, the virtual
-base subobject can be encountered many times. In the example, copying
+base subobject can be encountered more than once. In the example, copying
proceeds in the following order: @samp{val}, @samp{name} (via
@code{strdup}), @samp{bval}, and @samp{name} again.
the program worked before without any prototypes, it will work again
without them.
-@opindex Wconversion
+@opindex Wtraditional-conversion
You can find all the places where this problem might occur by compiling
-the program with the @option{-Wconversion} option. It prints a warning
-whenever an argument is converted.
+the program with the @option{-Wtraditional-conversion} option. It
+prints a warning whenever an argument is converted.
@item
Both conversion programs can be confused if there are macro calls in and
@item
Warning when a non-void function value is ignored.
-Coming as I do from a Lisp background, I balk at the idea that there is
-something dangerous about discarding a value. There are functions that
-return values which some callers may find useful; it makes no sense to
-clutter the program with a cast to @code{void} whenever the value isn't
-useful.
+C contains many standard functions that return a value that most
+programs choose to ignore. One obvious example is @code{printf}.
+Warning about this practice only leads the defensive programmer to
+clutter programs with dozens of casts to @code{void}. Such casts are
+required so frequently that they become visual noise. Writing those
+casts becomes so automatic that they no longer convey useful
+information about the intentions of the programmer. For functions
+where the return value should never be ignored, use the
+@code{warn_unused_result} function attribute (@pxref{Function
+Attributes}).
@item
@opindex fshort-enums
@item
@opindex ansi
-@opindex traditional
@opindex std
Undefining @code{__STDC__} when @option{-ansi} is not used.
-Currently, GCC defines @code{__STDC__} as long as you don't use
-@option{-traditional}. This provides good results in practice.
+Currently, GCC defines @code{__STDC__} unconditionally. This provides
+good results in practice.
Programmers normally use conditionals on @code{__STDC__} to ask whether
it is safe to use certain features of ISO C, such as function
faster.
However, the rationale here is that optimization of a nonempty loop
-cannot produce an empty one, which holds for C but is not always the
-case for C++.
+cannot produce an empty one. This held for carefully written C compiled
+with less powerful optimizers but is not always the case for carefully
+written C++ or with more powerful optimizers.
+Thus GCC will remove operations from loops whenever it can determine
+those operations are not externally visible (apart from the time taken
+to execute them, of course). In case the loop can be proved to be finite,
+GCC will also remove the loop itself.
+
+Be aware of this when performing timing tests, for instance the
+following loop can be completely removed, provided
+@code{some_expression} can provably not change any global state.
-@opindex funroll-loops
-Moreover, with @option{-funroll-loops} small ``empty'' loops are already
-removed, so the current behavior is both sub-optimal and inconsistent
-and will change in the future.
+@smallexample
+@{
+ int sum = 0;
+ int ix;
+
+ for (ix = 0; ix != 10000; ix++)
+ sum += some_expression;
+@}
+@end smallexample
+
+Even though @code{sum} is accumulated in the loop, no use is made of
+that summation, so the accumulation can be removed.
@item
Making side effects happen in the same order as in some other compiler.
For example, a function call like this may very well behave differently
from one compiler to another:
-@example
+@smallexample
void func (int, int);
int i = 2;
func (i++, i++);
-@end example
+@end smallexample
There is no guarantee (in either the C or the C++ standard language
definitions) that the increments will be evaluated in any particular
order. Either increment might happen first. @code{func} might get the
arguments @samp{2, 3}, or it might get @samp{3, 2}, or even @samp{2, 2}.
-@item
-Not allowing structures with volatile fields in registers.
-
-Strictly speaking, there is no prohibition in the ISO C standard
-against allowing structures with volatile fields in registers, but
-it does not seem to make any sense and is probably not what you wanted
-to do. So the compiler will give an error message in this case.
-
@item
Making certain warnings into errors by default.
ISO C requires a ``diagnostic'' message for certain kinds of invalid
programs, but a warning is defined by GCC to count as a diagnostic. If
GCC produces a warning but not an error, that is correct ISO C support.
-If test suites call this ``failure'', they should be run with the GCC
+If testsuites call this ``failure'', they should be run with the GCC
option @option{-pedantic-errors}, which will turn these warnings into
errors.
projects / msp430-gcc.git / blobdiff