Red Hat ENTERPRISE LINUX 4 Manual page 298

290
that would be desirable anyway. So GCC simply does not mention the eliminated variable when it
writes debugging information.
You have to expect a certain amount of disagreement between the executable and your source code,
when you use optimization.
Users often think it is a bug when GCC reports an error for code like this:
•
int foo (struct mumble *);
struct mumble { ... };
int foo (struct mumble *x)
{ ... }
This code really is erroneous, because the scope of
to the argument list containing it. It does not refer to the
immediately below--they are two unrelated types with similar names in different scopes.
But in the definition of
Thus, the definition and the prototype do not match, and you get an error.
This behavior may seem silly, but it's what the ISO standard specifies. It is easy enough for you to
make your code work by moving the definition of
worth being incompatible with ISO C just to avoid an error for the example shown above.
Accesses to bit-fields even in volatile objects works by accessing larger objects, such as a byte or
•
a word. You cannot rely on what size of object is accessed in order to read or write the bit-field; it
may even vary for a given bit-field according to the precise usage.
If you care about controlling the amount of memory that is accessed, use volatile but do not use
bit-fields.
GCC comes with shell scripts to fix certain known problems in system header files. They install
•
corrected copies of various header files in a special directory where only GCC will normally look
for them. The scripts adapt to various systems by searching all the system header 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
; then do
include
On 68000 and x86 systems, for instance, you can get paradoxical results if you test the precise
•
values of floating point numbers. For example, you can find that a floating point value which is
not a NaN is not equal to itself. This results from the fact that the floating point registers hold a
few more bits of precision than fit in a
memory and floating point registers at its convenience, and moving them into memory truncates
them.
You can partially avoid this problem by using the
That Control Optimization).
On AIX and other platforms without weak symbol support, templates need to be instantiated ex-
•
plicitly and symbols for static members of templates will not be generated.
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 re-
moving 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.
, the file-scope type is used because that is available to be inherited.
foo
again.
make install
double
Chapter 11. Known Causes of Trouble with GCC
struct mumble
struct mumble
struct mumble
and
stmp-fixinc stmp-headers
in memory. Compiled code moves values between
-ffloat-store
in the prototype is limited
defined with file scope
above the prototype. It's not
, and the subdirectory
option (Section 4.10 Options