1<html lang="en"> 2<head> 3<title>Disappointments - Using the GNU Compiler Collection (GCC)</title> 4<meta http-equiv="Content-Type" content="text/html"> 5<meta name="description" content="Using the GNU Compiler Collection (GCC)"> 6<meta name="generator" content="makeinfo 4.13"> 7<link title="Top" rel="start" href="index.html#Top"> 8<link rel="up" href="Trouble.html#Trouble" title="Trouble"> 9<link rel="prev" href="Standard-Libraries.html#Standard-Libraries" title="Standard Libraries"> 10<link rel="next" href="C_002b_002b-Misunderstandings.html#C_002b_002b-Misunderstandings" title="C++ Misunderstandings"> 11<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage"> 12<!-- 13Copyright (C) 1988-2013 Free Software Foundation, Inc. 14 15Permission is granted to copy, distribute and/or modify this document 16under the terms of the GNU Free Documentation License, Version 1.3 or 17any later version published by the Free Software Foundation; with the 18Invariant Sections being ``Funding Free Software'', the Front-Cover 19Texts being (a) (see below), and with the Back-Cover Texts being (b) 20(see below). A copy of the license is included in the section entitled 21``GNU Free Documentation License''. 22 23(a) The FSF's Front-Cover Text is: 24 25 A GNU Manual 26 27(b) The FSF's Back-Cover Text is: 28 29 You have freedom to copy and modify this GNU Manual, like GNU 30 software. Copies published by the Free Software Foundation raise 31 funds for GNU development.--> 32<meta http-equiv="Content-Style-Type" content="text/css"> 33<style type="text/css"><!-- 34 pre.display { font-family:inherit } 35 pre.format { font-family:inherit } 36 pre.smalldisplay { font-family:inherit; font-size:smaller } 37 pre.smallformat { font-family:inherit; font-size:smaller } 38 pre.smallexample { font-size:smaller } 39 pre.smalllisp { font-size:smaller } 40 span.sc { font-variant:small-caps } 41 span.roman { font-family:serif; font-weight:normal; } 42 span.sansserif { font-family:sans-serif; font-weight:normal; } 43--></style> 44<link rel="stylesheet" type="text/css" href="../cs.css"> 45</head> 46<body> 47<div class="node"> 48<a name="Disappointments"></a> 49<p> 50Next: <a rel="next" accesskey="n" href="C_002b_002b-Misunderstandings.html#C_002b_002b-Misunderstandings">C++ Misunderstandings</a>, 51Previous: <a rel="previous" accesskey="p" href="Standard-Libraries.html#Standard-Libraries">Standard Libraries</a>, 52Up: <a rel="up" accesskey="u" href="Trouble.html#Trouble">Trouble</a> 53<hr> 54</div> 55 56<h3 class="section">11.6 Disappointments and Misunderstandings</h3> 57 58<p>These problems are perhaps regrettable, but we don't know any practical 59way around them. 60 61 <ul> 62<li>Certain local variables aren't recognized by debuggers when you compile 63with optimization. 64 65 <p>This occurs because sometimes GCC optimizes the variable out of 66existence. There is no way to tell the debugger how to compute the 67value such a variable “would have had”, and it is not clear that would 68be desirable anyway. So GCC simply does not mention the eliminated 69variable when it writes debugging information. 70 71 <p>You have to expect a certain amount of disagreement between the 72executable and your source code, when you use optimization. 73 74 <p><a name="index-conflicting-types-3570"></a><a name="index-scope-of-declaration-3571"></a><li>Users often think it is a bug when GCC reports an error for code 75like this: 76 77 <pre class="smallexample"> int foo (struct mumble *); 78 79 struct mumble { ... }; 80 81 int foo (struct mumble *x) 82 { ... } 83</pre> 84 <p>This code really is erroneous, because the scope of <code>struct 85mumble</code> in the prototype is limited to the argument list containing it. 86It does not refer to the <code>struct mumble</code> defined with file scope 87immediately below—they are two unrelated types with similar names in 88different scopes. 89 90 <p>But in the definition of <code>foo</code>, the file-scope type is used 91because that is available to be inherited. Thus, the definition and 92the prototype do not match, and you get an error. 93 94 <p>This behavior may seem silly, but it's what the ISO standard specifies. 95It is easy enough for you to make your code work by moving the 96definition of <code>struct mumble</code> above the prototype. It's not worth 97being incompatible with ISO C just to avoid an error for the example 98shown above. 99 100 <li>Accesses to bit-fields even in volatile objects works by accessing larger 101objects, such as a byte or a word. You cannot rely on what size of 102object is accessed in order to read or write the bit-field; it may even 103vary for a given bit-field according to the precise usage. 104 105 <p>If you care about controlling the amount of memory that is accessed, use 106volatile but do not use bit-fields. 107 108 <li>GCC comes with shell scripts to fix certain known problems in system 109header files. They install corrected copies of various header files in 110a special directory where only GCC will normally look for them. The 111scripts adapt to various systems by searching all the system header 112files for the problem cases that we know about. 113 114 <p>If new system header files are installed, nothing automatically arranges 115to update the corrected header files. They can be updated using the 116<samp><span class="command">mkheaders</span></samp> script installed in 117<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>. 118 119 <li><a name="index-floating-point-precision-3572"></a>On 68000 and x86 systems, for instance, you can get paradoxical results 120if you test the precise values of floating point numbers. For example, 121you can find that a floating point value which is not a NaN is not equal 122to itself. This results from the fact that the floating point registers 123hold a few more bits of precision than fit in a <code>double</code> in memory. 124Compiled code moves values between memory and floating point registers 125at its convenience, and moving them into memory truncates them. 126 127 <p><a name="index-ffloat_002dstore-3573"></a>You can partially avoid this problem by using the <samp><span class="option">-ffloat-store</span></samp> 128option (see <a href="Optimize-Options.html#Optimize-Options">Optimize Options</a>). 129 130 <li>On AIX and other platforms without weak symbol support, templates 131need to be instantiated explicitly and symbols for static members 132of templates will not be generated. 133 134 <li>On AIX, GCC scans object files and library archives for static 135constructors and destructors when linking an application before the 136linker prunes unreferenced symbols. This is necessary to prevent the 137AIX linker from mistakenly assuming that static constructor or 138destructor are unused and removing them before the scanning can occur. 139All static constructors and destructors found will be referenced even 140though the modules in which they occur may not be used by the program. 141This may lead to both increased executable size and unexpected symbol 142references. 143</ul> 144 145 </body></html> 146 147