@c Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
-@c 1999, 2000, 2001, 2003, 2004 Free Software Foundation, Inc.
+@c 1999, 2000, 2001, 2003, 2004, 2005, 2006, 2007, 2008, 2009
+@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++.
-* Protoize Caveats:: Things to watch out for when using @code{protoize}.
-* Non-bugs:: Things we think are right, but some others disagree.
+* C++ Misunderstandings:: Common misunderstandings with GNU C++.
+* 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
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
@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
compile environment.
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 that can be done about these problems.
-
-@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}.
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
@code{alloca} or variable-size arrays. This is because GCC doesn't
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
that is too large. If you should run into it, you can work around by
@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.
-@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 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}.
-@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,
-or fixing the header files by adding this:
-
-@smallexample
-#ifdef __STDC__
-#define NeedFunctionPrototypes 0
-#endif
-@end smallexample
-
-@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:
-
-@smallexample
-MALLOC=/usr/local/lib/libgmalloc.a
-@end smallexample
-
-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:
-
-@smallexample
-MALLOC=gmalloc.o
-@end smallexample
@end itemize
@node Incompatibilities
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
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
struct A @{
template <typename T>
void f () @{
- foo (1); // 1
- int i = N; // 2
+ foo (1); // @r{1}
+ int i = N; // @r{2}
T t;
- t.bar(); // 3
- foo (t); // 4
+ t.bar(); // @r{3}
+ foo (t); // @r{4}
@}
static const int N;
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:
+different from non-template codes. The most common is probably this:
@smallexample
template <typename T> struct 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
+@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
operator, the application can define whether and how the virtual base
subobject is assigned.
-@node Protoize Caveats
-@section Caveats of using @command{protoize}
-
-The conversion programs @command{protoize} and @command{unprotoize} can
-sometimes change a source file in a way that won't work unless you
-rearrange it.
-
-@itemize @bullet
-@item
-@command{protoize} can insert references to a type name or type tag before
-the definition, or in a file where they are not defined.
-
-If this happens, compiler error messages should show you where the new
-references are, so fixing the file by hand is straightforward.
-
-@item
-There are some C constructs which @command{protoize} cannot figure out.
-For example, it can't determine argument types for declaring a
-pointer-to-function variable; this you must do by hand. @command{protoize}
-inserts a comment containing @samp{???} each time it finds such a
-variable; so you can find all such variables by searching for this
-string. ISO C does not require declaring the argument types of
-pointer-to-function types.
-
-@item
-Using @command{unprotoize} can easily introduce bugs. If the program
-relied on prototypes to bring about conversion of arguments, these
-conversions will not take place in the program without prototypes.
-One case in which you can be sure @command{unprotoize} is safe is when
-you are removing prototypes that were made with @command{protoize}; if
-the program worked before without any prototypes, it will work again
-without them.
-
-@opindex Wconversion
-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.
-
-@item
-Both conversion programs can be confused if there are macro calls in and
-around the text to be converted. In other words, the standard syntax
-for a declaration or definition must not result from expanding a macro.
-This problem is inherent in the design of C and cannot be fixed. If
-only a few functions have confusing macro calls, you can easily convert
-them manually.
-
-@item
-@command{protoize} cannot get the argument types for a function whose
-definition was not actually compiled due to preprocessing conditionals.
-When this happens, @command{protoize} changes nothing in regard to such
-a function. @command{protoize} tries to detect such instances and warn
-about them.
-
-You can generally work around this problem by using @command{protoize} step
-by step, each time specifying a different set of @option{-D} options for
-compilation, until all of the functions have been converted. There is
-no automatic way to verify that you have got them all, however.
-
-@item
-Confusion may result if there is an occasion to convert a function
-declaration or definition in a region of source code where there is more
-than one formal parameter list present. Thus, attempts to convert code
-containing multiple (conditionally compiled) versions of a single
-function header (in the same vicinity) may not produce the desired (or
-expected) results.
-
-If you plan on converting source files which contain such code, it is
-recommended that you first make sure that each conditionally compiled
-region of source code which contains an alternative function header also
-contains at least one additional follower token (past the final right
-parenthesis of the function header). This should circumvent the
-problem.
-
-@item
-@command{unprotoize} can become confused when trying to convert a function
-definition or declaration which contains a declaration for a
-pointer-to-function formal argument which has the same name as the
-function being defined or declared. We recommend you avoid such choices
-of formal parameter names.
-
-@item
-You might also want to correct some of the indentation by hand and break
-long lines. (The conversion programs don't write lines longer than
-eighty characters in any case.)
-@end itemize
-
@node Non-bugs
@section Certain Changes We Don't Want to Make
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.
+
+@smallexample
+@{
+ int sum = 0;
+ int ix;
+
+ for (ix = 0; ix != 10000; ix++)
+ sum += some_expression;
+@}
+@end smallexample
-@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.
+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.
OSDN Git Service
