@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.
+ 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.
@end itemize
@node Cross-Compiler Problems
@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
@end itemize
@node Incompatibilities
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
