gcc: Disappointments
1
1 13.6 Disappointments and Misunderstandings
1 ==========================================
1
1 These problems are perhaps regrettable, but we don't know any practical
1 way around them.
1
1 * Certain local variables aren't recognized by debuggers when you
1 compile with optimization.
1
1 This occurs because sometimes GCC optimizes the variable out of
1 existence. There is no way to tell the debugger how to compute the
1 value such a variable "would have had", and it is not clear that
1 would be desirable anyway. So GCC simply does not mention the
1 eliminated variable when it writes debugging information.
1
1 You have to expect a certain amount of disagreement between the
1 executable and your source code, when you use optimization.
1
1 * Users often think it is a bug when GCC reports an error for code
1 like this:
1
1 int foo (struct mumble *);
1
1 struct mumble { ... };
1
1 int foo (struct mumble *x)
1 { ... }
1
1 This code really is erroneous, because the scope of 'struct mumble'
1 in the prototype is limited to the argument list containing it. It
1 does not refer to the 'struct mumble' defined with file scope
1 immediately below--they are two unrelated types with similar names
1 in different scopes.
1
1 But in the definition of 'foo', the file-scope type is used because
1 that is available to be inherited. Thus, the definition and the
1 prototype do not match, and you get an error.
1
1 This behavior may seem silly, but it's what the ISO standard
1 specifies. It is easy enough for you to make your code work by
1 moving the definition of 'struct mumble' above the prototype. It's
1 not worth being incompatible with ISO C just to avoid an error for
1 the example shown above.
1
1 * Accesses to bit-fields even in volatile objects works by accessing
1 larger objects, such as a byte or a word. You cannot rely on what
1 size of object is accessed in order to read or write the bit-field;
1 it may even vary for a given bit-field according to the precise
1 usage.
1
1 If you care about controlling the amount of memory that is
1 accessed, use volatile but do not use bit-fields.
1
1 * GCC comes with shell scripts to fix certain known problems in
1 system header files. They install corrected copies of various
1 header files in a special directory where only GCC will normally
1 look for them. The scripts adapt to various systems by searching
1 all the system header files for the problem cases that we know
1 about.
1
1 If new system header files are installed, nothing automatically
1 arranges to update the corrected header files. They can be updated
1 using the 'mkheaders' script installed in
1 'LIBEXECDIR/gcc/TARGET/VERSION/install-tools/'.
1
1 * On 68000 and x86 systems, for instance, you can get paradoxical
1 results if you test the precise values of floating point numbers.
1 For example, you can find that a floating point value which is not
1 a NaN is not equal to itself. This results from the fact that the
1 floating point registers hold a few more bits of precision than fit
1 in a 'double' in memory. Compiled code moves values between memory
1 and floating point registers at its convenience, and moving them
1 into memory truncates them.
1
1 You can partially avoid this problem by using the '-ffloat-store'
1 option (⇒Optimize Options).
1
1 * On AIX and other platforms without weak symbol support, templates
1 need to be instantiated explicitly and symbols for static members
1 of templates will not be generated.
1
1 * On AIX, GCC scans object files and library archives for static
1 constructors and destructors when linking an application before the
1 linker prunes unreferenced symbols. This is necessary to prevent
1 the AIX linker from mistakenly assuming that static constructor or
1 destructor are unused and removing them before the scanning can
1 occur. All static constructors and destructors found will be
1 referenced even though the modules in which they occur may not be
1 used by the program. This may lead to both increased executable
1 size and unexpected symbol references.
1