You cannot select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
146 lines
6.9 KiB
HTML
146 lines
6.9 KiB
HTML
<html lang="en">
|
|
<head>
|
|
<title>Disappointments - Using the GNU Compiler Collection (GCC)</title>
|
|
<meta http-equiv="Content-Type" content="text/html">
|
|
<meta name="description" content="Using the GNU Compiler Collection (GCC)">
|
|
<meta name="generator" content="makeinfo 4.13">
|
|
<link title="Top" rel="start" href="index.html#Top">
|
|
<link rel="up" href="Trouble.html#Trouble" title="Trouble">
|
|
<link rel="prev" href="Standard-Libraries.html#Standard-Libraries" title="Standard Libraries">
|
|
<link rel="next" href="C_002b_002b-Misunderstandings.html#C_002b_002b-Misunderstandings" title="C++ Misunderstandings">
|
|
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
|
|
<!--
|
|
Copyright (C) 1988-2015 Free Software Foundation, Inc.
|
|
|
|
Permission is granted to copy, distribute and/or modify this document
|
|
under the terms of the GNU Free Documentation License, Version 1.3 or
|
|
any later version published by the Free Software Foundation; with the
|
|
Invariant Sections being ``Funding Free Software'', the Front-Cover
|
|
Texts being (a) (see below), and with the Back-Cover Texts being (b)
|
|
(see below). A copy of the license is included in the section entitled
|
|
``GNU Free Documentation License''.
|
|
|
|
(a) The FSF's Front-Cover Text is:
|
|
|
|
A GNU Manual
|
|
|
|
(b) The FSF's Back-Cover Text is:
|
|
|
|
You have freedom to copy and modify this GNU Manual, like GNU
|
|
software. Copies published by the Free Software Foundation raise
|
|
funds for GNU development.-->
|
|
<meta http-equiv="Content-Style-Type" content="text/css">
|
|
<style type="text/css"><!--
|
|
pre.display { font-family:inherit }
|
|
pre.format { font-family:inherit }
|
|
pre.smalldisplay { font-family:inherit; font-size:smaller }
|
|
pre.smallformat { font-family:inherit; font-size:smaller }
|
|
pre.smallexample { font-size:smaller }
|
|
pre.smalllisp { font-size:smaller }
|
|
span.sc { font-variant:small-caps }
|
|
span.roman { font-family:serif; font-weight:normal; }
|
|
span.sansserif { font-family:sans-serif; font-weight:normal; }
|
|
--></style>
|
|
</head>
|
|
<body>
|
|
<div class="node">
|
|
<a name="Disappointments"></a>
|
|
<p>
|
|
Next: <a rel="next" accesskey="n" href="C_002b_002b-Misunderstandings.html#C_002b_002b-Misunderstandings">C++ Misunderstandings</a>,
|
|
Previous: <a rel="previous" accesskey="p" href="Standard-Libraries.html#Standard-Libraries">Standard Libraries</a>,
|
|
Up: <a rel="up" accesskey="u" href="Trouble.html#Trouble">Trouble</a>
|
|
<hr>
|
|
</div>
|
|
|
|
<h3 class="section">12.6 Disappointments and Misunderstandings</h3>
|
|
|
|
<p>These problems are perhaps regrettable, but we don't know any practical
|
|
way around them.
|
|
|
|
<ul>
|
|
<li>Certain local variables aren't recognized by debuggers when you compile
|
|
with optimization.
|
|
|
|
<p>This occurs because sometimes GCC optimizes the variable out of
|
|
existence. There is no way to tell the debugger how to compute the
|
|
value such a variable “would have had”, and it is not clear that would
|
|
be desirable anyway. So GCC simply does not mention the eliminated
|
|
variable when it writes debugging information.
|
|
|
|
<p>You have to expect a certain amount of disagreement between the
|
|
executable and your source code, when you use optimization.
|
|
|
|
<p><a name="index-conflicting-types-4271"></a><a name="index-scope-of-declaration-4272"></a><li>Users often think it is a bug when GCC reports an error for code
|
|
like this:
|
|
|
|
<pre class="smallexample"> int foo (struct mumble *);
|
|
|
|
struct mumble { ... };
|
|
|
|
int foo (struct mumble *x)
|
|
{ ... }
|
|
</pre>
|
|
<p>This code really is erroneous, because the scope of <code>struct
|
|
mumble</code> in the prototype is limited to the argument list containing it.
|
|
It does not refer to the <code>struct mumble</code> defined with file scope
|
|
immediately below—they are two unrelated types with similar names in
|
|
different scopes.
|
|
|
|
<p>But in the definition of <code>foo</code>, the file-scope type is used
|
|
because that is available to be inherited. Thus, the definition and
|
|
the prototype do not match, and you get an error.
|
|
|
|
<p>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 <code>struct mumble</code> above the prototype. It's not worth
|
|
being incompatible with ISO C just to avoid an error for the example
|
|
shown above.
|
|
|
|
<li>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.
|
|
|
|
<p>If you care about controlling the amount of memory that is accessed, use
|
|
volatile but do not use bit-fields.
|
|
|
|
<li>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.
|
|
|
|
<p>If new system header files are installed, nothing automatically arranges
|
|
to update the corrected header files. They can be updated using the
|
|
<samp><span class="command">mkheaders</span></samp> script installed in
|
|
<samp><var>libexecdir</var><span class="file">/gcc/</span><var>target</var><span class="file">/</span><var>version</var><span class="file">/install-tools/</span></samp>.
|
|
|
|
<li><a name="index-floating-point-precision-4273"></a>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 <code>double</code> in memory.
|
|
Compiled code moves values between memory and floating point registers
|
|
at its convenience, and moving them into memory truncates them.
|
|
|
|
<p><a name="index-ffloat_002dstore-4274"></a>You can partially avoid this problem by using the <samp><span class="option">-ffloat-store</span></samp>
|
|
option (see <a href="Optimize-Options.html#Optimize-Options">Optimize Options</a>).
|
|
|
|
<li>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.
|
|
|
|
<li>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.
|
|
</ul>
|
|
|
|
</body></html>
|
|
|