|
0
|
1 @c Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
|
|
|
2 @c 1999, 2000, 2001, 2003, 2004, 2005, 2006, 2007, 2008
|
|
|
3 @c Free Software Foundation, Inc.
|
|
|
4 @c This is part of the GCC manual.
|
|
|
5 @c For copying conditions, see the file gcc.texi.
|
|
|
6
|
|
|
7 @node Trouble
|
|
|
8 @chapter Known Causes of Trouble with GCC
|
|
|
9 @cindex bugs, known
|
|
|
10 @cindex installation trouble
|
|
|
11 @cindex known causes of trouble
|
|
|
12
|
|
|
13 This section describes known problems that affect users of GCC@. Most
|
|
|
14 of these are not GCC bugs per se---if they were, we would fix them.
|
|
|
15 But the result for a user may be like the result of a bug.
|
|
|
16
|
|
|
17 Some of these problems are due to bugs in other software, some are
|
|
|
18 missing features that are too much work to add, and some are places
|
|
|
19 where people's opinions differ as to what is best.
|
|
|
20
|
|
|
21 @menu
|
|
|
22 * Actual Bugs:: Bugs we will fix later.
|
|
|
23 * Cross-Compiler Problems:: Common problems of cross compiling with GCC.
|
|
|
24 * Interoperation:: Problems using GCC with other compilers,
|
|
|
25 and with certain linkers, assemblers and debuggers.
|
|
|
26 * Incompatibilities:: GCC is incompatible with traditional C.
|
|
|
27 * Fixed Headers:: GCC uses corrected versions of system header files.
|
|
|
28 This is necessary, but doesn't always work smoothly.
|
|
|
29 * Standard Libraries:: GCC uses the system C library, which might not be
|
|
|
30 compliant with the ISO C standard.
|
|
|
31 * Disappointments:: Regrettable things we can't change, but not quite bugs.
|
|
|
32 * C++ Misunderstandings:: Common misunderstandings with GNU C++.
|
|
|
33 * Protoize Caveats:: Things to watch out for when using @code{protoize}.
|
|
|
34 * Non-bugs:: Things we think are right, but some others disagree.
|
|
|
35 * Warnings and Errors:: Which problems in your code get warnings,
|
|
|
36 and which get errors.
|
|
|
37 @end menu
|
|
|
38
|
|
|
39 @node Actual Bugs
|
|
|
40 @section Actual Bugs We Haven't Fixed Yet
|
|
|
41
|
|
|
42 @itemize @bullet
|
|
|
43 @item
|
|
|
44 The @code{fixincludes} script interacts badly with automounters; if the
|
|
|
45 directory of system header files is automounted, it tends to be
|
|
|
46 unmounted while @code{fixincludes} is running. This would seem to be a
|
|
|
47 bug in the automounter. We don't know any good way to work around it.
|
|
|
48
|
|
|
49 @item
|
|
|
50 The @code{fixproto} script will sometimes add prototypes for the
|
|
|
51 @code{sigsetjmp} and @code{siglongjmp} functions that reference the
|
|
|
52 @code{jmp_buf} type before that type is defined. To work around this,
|
|
|
53 edit the offending file and place the typedef in front of the
|
|
|
54 prototypes.
|
|
|
55 @end itemize
|
|
|
56
|
|
|
57 @node Cross-Compiler Problems
|
|
|
58 @section Cross-Compiler Problems
|
|
|
59
|
|
|
60 You may run into problems with cross compilation on certain machines,
|
|
|
61 for several reasons.
|
|
|
62
|
|
|
63 @itemize @bullet
|
|
|
64 @item
|
|
|
65 At present, the program @file{mips-tfile} which adds debug
|
|
|
66 support to object files on MIPS systems does not work in a cross
|
|
|
67 compile environment.
|
|
|
68 @end itemize
|
|
|
69
|
|
|
70 @node Interoperation
|
|
|
71 @section Interoperation
|
|
|
72
|
|
|
73 This section lists various difficulties encountered in using GCC
|
|
|
74 together with other compilers or with the assemblers, linkers,
|
|
|
75 libraries and debuggers on certain systems.
|
|
|
76
|
|
|
77 @itemize @bullet
|
|
|
78 @item
|
|
|
79 On many platforms, GCC supports a different ABI for C++ than do other
|
|
|
80 compilers, so the object files compiled by GCC cannot be used with object
|
|
|
81 files generated by another C++ compiler.
|
|
|
82
|
|
|
83 An area where the difference is most apparent is name mangling. The use
|
|
|
84 of different name mangling is intentional, to protect you from more subtle
|
|
|
85 problems.
|
|
|
86 Compilers differ as to many internal details of C++ implementation,
|
|
|
87 including: how class instances are laid out, how multiple inheritance is
|
|
|
88 implemented, and how virtual function calls are handled. If the name
|
|
|
89 encoding were made the same, your programs would link against libraries
|
|
|
90 provided from other compilers---but the programs would then crash when
|
|
|
91 run. Incompatible libraries are then detected at link time, rather than
|
|
|
92 at run time.
|
|
|
93
|
|
|
94 @item
|
|
|
95 On some BSD systems, including some versions of Ultrix, use of profiling
|
|
|
96 causes static variable destructors (currently used only in C++) not to
|
|
|
97 be run.
|
|
|
98
|
|
|
99 @item
|
|
|
100 On some SGI systems, when you use @option{-lgl_s} as an option,
|
|
|
101 it gets translated magically to @samp{-lgl_s -lX11_s -lc_s}.
|
|
|
102 Naturally, this does not happen when you use GCC@.
|
|
|
103 You must specify all three options explicitly.
|
|
|
104
|
|
|
105 @item
|
|
|
106 On a SPARC, GCC aligns all values of type @code{double} on an 8-byte
|
|
|
107 boundary, and it expects every @code{double} to be so aligned. The Sun
|
|
|
108 compiler usually gives @code{double} values 8-byte alignment, with one
|
|
|
109 exception: function arguments of type @code{double} may not be aligned.
|
|
|
110
|
|
|
111 As a result, if a function compiled with Sun CC takes the address of an
|
|
|
112 argument of type @code{double} and passes this pointer of type
|
|
|
113 @code{double *} to a function compiled with GCC, dereferencing the
|
|
|
114 pointer may cause a fatal signal.
|
|
|
115
|
|
|
116 One way to solve this problem is to compile your entire program with GCC@.
|
|
|
117 Another solution is to modify the function that is compiled with
|
|
|
118 Sun CC to copy the argument into a local variable; local variables
|
|
|
119 are always properly aligned. A third solution is to modify the function
|
|
|
120 that uses the pointer to dereference it via the following function
|
|
|
121 @code{access_double} instead of directly with @samp{*}:
|
|
|
122
|
|
|
123 @smallexample
|
|
|
124 inline double
|
|
|
125 access_double (double *unaligned_ptr)
|
|
|
126 @{
|
|
|
127 union d2i @{ double d; int i[2]; @};
|
|
|
128
|
|
|
129 union d2i *p = (union d2i *) unaligned_ptr;
|
|
|
130 union d2i u;
|
|
|
131
|
|
|
132 u.i[0] = p->i[0];
|
|
|
133 u.i[1] = p->i[1];
|
|
|
134
|
|
|
135 return u.d;
|
|
|
136 @}
|
|
|
137 @end smallexample
|
|
|
138
|
|
|
139 @noindent
|
|
|
140 Storing into the pointer can be done likewise with the same union.
|
|
|
141
|
|
|
142 @item
|
|
|
143 On Solaris, the @code{malloc} function in the @file{libmalloc.a} library
|
|
|
144 may allocate memory that is only 4 byte aligned. Since GCC on the
|
|
|
145 SPARC assumes that doubles are 8 byte aligned, this may result in a
|
|
|
146 fatal signal if doubles are stored in memory allocated by the
|
|
|
147 @file{libmalloc.a} library.
|
|
|
148
|
|
|
149 The solution is to not use the @file{libmalloc.a} library. Use instead
|
|
|
150 @code{malloc} and related functions from @file{libc.a}; they do not have
|
|
|
151 this problem.
|
|
|
152
|
|
|
153 @item
|
|
|
154 On the HP PA machine, ADB sometimes fails to work on functions compiled
|
|
|
155 with GCC@. Specifically, it fails to work on functions that use
|
|
|
156 @code{alloca} or variable-size arrays. This is because GCC doesn't
|
|
|
157 generate HP-UX unwind descriptors for such functions. It may even be
|
|
|
158 impossible to generate them.
|
|
|
159
|
|
|
160 @item
|
|
|
161 Debugging (@option{-g}) is not supported on the HP PA machine, unless you use
|
|
|
162 the preliminary GNU tools.
|
|
|
163
|
|
|
164 @item
|
|
|
165 Taking the address of a label may generate errors from the HP-UX
|
|
|
166 PA assembler. GAS for the PA does not have this problem.
|
|
|
167
|
|
|
168 @item
|
|
|
169 Using floating point parameters for indirect calls to static functions
|
|
|
170 will not work when using the HP assembler. There simply is no way for GCC
|
|
|
171 to specify what registers hold arguments for static functions when using
|
|
|
172 the HP assembler. GAS for the PA does not have this problem.
|
|
|
173
|
|
|
174 @item
|
|
|
175 In extremely rare cases involving some very large functions you may
|
|
|
176 receive errors from the HP linker complaining about an out of bounds
|
|
|
177 unconditional branch offset. This used to occur more often in previous
|
|
|
178 versions of GCC, but is now exceptionally rare. If you should run
|
|
|
179 into it, you can work around by making your function smaller.
|
|
|
180
|
|
|
181 @item
|
|
|
182 GCC compiled code sometimes emits warnings from the HP-UX assembler of
|
|
|
183 the form:
|
|
|
184
|
|
|
185 @smallexample
|
|
|
186 (warning) Use of GR3 when
|
|
|
187 frame >= 8192 may cause conflict.
|
|
|
188 @end smallexample
|
|
|
189
|
|
|
190 These warnings are harmless and can be safely ignored.
|
|
|
191
|
|
|
192 @item
|
|
|
193 In extremely rare cases involving some very large functions you may
|
|
|
194 receive errors from the AIX Assembler complaining about a displacement
|
|
|
195 that is too large. If you should run into it, you can work around by
|
|
|
196 making your function smaller.
|
|
|
197
|
|
|
198 @item
|
|
|
199 The @file{libstdc++.a} library in GCC relies on the SVR4 dynamic
|
|
|
200 linker semantics which merges global symbols between libraries and
|
|
|
201 applications, especially necessary for C++ streams functionality.
|
|
|
202 This is not the default behavior of AIX shared libraries and dynamic
|
|
|
203 linking. @file{libstdc++.a} is built on AIX with ``runtime-linking''
|
|
|
204 enabled so that symbol merging can occur. To utilize this feature,
|
|
|
205 the application linked with @file{libstdc++.a} must include the
|
|
|
206 @option{-Wl,-brtl} flag on the link line. G++ cannot impose this
|
|
|
207 because this option may interfere with the semantics of the user
|
|
|
208 program and users may not always use @samp{g++} to link his or her
|
|
|
209 application. Applications are not required to use the
|
|
|
210 @option{-Wl,-brtl} flag on the link line---the rest of the
|
|
|
211 @file{libstdc++.a} library which is not dependent on the symbol
|
|
|
212 merging semantics will continue to function correctly.
|
|
|
213
|
|
|
214 @item
|
|
|
215 An application can interpose its own definition of functions for
|
|
|
216 functions invoked by @file{libstdc++.a} with ``runtime-linking''
|
|
|
217 enabled on AIX@. To accomplish this the application must be linked
|
|
|
218 with ``runtime-linking'' option and the functions explicitly must be
|
|
|
219 exported by the application (@option{-Wl,-brtl,-bE:exportfile}).
|
|
|
220
|
|
|
221 @item
|
|
|
222 AIX on the RS/6000 provides support (NLS) for environments outside of
|
|
|
223 the United States. Compilers and assemblers use NLS to support
|
|
|
224 locale-specific representations of various objects including
|
|
|
225 floating-point numbers (@samp{.} vs @samp{,} for separating decimal
|
|
|
226 fractions). There have been problems reported where the library linked
|
|
|
227 with GCC does not produce the same floating-point formats that the
|
|
|
228 assembler accepts. If you have this problem, set the @env{LANG}
|
|
|
229 environment variable to @samp{C} or @samp{En_US}.
|
|
|
230
|
|
|
231 @item
|
|
|
232 @opindex fdollars-in-identifiers
|
|
|
233 Even if you specify @option{-fdollars-in-identifiers},
|
|
|
234 you cannot successfully use @samp{$} in identifiers on the RS/6000 due
|
|
|
235 to a restriction in the IBM assembler. GAS supports these
|
|
|
236 identifiers.
|
|
|
237
|
|
|
238 @end itemize
|
|
|
239
|
|
|
240 @node Incompatibilities
|
|
|
241 @section Incompatibilities of GCC
|
|
|
242 @cindex incompatibilities of GCC
|
|
|
243 @opindex traditional
|
|
|
244
|
|
|
245 There are several noteworthy incompatibilities between GNU C and K&R
|
|
|
246 (non-ISO) versions of C@.
|
|
|
247
|
|
|
248 @itemize @bullet
|
|
|
249 @cindex string constants
|
|
|
250 @cindex read-only strings
|
|
|
251 @cindex shared strings
|
|
|
252 @item
|
|
|
253 GCC normally makes string constants read-only. If several
|
|
|
254 identical-looking string constants are used, GCC stores only one
|
|
|
255 copy of the string.
|
|
|
256
|
|
|
257 @cindex @code{mktemp}, and constant strings
|
|
|
258 One consequence is that you cannot call @code{mktemp} with a string
|
|
|
259 constant argument. The function @code{mktemp} always alters the
|
|
|
260 string its argument points to.
|
|
|
261
|
|
|
262 @cindex @code{sscanf}, and constant strings
|
|
|
263 @cindex @code{fscanf}, and constant strings
|
|
|
264 @cindex @code{scanf}, and constant strings
|
|
|
265 Another consequence is that @code{sscanf} does not work on some very
|
|
|
266 old systems when passed a string constant as its format control string
|
|
|
267 or input. This is because @code{sscanf} incorrectly tries to write
|
|
|
268 into the string constant. Likewise @code{fscanf} and @code{scanf}.
|
|
|
269
|
|
|
270 The solution to these problems is to change the program to use
|
|
|
271 @code{char}-array variables with initialization strings for these
|
|
|
272 purposes instead of string constants.
|
|
|
273
|
|
|
274 @item
|
|
|
275 @code{-2147483648} is positive.
|
|
|
276
|
|
|
277 This is because 2147483648 cannot fit in the type @code{int}, so
|
|
|
278 (following the ISO C rules) its data type is @code{unsigned long int}.
|
|
|
279 Negating this value yields 2147483648 again.
|
|
|
280
|
|
|
281 @item
|
|
|
282 GCC does not substitute macro arguments when they appear inside of
|
|
|
283 string constants. For example, the following macro in GCC
|
|
|
284
|
|
|
285 @smallexample
|
|
|
286 #define foo(a) "a"
|
|
|
287 @end smallexample
|
|
|
288
|
|
|
289 @noindent
|
|
|
290 will produce output @code{"a"} regardless of what the argument @var{a} is.
|
|
|
291
|
|
|
292 @cindex @code{setjmp} incompatibilities
|
|
|
293 @cindex @code{longjmp} incompatibilities
|
|
|
294 @item
|
|
|
295 When you use @code{setjmp} and @code{longjmp}, the only automatic
|
|
|
296 variables guaranteed to remain valid are those declared
|
|
|
297 @code{volatile}. This is a consequence of automatic register
|
|
|
298 allocation. Consider this function:
|
|
|
299
|
|
|
300 @smallexample
|
|
|
301 jmp_buf j;
|
|
|
302
|
|
|
303 foo ()
|
|
|
304 @{
|
|
|
305 int a, b;
|
|
|
306
|
|
|
307 a = fun1 ();
|
|
|
308 if (setjmp (j))
|
|
|
309 return a;
|
|
|
310
|
|
|
311 a = fun2 ();
|
|
|
312 /* @r{@code{longjmp (j)} may occur in @code{fun3}.} */
|
|
|
313 return a + fun3 ();
|
|
|
314 @}
|
|
|
315 @end smallexample
|
|
|
316
|
|
|
317 Here @code{a} may or may not be restored to its first value when the
|
|
|
318 @code{longjmp} occurs. If @code{a} is allocated in a register, then
|
|
|
319 its first value is restored; otherwise, it keeps the last value stored
|
|
|
320 in it.
|
|
|
321
|
|
|
322 @opindex W
|
|
|
323 If you use the @option{-W} option with the @option{-O} option, you will
|
|
|
324 get a warning when GCC thinks such a problem might be possible.
|
|
|
325
|
|
|
326 @item
|
|
|
327 Programs that use preprocessing directives in the middle of macro
|
|
|
328 arguments do not work with GCC@. For example, a program like this
|
|
|
329 will not work:
|
|
|
330
|
|
|
331 @smallexample
|
|
|
332 @group
|
|
|
333 foobar (
|
|
|
334 #define luser
|
|
|
335 hack)
|
|
|
336 @end group
|
|
|
337 @end smallexample
|
|
|
338
|
|
|
339 ISO C does not permit such a construct.
|
|
|
340
|
|
|
341 @item
|
|
|
342 K&R compilers allow comments to cross over an inclusion boundary
|
|
|
343 (i.e.@: started in an include file and ended in the including file).
|
|
|
344
|
|
|
345 @cindex external declaration scope
|
|
|
346 @cindex scope of external declarations
|
|
|
347 @cindex declaration scope
|
|
|
348 @item
|
|
|
349 Declarations of external variables and functions within a block apply
|
|
|
350 only to the block containing the declaration. In other words, they
|
|
|
351 have the same scope as any other declaration in the same place.
|
|
|
352
|
|
|
353 In some other C compilers, a @code{extern} declaration affects all the
|
|
|
354 rest of the file even if it happens within a block.
|
|
|
355
|
|
|
356 @item
|
|
|
357 In traditional C, you can combine @code{long}, etc., with a typedef name,
|
|
|
358 as shown here:
|
|
|
359
|
|
|
360 @smallexample
|
|
|
361 typedef int foo;
|
|
|
362 typedef long foo bar;
|
|
|
363 @end smallexample
|
|
|
364
|
|
|
365 In ISO C, this is not allowed: @code{long} and other type modifiers
|
|
|
366 require an explicit @code{int}.
|
|
|
367
|
|
|
368 @cindex typedef names as function parameters
|
|
|
369 @item
|
|
|
370 PCC allows typedef names to be used as function parameters.
|
|
|
371
|
|
|
372 @item
|
|
|
373 Traditional C allows the following erroneous pair of declarations to
|
|
|
374 appear together in a given scope:
|
|
|
375
|
|
|
376 @smallexample
|
|
|
377 typedef int foo;
|
|
|
378 typedef foo foo;
|
|
|
379 @end smallexample
|
|
|
380
|
|
|
381 @item
|
|
|
382 GCC treats all characters of identifiers as significant. According to
|
|
|
383 K&R-1 (2.2), ``No more than the first eight characters are significant,
|
|
|
384 although more may be used.''. Also according to K&R-1 (2.2), ``An
|
|
|
385 identifier is a sequence of letters and digits; the first character must
|
|
|
386 be a letter. The underscore _ counts as a letter.'', but GCC also
|
|
|
387 allows dollar signs in identifiers.
|
|
|
388
|
|
|
389 @cindex whitespace
|
|
|
390 @item
|
|
|
391 PCC allows whitespace in the middle of compound assignment operators
|
|
|
392 such as @samp{+=}. GCC, following the ISO standard, does not
|
|
|
393 allow this.
|
|
|
394
|
|
|
395 @cindex apostrophes
|
|
|
396 @cindex '
|
|
|
397 @item
|
|
|
398 GCC complains about unterminated character constants inside of
|
|
|
399 preprocessing conditionals that fail. Some programs have English
|
|
|
400 comments enclosed in conditionals that are guaranteed to fail; if these
|
|
|
401 comments contain apostrophes, GCC will probably report an error. For
|
|
|
402 example, this code would produce an error:
|
|
|
403
|
|
|
404 @smallexample
|
|
|
405 #if 0
|
|
|
406 You can't expect this to work.
|
|
|
407 #endif
|
|
|
408 @end smallexample
|
|
|
409
|
|
|
410 The best solution to such a problem is to put the text into an actual
|
|
|
411 C comment delimited by @samp{/*@dots{}*/}.
|
|
|
412
|
|
|
413 @item
|
|
|
414 Many user programs contain the declaration @samp{long time ();}. In the
|
|
|
415 past, the system header files on many systems did not actually declare
|
|
|
416 @code{time}, so it did not matter what type your program declared it to
|
|
|
417 return. But in systems with ISO C headers, @code{time} is declared to
|
|
|
418 return @code{time_t}, and if that is not the same as @code{long}, then
|
|
|
419 @samp{long time ();} is erroneous.
|
|
|
420
|
|
|
421 The solution is to change your program to use appropriate system headers
|
|
|
422 (@code{<time.h>} on systems with ISO C headers) and not to declare
|
|
|
423 @code{time} if the system header files declare it, or failing that to
|
|
|
424 use @code{time_t} as the return type of @code{time}.
|
|
|
425
|
|
|
426 @cindex @code{float} as function value type
|
|
|
427 @item
|
|
|
428 When compiling functions that return @code{float}, PCC converts it to
|
|
|
429 a double. GCC actually returns a @code{float}. If you are concerned
|
|
|
430 with PCC compatibility, you should declare your functions to return
|
|
|
431 @code{double}; you might as well say what you mean.
|
|
|
432
|
|
|
433 @cindex structures
|
|
|
434 @cindex unions
|
|
|
435 @item
|
|
|
436 When compiling functions that return structures or unions, GCC
|
|
|
437 output code normally uses a method different from that used on most
|
|
|
438 versions of Unix. As a result, code compiled with GCC cannot call
|
|
|
439 a structure-returning function compiled with PCC, and vice versa.
|
|
|
440
|
|
|
441 The method used by GCC is as follows: a structure or union which is
|
|
|
442 1, 2, 4 or 8 bytes long is returned like a scalar. A structure or union
|
|
|
443 with any other size is stored into an address supplied by the caller
|
|
|
444 (usually in a special, fixed register, but on some machines it is passed
|
|
|
445 on the stack). The target hook @code{TARGET_STRUCT_VALUE_RTX}
|
|
|
446 tells GCC where to pass this address.
|
|
|
447
|
|
|
448 By contrast, PCC on most target machines returns structures and unions
|
|
|
449 of any size by copying the data into an area of static storage, and then
|
|
|
450 returning the address of that storage as if it were a pointer value.
|
|
|
451 The caller must copy the data from that memory area to the place where
|
|
|
452 the value is wanted. GCC does not use this method because it is
|
|
|
453 slower and nonreentrant.
|
|
|
454
|
|
|
455 On some newer machines, PCC uses a reentrant convention for all
|
|
|
456 structure and union returning. GCC on most of these machines uses a
|
|
|
457 compatible convention when returning structures and unions in memory,
|
|
|
458 but still returns small structures and unions in registers.
|
|
|
459
|
|
|
460 @opindex fpcc-struct-return
|
|
|
461 You can tell GCC to use a compatible convention for all structure and
|
|
|
462 union returning with the option @option{-fpcc-struct-return}.
|
|
|
463
|
|
|
464 @cindex preprocessing tokens
|
|
|
465 @cindex preprocessing numbers
|
|
|
466 @item
|
|
|
467 GCC complains about program fragments such as @samp{0x74ae-0x4000}
|
|
|
468 which appear to be two hexadecimal constants separated by the minus
|
|
|
469 operator. Actually, this string is a single @dfn{preprocessing token}.
|
|
|
470 Each such token must correspond to one token in C@. Since this does not,
|
|
|
471 GCC prints an error message. Although it may appear obvious that what
|
|
|
472 is meant is an operator and two values, the ISO C standard specifically
|
|
|
473 requires that this be treated as erroneous.
|
|
|
474
|
|
|
475 A @dfn{preprocessing token} is a @dfn{preprocessing number} if it
|
|
|
476 begins with a digit and is followed by letters, underscores, digits,
|
|
|
477 periods and @samp{e+}, @samp{e-}, @samp{E+}, @samp{E-}, @samp{p+},
|
|
|
478 @samp{p-}, @samp{P+}, or @samp{P-} character sequences. (In strict C89
|
|
|
479 mode, the sequences @samp{p+}, @samp{p-}, @samp{P+} and @samp{P-} cannot
|
|
|
480 appear in preprocessing numbers.)
|
|
|
481
|
|
|
482 To make the above program fragment valid, place whitespace in front of
|
|
|
483 the minus sign. This whitespace will end the preprocessing number.
|
|
|
484 @end itemize
|
|
|
485
|
|
|
486 @node Fixed Headers
|
|
|
487 @section Fixed Header Files
|
|
|
488
|
|
|
489 GCC needs to install corrected versions of some system header files.
|
|
|
490 This is because most target systems have some header files that won't
|
|
|
491 work with GCC unless they are changed. Some have bugs, some are
|
|
|
492 incompatible with ISO C, and some depend on special features of other
|
|
|
493 compilers.
|
|
|
494
|
|
|
495 Installing GCC automatically creates and installs the fixed header
|
|
|
496 files, by running a program called @code{fixincludes}. Normally, you
|
|
|
497 don't need to pay attention to this. But there are cases where it
|
|
|
498 doesn't do the right thing automatically.
|
|
|
499
|
|
|
500 @itemize @bullet
|
|
|
501 @item
|
|
|
502 If you update the system's header files, such as by installing a new
|
|
|
503 system version, the fixed header files of GCC are not automatically
|
|
|
504 updated. They can be updated using the @command{mkheaders} script
|
|
|
505 installed in
|
|
|
506 @file{@var{libexecdir}/gcc/@var{target}/@var{version}/install-tools/}.
|
|
|
507
|
|
|
508 @item
|
|
|
509 On some systems, header file directories contain
|
|
|
510 machine-specific symbolic links in certain places. This makes it
|
|
|
511 possible to share most of the header files among hosts running the
|
|
|
512 same version of the system on different machine models.
|
|
|
513
|
|
|
514 The programs that fix the header files do not understand this special
|
|
|
515 way of using symbolic links; therefore, the directory of fixed header
|
|
|
516 files is good only for the machine model used to build it.
|
|
|
517
|
|
|
518 It is possible to make separate sets of fixed header files for the
|
|
|
519 different machine models, and arrange a structure of symbolic links so
|
|
|
520 as to use the proper set, but you'll have to do this by hand.
|
|
|
521 @end itemize
|
|
|
522
|
|
|
523 @node Standard Libraries
|
|
|
524 @section Standard Libraries
|
|
|
525
|
|
|
526 @opindex Wall
|
|
|
527 GCC by itself attempts to be a conforming freestanding implementation.
|
|
|
528 @xref{Standards,,Language Standards Supported by GCC}, for details of
|
|
|
529 what this means. Beyond the library facilities required of such an
|
|
|
530 implementation, the rest of the C library is supplied by the vendor of
|
|
|
531 the operating system. If that C library doesn't conform to the C
|
|
|
532 standards, then your programs might get warnings (especially when using
|
|
|
533 @option{-Wall}) that you don't expect.
|
|
|
534
|
|
|
535 For example, the @code{sprintf} function on SunOS 4.1.3 returns
|
|
|
536 @code{char *} while the C standard says that @code{sprintf} returns an
|
|
|
537 @code{int}. The @code{fixincludes} program could make the prototype for
|
|
|
538 this function match the Standard, but that would be wrong, since the
|
|
|
539 function will still return @code{char *}.
|
|
|
540
|
|
|
541 If you need a Standard compliant library, then you need to find one, as
|
|
|
542 GCC does not provide one. The GNU C library (called @code{glibc})
|
|
|
543 provides ISO C, POSIX, BSD, SystemV and X/Open compatibility for
|
|
|
544 GNU/Linux and HURD-based GNU systems; no recent version of it supports
|
|
|
545 other systems, though some very old versions did. Version 2.2 of the
|
|
|
546 GNU C library includes nearly complete C99 support. You could also ask
|
|
|
547 your operating system vendor if newer libraries are available.
|
|
|
548
|
|
|
549 @node Disappointments
|
|
|
550 @section Disappointments and Misunderstandings
|
|
|
551
|
|
|
552 These problems are perhaps regrettable, but we don't know any practical
|
|
|
553 way around them.
|
|
|
554
|
|
|
555 @itemize @bullet
|
|
|
556 @item
|
|
|
557 Certain local variables aren't recognized by debuggers when you compile
|
|
|
558 with optimization.
|
|
|
559
|
|
|
560 This occurs because sometimes GCC optimizes the variable out of
|
|
|
561 existence. There is no way to tell the debugger how to compute the
|
|
|
562 value such a variable ``would have had'', and it is not clear that would
|
|
|
563 be desirable anyway. So GCC simply does not mention the eliminated
|
|
|
564 variable when it writes debugging information.
|
|
|
565
|
|
|
566 You have to expect a certain amount of disagreement between the
|
|
|
567 executable and your source code, when you use optimization.
|
|
|
568
|
|
|
569 @cindex conflicting types
|
|
|
570 @cindex scope of declaration
|
|
|
571 @item
|
|
|
572 Users often think it is a bug when GCC reports an error for code
|
|
|
573 like this:
|
|
|
574
|
|
|
575 @smallexample
|
|
|
576 int foo (struct mumble *);
|
|
|
577
|
|
|
578 struct mumble @{ @dots{} @};
|
|
|
579
|
|
|
580 int foo (struct mumble *x)
|
|
|
581 @{ @dots{} @}
|
|
|
582 @end smallexample
|
|
|
583
|
|
|
584 This code really is erroneous, because the scope of @code{struct
|
|
|
585 mumble} in the prototype is limited to the argument list containing it.
|
|
|
586 It does not refer to the @code{struct mumble} defined with file scope
|
|
|
587 immediately below---they are two unrelated types with similar names in
|
|
|
588 different scopes.
|
|
|
589
|
|
|
590 But in the definition of @code{foo}, the file-scope type is used
|
|
|
591 because that is available to be inherited. Thus, the definition and
|
|
|
592 the prototype do not match, and you get an error.
|
|
|
593
|
|
|
594 This behavior may seem silly, but it's what the ISO standard specifies.
|
|
|
595 It is easy enough for you to make your code work by moving the
|
|
|
596 definition of @code{struct mumble} above the prototype. It's not worth
|
|
|
597 being incompatible with ISO C just to avoid an error for the example
|
|
|
598 shown above.
|
|
|
599
|
|
|
600 @item
|
|
|
601 Accesses to bit-fields even in volatile objects works by accessing larger
|
|
|
602 objects, such as a byte or a word. You cannot rely on what size of
|
|
|
603 object is accessed in order to read or write the bit-field; it may even
|
|
|
604 vary for a given bit-field according to the precise usage.
|
|
|
605
|
|
|
606 If you care about controlling the amount of memory that is accessed, use
|
|
|
607 volatile but do not use bit-fields.
|
|
|
608
|
|
|
609 @item
|
|
|
610 GCC comes with shell scripts to fix certain known problems in system
|
|
|
611 header files. They install corrected copies of various header files in
|
|
|
612 a special directory where only GCC will normally look for them. The
|
|
|
613 scripts adapt to various systems by searching all the system header
|
|
|
614 files for the problem cases that we know about.
|
|
|
615
|
|
|
616 If new system header files are installed, nothing automatically arranges
|
|
|
617 to update the corrected header files. They can be updated using the
|
|
|
618 @command{mkheaders} script installed in
|
|
|
619 @file{@var{libexecdir}/gcc/@var{target}/@var{version}/install-tools/}.
|
|
|
620
|
|
|
621 @item
|
|
|
622 @cindex floating point precision
|
|
|
623 On 68000 and x86 systems, for instance, you can get paradoxical results
|
|
|
624 if you test the precise values of floating point numbers. For example,
|
|
|
625 you can find that a floating point value which is not a NaN is not equal
|
|
|
626 to itself. This results from the fact that the floating point registers
|
|
|
627 hold a few more bits of precision than fit in a @code{double} in memory.
|
|
|
628 Compiled code moves values between memory and floating point registers
|
|
|
629 at its convenience, and moving them into memory truncates them.
|
|
|
630
|
|
|
631 @opindex ffloat-store
|
|
|
632 You can partially avoid this problem by using the @option{-ffloat-store}
|
|
|
633 option (@pxref{Optimize Options}).
|
|
|
634
|
|
|
635 @item
|
|
|
636 On AIX and other platforms without weak symbol support, templates
|
|
|
637 need to be instantiated explicitly and symbols for static members
|
|
|
638 of templates will not be generated.
|
|
|
639
|
|
|
640 @item
|
|
|
641 On AIX, GCC scans object files and library archives for static
|
|
|
642 constructors and destructors when linking an application before the
|
|
|
643 linker prunes unreferenced symbols. This is necessary to prevent the
|
|
|
644 AIX linker from mistakenly assuming that static constructor or
|
|
|
645 destructor are unused and removing them before the scanning can occur.
|
|
|
646 All static constructors and destructors found will be referenced even
|
|
|
647 though the modules in which they occur may not be used by the program.
|
|
|
648 This may lead to both increased executable size and unexpected symbol
|
|
|
649 references.
|
|
|
650 @end itemize
|
|
|
651
|
|
|
652 @node C++ Misunderstandings
|
|
|
653 @section Common Misunderstandings with GNU C++
|
|
|
654
|
|
|
655 @cindex misunderstandings in C++
|
|
|
656 @cindex surprises in C++
|
|
|
657 @cindex C++ misunderstandings
|
|
|
658 C++ is a complex language and an evolving one, and its standard
|
|
|
659 definition (the ISO C++ standard) was only recently completed. As a
|
|
|
660 result, your C++ compiler may occasionally surprise you, even when its
|
|
|
661 behavior is correct. This section discusses some areas that frequently
|
|
|
662 give rise to questions of this sort.
|
|
|
663
|
|
|
664 @menu
|
|
|
665 * Static Definitions:: Static member declarations are not definitions
|
|
|
666 * Name lookup:: Name lookup, templates, and accessing members of base classes
|
|
|
667 * Temporaries:: Temporaries may vanish before you expect
|
|
|
668 * Copy Assignment:: Copy Assignment operators copy virtual bases twice
|
|
|
669 @end menu
|
|
|
670
|
|
|
671 @node Static Definitions
|
|
|
672 @subsection Declare @emph{and} Define Static Members
|
|
|
673
|
|
|
674 @cindex C++ static data, declaring and defining
|
|
|
675 @cindex static data in C++, declaring and defining
|
|
|
676 @cindex declaring static data in C++
|
|
|
677 @cindex defining static data in C++
|
|
|
678 When a class has static data members, it is not enough to @emph{declare}
|
|
|
679 the static member; you must also @emph{define} it. For example:
|
|
|
680
|
|
|
681 @smallexample
|
|
|
682 class Foo
|
|
|
683 @{
|
|
|
684 @dots{}
|
|
|
685 void method();
|
|
|
686 static int bar;
|
|
|
687 @};
|
|
|
688 @end smallexample
|
|
|
689
|
|
|
690 This declaration only establishes that the class @code{Foo} has an
|
|
|
691 @code{int} named @code{Foo::bar}, and a member function named
|
|
|
692 @code{Foo::method}. But you still need to define @emph{both}
|
|
|
693 @code{method} and @code{bar} elsewhere. According to the ISO
|
|
|
694 standard, you must supply an initializer in one (and only one) source
|
|
|
695 file, such as:
|
|
|
696
|
|
|
697 @smallexample
|
|
|
698 int Foo::bar = 0;
|
|
|
699 @end smallexample
|
|
|
700
|
|
|
701 Other C++ compilers may not correctly implement the standard behavior.
|
|
|
702 As a result, when you switch to @command{g++} from one of these compilers,
|
|
|
703 you may discover that a program that appeared to work correctly in fact
|
|
|
704 does not conform to the standard: @command{g++} reports as undefined
|
|
|
705 symbols any static data members that lack definitions.
|
|
|
706
|
|
|
707
|
|
|
708 @node Name lookup
|
|
|
709 @subsection Name lookup, templates, and accessing members of base classes
|
|
|
710
|
|
|
711 @cindex base class members
|
|
|
712 @cindex two-stage name lookup
|
|
|
713 @cindex dependent name lookup
|
|
|
714
|
|
|
715 The C++ standard prescribes that all names that are not dependent on
|
|
|
716 template parameters are bound to their present definitions when parsing
|
|
|
717 a template function or class.@footnote{The C++ standard just uses the
|
|
|
718 term ``dependent'' for names that depend on the type or value of
|
|
|
719 template parameters. This shorter term will also be used in the rest of
|
|
|
720 this section.} Only names that are dependent are looked up at the point
|
|
|
721 of instantiation. For example, consider
|
|
|
722
|
|
|
723 @smallexample
|
|
|
724 void foo(double);
|
|
|
725
|
|
|
726 struct A @{
|
|
|
727 template <typename T>
|
|
|
728 void f () @{
|
|
|
729 foo (1); // @r{1}
|
|
|
730 int i = N; // @r{2}
|
|
|
731 T t;
|
|
|
732 t.bar(); // @r{3}
|
|
|
733 foo (t); // @r{4}
|
|
|
734 @}
|
|
|
735
|
|
|
736 static const int N;
|
|
|
737 @};
|
|
|
738 @end smallexample
|
|
|
739
|
|
|
740 Here, the names @code{foo} and @code{N} appear in a context that does
|
|
|
741 not depend on the type of @code{T}. The compiler will thus require that
|
|
|
742 they are defined in the context of use in the template, not only before
|
|
|
743 the point of instantiation, and will here use @code{::foo(double)} and
|
|
|
744 @code{A::N}, respectively. In particular, it will convert the integer
|
|
|
745 value to a @code{double} when passing it to @code{::foo(double)}.
|
|
|
746
|
|
|
747 Conversely, @code{bar} and the call to @code{foo} in the fourth marked
|
|
|
748 line are used in contexts that do depend on the type of @code{T}, so
|
|
|
749 they are only looked up at the point of instantiation, and you can
|
|
|
750 provide declarations for them after declaring the template, but before
|
|
|
751 instantiating it. In particular, if you instantiate @code{A::f<int>},
|
|
|
752 the last line will call an overloaded @code{::foo(int)} if one was
|
|
|
753 provided, even if after the declaration of @code{struct A}.
|
|
|
754
|
|
|
755 This distinction between lookup of dependent and non-dependent names is
|
|
|
756 called two-stage (or dependent) name lookup. G++ implements it
|
|
|
757 since version 3.4.
|
|
|
758
|
|
|
759 Two-stage name lookup sometimes leads to situations with behavior
|
|
|
760 different from non-template codes. The most common is probably this:
|
|
|
761
|
|
|
762 @smallexample
|
|
|
763 template <typename T> struct Base @{
|
|
|
764 int i;
|
|
|
765 @};
|
|
|
766
|
|
|
767 template <typename T> struct Derived : public Base<T> @{
|
|
|
768 int get_i() @{ return i; @}
|
|
|
769 @};
|
|
|
770 @end smallexample
|
|
|
771
|
|
|
772 In @code{get_i()}, @code{i} is not used in a dependent context, so the
|
|
|
773 compiler will look for a name declared at the enclosing namespace scope
|
|
|
774 (which is the global scope here). It will not look into the base class,
|
|
|
775 since that is dependent and you may declare specializations of
|
|
|
776 @code{Base} even after declaring @code{Derived}, so the compiler can't
|
|
|
777 really know what @code{i} would refer to. If there is no global
|
|
|
778 variable @code{i}, then you will get an error message.
|
|
|
779
|
|
|
780 In order to make it clear that you want the member of the base class,
|
|
|
781 you need to defer lookup until instantiation time, at which the base
|
|
|
782 class is known. For this, you need to access @code{i} in a dependent
|
|
|
783 context, by either using @code{this->i} (remember that @code{this} is of
|
|
|
784 type @code{Derived<T>*}, so is obviously dependent), or using
|
|
|
785 @code{Base<T>::i}. Alternatively, @code{Base<T>::i} might be brought
|
|
|
786 into scope by a @code{using}-declaration.
|
|
|
787
|
|
|
788 Another, similar example involves calling member functions of a base
|
|
|
789 class:
|
|
|
790
|
|
|
791 @smallexample
|
|
|
792 template <typename T> struct Base @{
|
|
|
793 int f();
|
|
|
794 @};
|
|
|
795
|
|
|
796 template <typename T> struct Derived : Base<T> @{
|
|
|
797 int g() @{ return f(); @};
|
|
|
798 @};
|
|
|
799 @end smallexample
|
|
|
800
|
|
|
801 Again, the call to @code{f()} is not dependent on template arguments
|
|
|
802 (there are no arguments that depend on the type @code{T}, and it is also
|
|
|
803 not otherwise specified that the call should be in a dependent context).
|
|
|
804 Thus a global declaration of such a function must be available, since
|
|
|
805 the one in the base class is not visible until instantiation time. The
|
|
|
806 compiler will consequently produce the following error message:
|
|
|
807
|
|
|
808 @smallexample
|
|
|
809 x.cc: In member function `int Derived<T>::g()':
|
|
|
810 x.cc:6: error: there are no arguments to `f' that depend on a template
|
|
|
811 parameter, so a declaration of `f' must be available
|
|
|
812 x.cc:6: error: (if you use `-fpermissive', G++ will accept your code, but
|
|
|
813 allowing the use of an undeclared name is deprecated)
|
|
|
814 @end smallexample
|
|
|
815
|
|
|
816 To make the code valid either use @code{this->f()}, or
|
|
|
817 @code{Base<T>::f()}. Using the @option{-fpermissive} flag will also let
|
|
|
818 the compiler accept the code, by marking all function calls for which no
|
|
|
819 declaration is visible at the time of definition of the template for
|
|
|
820 later lookup at instantiation time, as if it were a dependent call.
|
|
|
821 We do not recommend using @option{-fpermissive} to work around invalid
|
|
|
822 code, and it will also only catch cases where functions in base classes
|
|
|
823 are called, not where variables in base classes are used (as in the
|
|
|
824 example above).
|
|
|
825
|
|
|
826 Note that some compilers (including G++ versions prior to 3.4) get these
|
|
|
827 examples wrong and accept above code without an error. Those compilers
|
|
|
828 do not implement two-stage name lookup correctly.
|
|
|
829
|
|
|
830
|
|
|
831 @node Temporaries
|
|
|
832 @subsection Temporaries May Vanish Before You Expect
|
|
|
833
|
|
|
834 @cindex temporaries, lifetime of
|
|
|
835 @cindex portions of temporary objects, pointers to
|
|
|
836 It is dangerous to use pointers or references to @emph{portions} of a
|
|
|
837 temporary object. The compiler may very well delete the object before
|
|
|
838 you expect it to, leaving a pointer to garbage. The most common place
|
|
|
839 where this problem crops up is in classes like string classes,
|
|
|
840 especially ones that define a conversion function to type @code{char *}
|
|
|
841 or @code{const char *}---which is one reason why the standard
|
|
|
842 @code{string} class requires you to call the @code{c_str} member
|
|
|
843 function. However, any class that returns a pointer to some internal
|
|
|
844 structure is potentially subject to this problem.
|
|
|
845
|
|
|
846 For example, a program may use a function @code{strfunc} that returns
|
|
|
847 @code{string} objects, and another function @code{charfunc} that
|
|
|
848 operates on pointers to @code{char}:
|
|
|
849
|
|
|
850 @smallexample
|
|
|
851 string strfunc ();
|
|
|
852 void charfunc (const char *);
|
|
|
853
|
|
|
854 void
|
|
|
855 f ()
|
|
|
856 @{
|
|
|
857 const char *p = strfunc().c_str();
|
|
|
858 @dots{}
|
|
|
859 charfunc (p);
|
|
|
860 @dots{}
|
|
|
861 charfunc (p);
|
|
|
862 @}
|
|
|
863 @end smallexample
|
|
|
864
|
|
|
865 @noindent
|
|
|
866 In this situation, it may seem reasonable to save a pointer to the C
|
|
|
867 string returned by the @code{c_str} member function and use that rather
|
|
|
868 than call @code{c_str} repeatedly. However, the temporary string
|
|
|
869 created by the call to @code{strfunc} is destroyed after @code{p} is
|
|
|
870 initialized, at which point @code{p} is left pointing to freed memory.
|
|
|
871
|
|
|
872 Code like this may run successfully under some other compilers,
|
|
|
873 particularly obsolete cfront-based compilers that delete temporaries
|
|
|
874 along with normal local variables. However, the GNU C++ behavior is
|
|
|
875 standard-conforming, so if your program depends on late destruction of
|
|
|
876 temporaries it is not portable.
|
|
|
877
|
|
|
878 The safe way to write such code is to give the temporary a name, which
|
|
|
879 forces it to remain until the end of the scope of the name. For
|
|
|
880 example:
|
|
|
881
|
|
|
882 @smallexample
|
|
|
883 const string& tmp = strfunc ();
|
|
|
884 charfunc (tmp.c_str ());
|
|
|
885 @end smallexample
|
|
|
886
|
|
|
887 @node Copy Assignment
|
|
|
888 @subsection Implicit Copy-Assignment for Virtual Bases
|
|
|
889
|
|
|
890 When a base class is virtual, only one subobject of the base class
|
|
|
891 belongs to each full object. Also, the constructors and destructors are
|
|
|
892 invoked only once, and called from the most-derived class. However, such
|
|
|
893 objects behave unspecified when being assigned. For example:
|
|
|
894
|
|
|
895 @smallexample
|
|
|
896 struct Base@{
|
|
|
897 char *name;
|
|
|
898 Base(char *n) : name(strdup(n))@{@}
|
|
|
899 Base& operator= (const Base& other)@{
|
|
|
900 free (name);
|
|
|
901 name = strdup (other.name);
|
|
|
902 @}
|
|
|
903 @};
|
|
|
904
|
|
|
905 struct A:virtual Base@{
|
|
|
906 int val;
|
|
|
907 A():Base("A")@{@}
|
|
|
908 @};
|
|
|
909
|
|
|
910 struct B:virtual Base@{
|
|
|
911 int bval;
|
|
|
912 B():Base("B")@{@}
|
|
|
913 @};
|
|
|
914
|
|
|
915 struct Derived:public A, public B@{
|
|
|
916 Derived():Base("Derived")@{@}
|
|
|
917 @};
|
|
|
918
|
|
|
919 void func(Derived &d1, Derived &d2)
|
|
|
920 @{
|
|
|
921 d1 = d2;
|
|
|
922 @}
|
|
|
923 @end smallexample
|
|
|
924
|
|
|
925 The C++ standard specifies that @samp{Base::Base} is only called once
|
|
|
926 when constructing or copy-constructing a Derived object. It is
|
|
|
927 unspecified whether @samp{Base::operator=} is called more than once when
|
|
|
928 the implicit copy-assignment for Derived objects is invoked (as it is
|
|
|
929 inside @samp{func} in the example).
|
|
|
930
|
|
|
931 G++ implements the ``intuitive'' algorithm for copy-assignment: assign all
|
|
|
932 direct bases, then assign all members. In that algorithm, the virtual
|
|
|
933 base subobject can be encountered more than once. In the example, copying
|
|
|
934 proceeds in the following order: @samp{val}, @samp{name} (via
|
|
|
935 @code{strdup}), @samp{bval}, and @samp{name} again.
|
|
|
936
|
|
|
937 If application code relies on copy-assignment, a user-defined
|
|
|
938 copy-assignment operator removes any uncertainties. With such an
|
|
|
939 operator, the application can define whether and how the virtual base
|
|
|
940 subobject is assigned.
|
|
|
941
|
|
|
942 @node Protoize Caveats
|
|
|
943 @section Caveats of using @command{protoize}
|
|
|
944
|
|
|
945 The conversion programs @command{protoize} and @command{unprotoize} can
|
|
|
946 sometimes change a source file in a way that won't work unless you
|
|
|
947 rearrange it.
|
|
|
948
|
|
|
949 @itemize @bullet
|
|
|
950 @item
|
|
|
951 @command{protoize} can insert references to a type name or type tag before
|
|
|
952 the definition, or in a file where they are not defined.
|
|
|
953
|
|
|
954 If this happens, compiler error messages should show you where the new
|
|
|
955 references are, so fixing the file by hand is straightforward.
|
|
|
956
|
|
|
957 @item
|
|
|
958 There are some C constructs which @command{protoize} cannot figure out.
|
|
|
959 For example, it can't determine argument types for declaring a
|
|
|
960 pointer-to-function variable; this you must do by hand. @command{protoize}
|
|
|
961 inserts a comment containing @samp{???} each time it finds such a
|
|
|
962 variable; so you can find all such variables by searching for this
|
|
|
963 string. ISO C does not require declaring the argument types of
|
|
|
964 pointer-to-function types.
|
|
|
965
|
|
|
966 @item
|
|
|
967 Using @command{unprotoize} can easily introduce bugs. If the program
|
|
|
968 relied on prototypes to bring about conversion of arguments, these
|
|
|
969 conversions will not take place in the program without prototypes.
|
|
|
970 One case in which you can be sure @command{unprotoize} is safe is when
|
|
|
971 you are removing prototypes that were made with @command{protoize}; if
|
|
|
972 the program worked before without any prototypes, it will work again
|
|
|
973 without them.
|
|
|
974
|
|
|
975 @opindex Wtraditional-conversion
|
|
|
976 You can find all the places where this problem might occur by compiling
|
|
|
977 the program with the @option{-Wtraditional-conversion} option. It
|
|
|
978 prints a warning whenever an argument is converted.
|
|
|
979
|
|
|
980 @item
|
|
|
981 Both conversion programs can be confused if there are macro calls in and
|
|
|
982 around the text to be converted. In other words, the standard syntax
|
|
|
983 for a declaration or definition must not result from expanding a macro.
|
|
|
984 This problem is inherent in the design of C and cannot be fixed. If
|
|
|
985 only a few functions have confusing macro calls, you can easily convert
|
|
|
986 them manually.
|
|
|
987
|
|
|
988 @item
|
|
|
989 @command{protoize} cannot get the argument types for a function whose
|
|
|
990 definition was not actually compiled due to preprocessing conditionals.
|
|
|
991 When this happens, @command{protoize} changes nothing in regard to such
|
|
|
992 a function. @command{protoize} tries to detect such instances and warn
|
|
|
993 about them.
|
|
|
994
|
|
|
995 You can generally work around this problem by using @command{protoize} step
|
|
|
996 by step, each time specifying a different set of @option{-D} options for
|
|
|
997 compilation, until all of the functions have been converted. There is
|
|
|
998 no automatic way to verify that you have got them all, however.
|
|
|
999
|
|
|
1000 @item
|
|
|
1001 Confusion may result if there is an occasion to convert a function
|
|
|
1002 declaration or definition in a region of source code where there is more
|
|
|
1003 than one formal parameter list present. Thus, attempts to convert code
|
|
|
1004 containing multiple (conditionally compiled) versions of a single
|
|
|
1005 function header (in the same vicinity) may not produce the desired (or
|
|
|
1006 expected) results.
|
|
|
1007
|
|
|
1008 If you plan on converting source files which contain such code, it is
|
|
|
1009 recommended that you first make sure that each conditionally compiled
|
|
|
1010 region of source code which contains an alternative function header also
|
|
|
1011 contains at least one additional follower token (past the final right
|
|
|
1012 parenthesis of the function header). This should circumvent the
|
|
|
1013 problem.
|
|
|
1014
|
|
|
1015 @item
|
|
|
1016 @command{unprotoize} can become confused when trying to convert a function
|
|
|
1017 definition or declaration which contains a declaration for a
|
|
|
1018 pointer-to-function formal argument which has the same name as the
|
|
|
1019 function being defined or declared. We recommend you avoid such choices
|
|
|
1020 of formal parameter names.
|
|
|
1021
|
|
|
1022 @item
|
|
|
1023 You might also want to correct some of the indentation by hand and break
|
|
|
1024 long lines. (The conversion programs don't write lines longer than
|
|
|
1025 eighty characters in any case.)
|
|
|
1026 @end itemize
|
|
|
1027
|
|
|
1028 @node Non-bugs
|
|
|
1029 @section Certain Changes We Don't Want to Make
|
|
|
1030
|
|
|
1031 This section lists changes that people frequently request, but which
|
|
|
1032 we do not make because we think GCC is better without them.
|
|
|
1033
|
|
|
1034 @itemize @bullet
|
|
|
1035 @item
|
|
|
1036 Checking the number and type of arguments to a function which has an
|
|
|
1037 old-fashioned definition and no prototype.
|
|
|
1038
|
|
|
1039 Such a feature would work only occasionally---only for calls that appear
|
|
|
1040 in the same file as the called function, following the definition. The
|
|
|
1041 only way to check all calls reliably is to add a prototype for the
|
|
|
1042 function. But adding a prototype eliminates the motivation for this
|
|
|
1043 feature. So the feature is not worthwhile.
|
|
|
1044
|
|
|
1045 @item
|
|
|
1046 Warning about using an expression whose type is signed as a shift count.
|
|
|
1047
|
|
|
1048 Shift count operands are probably signed more often than unsigned.
|
|
|
1049 Warning about this would cause far more annoyance than good.
|
|
|
1050
|
|
|
1051 @item
|
|
|
1052 Warning about assigning a signed value to an unsigned variable.
|
|
|
1053
|
|
|
1054 Such assignments must be very common; warning about them would cause
|
|
|
1055 more annoyance than good.
|
|
|
1056
|
|
|
1057 @item
|
|
|
1058 Warning when a non-void function value is ignored.
|
|
|
1059
|
|
|
1060 C contains many standard functions that return a value that most
|
|
|
1061 programs choose to ignore. One obvious example is @code{printf}.
|
|
|
1062 Warning about this practice only leads the defensive programmer to
|
|
|
1063 clutter programs with dozens of casts to @code{void}. Such casts are
|
|
|
1064 required so frequently that they become visual noise. Writing those
|
|
|
1065 casts becomes so automatic that they no longer convey useful
|
|
|
1066 information about the intentions of the programmer. For functions
|
|
|
1067 where the return value should never be ignored, use the
|
|
|
1068 @code{warn_unused_result} function attribute (@pxref{Function
|
|
|
1069 Attributes}).
|
|
|
1070
|
|
|
1071 @item
|
|
|
1072 @opindex fshort-enums
|
|
|
1073 Making @option{-fshort-enums} the default.
|
|
|
1074
|
|
|
1075 This would cause storage layout to be incompatible with most other C
|
|
|
1076 compilers. And it doesn't seem very important, given that you can get
|
|
|
1077 the same result in other ways. The case where it matters most is when
|
|
|
1078 the enumeration-valued object is inside a structure, and in that case
|
|
|
1079 you can specify a field width explicitly.
|
|
|
1080
|
|
|
1081 @item
|
|
|
1082 Making bit-fields unsigned by default on particular machines where ``the
|
|
|
1083 ABI standard'' says to do so.
|
|
|
1084
|
|
|
1085 The ISO C standard leaves it up to the implementation whether a bit-field
|
|
|
1086 declared plain @code{int} is signed or not. This in effect creates two
|
|
|
1087 alternative dialects of C@.
|
|
|
1088
|
|
|
1089 @opindex fsigned-bitfields
|
|
|
1090 @opindex funsigned-bitfields
|
|
|
1091 The GNU C compiler supports both dialects; you can specify the signed
|
|
|
1092 dialect with @option{-fsigned-bitfields} and the unsigned dialect with
|
|
|
1093 @option{-funsigned-bitfields}. However, this leaves open the question of
|
|
|
1094 which dialect to use by default.
|
|
|
1095
|
|
|
1096 Currently, the preferred dialect makes plain bit-fields signed, because
|
|
|
1097 this is simplest. Since @code{int} is the same as @code{signed int} in
|
|
|
1098 every other context, it is cleanest for them to be the same in bit-fields
|
|
|
1099 as well.
|
|
|
1100
|
|
|
1101 Some computer manufacturers have published Application Binary Interface
|
|
|
1102 standards which specify that plain bit-fields should be unsigned. It is
|
|
|
1103 a mistake, however, to say anything about this issue in an ABI@. This is
|
|
|
1104 because the handling of plain bit-fields distinguishes two dialects of C@.
|
|
|
1105 Both dialects are meaningful on every type of machine. Whether a
|
|
|
1106 particular object file was compiled using signed bit-fields or unsigned
|
|
|
1107 is of no concern to other object files, even if they access the same
|
|
|
1108 bit-fields in the same data structures.
|
|
|
1109
|
|
|
1110 A given program is written in one or the other of these two dialects.
|
|
|
1111 The program stands a chance to work on most any machine if it is
|
|
|
1112 compiled with the proper dialect. It is unlikely to work at all if
|
|
|
1113 compiled with the wrong dialect.
|
|
|
1114
|
|
|
1115 Many users appreciate the GNU C compiler because it provides an
|
|
|
1116 environment that is uniform across machines. These users would be
|
|
|
1117 inconvenienced if the compiler treated plain bit-fields differently on
|
|
|
1118 certain machines.
|
|
|
1119
|
|
|
1120 Occasionally users write programs intended only for a particular machine
|
|
|
1121 type. On these occasions, the users would benefit if the GNU C compiler
|
|
|
1122 were to support by default the same dialect as the other compilers on
|
|
|
1123 that machine. But such applications are rare. And users writing a
|
|
|
1124 program to run on more than one type of machine cannot possibly benefit
|
|
|
1125 from this kind of compatibility.
|
|
|
1126
|
|
|
1127 This is why GCC does and will treat plain bit-fields in the same
|
|
|
1128 fashion on all types of machines (by default).
|
|
|
1129
|
|
|
1130 There are some arguments for making bit-fields unsigned by default on all
|
|
|
1131 machines. If, for example, this becomes a universal de facto standard,
|
|
|
1132 it would make sense for GCC to go along with it. This is something
|
|
|
1133 to be considered in the future.
|
|
|
1134
|
|
|
1135 (Of course, users strongly concerned about portability should indicate
|
|
|
1136 explicitly in each bit-field whether it is signed or not. In this way,
|
|
|
1137 they write programs which have the same meaning in both C dialects.)
|
|
|
1138
|
|
|
1139 @item
|
|
|
1140 @opindex ansi
|
|
|
1141 @opindex std
|
|
|
1142 Undefining @code{__STDC__} when @option{-ansi} is not used.
|
|
|
1143
|
|
|
1144 Currently, GCC defines @code{__STDC__} unconditionally. This provides
|
|
|
1145 good results in practice.
|
|
|
1146
|
|
|
1147 Programmers normally use conditionals on @code{__STDC__} to ask whether
|
|
|
1148 it is safe to use certain features of ISO C, such as function
|
|
|
1149 prototypes or ISO token concatenation. Since plain @command{gcc} supports
|
|
|
1150 all the features of ISO C, the correct answer to these questions is
|
|
|
1151 ``yes''.
|
|
|
1152
|
|
|
1153 Some users try to use @code{__STDC__} to check for the availability of
|
|
|
1154 certain library facilities. This is actually incorrect usage in an ISO
|
|
|
1155 C program, because the ISO C standard says that a conforming
|
|
|
1156 freestanding implementation should define @code{__STDC__} even though it
|
|
|
1157 does not have the library facilities. @samp{gcc -ansi -pedantic} is a
|
|
|
1158 conforming freestanding implementation, and it is therefore required to
|
|
|
1159 define @code{__STDC__}, even though it does not come with an ISO C
|
|
|
1160 library.
|
|
|
1161
|
|
|
1162 Sometimes people say that defining @code{__STDC__} in a compiler that
|
|
|
1163 does not completely conform to the ISO C standard somehow violates the
|
|
|
1164 standard. This is illogical. The standard is a standard for compilers
|
|
|
1165 that claim to support ISO C, such as @samp{gcc -ansi}---not for other
|
|
|
1166 compilers such as plain @command{gcc}. Whatever the ISO C standard says
|
|
|
1167 is relevant to the design of plain @command{gcc} without @option{-ansi} only
|
|
|
1168 for pragmatic reasons, not as a requirement.
|
|
|
1169
|
|
|
1170 GCC normally defines @code{__STDC__} to be 1, and in addition
|
|
|
1171 defines @code{__STRICT_ANSI__} if you specify the @option{-ansi} option,
|
|
|
1172 or a @option{-std} option for strict conformance to some version of ISO C@.
|
|
|
1173 On some hosts, system include files use a different convention, where
|
|
|
1174 @code{__STDC__} is normally 0, but is 1 if the user specifies strict
|
|
|
1175 conformance to the C Standard. GCC follows the host convention when
|
|
|
1176 processing system include files, but when processing user files it follows
|
|
|
1177 the usual GNU C convention.
|
|
|
1178
|
|
|
1179 @item
|
|
|
1180 Undefining @code{__STDC__} in C++.
|
|
|
1181
|
|
|
1182 Programs written to compile with C++-to-C translators get the
|
|
|
1183 value of @code{__STDC__} that goes with the C compiler that is
|
|
|
1184 subsequently used. These programs must test @code{__STDC__}
|
|
|
1185 to determine what kind of C preprocessor that compiler uses:
|
|
|
1186 whether they should concatenate tokens in the ISO C fashion
|
|
|
1187 or in the traditional fashion.
|
|
|
1188
|
|
|
1189 These programs work properly with GNU C++ if @code{__STDC__} is defined.
|
|
|
1190 They would not work otherwise.
|
|
|
1191
|
|
|
1192 In addition, many header files are written to provide prototypes in ISO
|
|
|
1193 C but not in traditional C@. Many of these header files can work without
|
|
|
1194 change in C++ provided @code{__STDC__} is defined. If @code{__STDC__}
|
|
|
1195 is not defined, they will all fail, and will all need to be changed to
|
|
|
1196 test explicitly for C++ as well.
|
|
|
1197
|
|
|
1198 @item
|
|
|
1199 Deleting ``empty'' loops.
|
|
|
1200
|
|
|
1201 Historically, GCC has not deleted ``empty'' loops under the
|
|
|
1202 assumption that the most likely reason you would put one in a program is
|
|
|
1203 to have a delay, so deleting them will not make real programs run any
|
|
|
1204 faster.
|
|
|
1205
|
|
|
1206 However, the rationale here is that optimization of a nonempty loop
|
|
|
1207 cannot produce an empty one. This held for carefully written C compiled
|
|
|
1208 with less powerful optimizers but is not always the case for carefully
|
|
|
1209 written C++ or with more powerful optimizers.
|
|
|
1210 Thus GCC will remove operations from loops whenever it can determine
|
|
|
1211 those operations are not externally visible (apart from the time taken
|
|
|
1212 to execute them, of course). In case the loop can be proved to be finite,
|
|
|
1213 GCC will also remove the loop itself.
|
|
|
1214
|
|
|
1215 Be aware of this when performing timing tests, for instance the
|
|
|
1216 following loop can be completely removed, provided
|
|
|
1217 @code{some_expression} can provably not change any global state.
|
|
|
1218
|
|
|
1219 @smallexample
|
|
|
1220 @{
|
|
|
1221 int sum = 0;
|
|
|
1222 int ix;
|
|
|
1223
|
|
|
1224 for (ix = 0; ix != 10000; ix++)
|
|
|
1225 sum += some_expression;
|
|
|
1226 @}
|
|
|
1227 @end smallexample
|
|
|
1228
|
|
|
1229 Even though @code{sum} is accumulated in the loop, no use is made of
|
|
|
1230 that summation, so the accumulation can be removed.
|
|
|
1231
|
|
|
1232 @item
|
|
|
1233 Making side effects happen in the same order as in some other compiler.
|
|
|
1234
|
|
|
1235 @cindex side effects, order of evaluation
|
|
|
1236 @cindex order of evaluation, side effects
|
|
|
1237 It is never safe to depend on the order of evaluation of side effects.
|
|
|
1238 For example, a function call like this may very well behave differently
|
|
|
1239 from one compiler to another:
|
|
|
1240
|
|
|
1241 @smallexample
|
|
|
1242 void func (int, int);
|
|
|
1243
|
|
|
1244 int i = 2;
|
|
|
1245 func (i++, i++);
|
|
|
1246 @end smallexample
|
|
|
1247
|
|
|
1248 There is no guarantee (in either the C or the C++ standard language
|
|
|
1249 definitions) that the increments will be evaluated in any particular
|
|
|
1250 order. Either increment might happen first. @code{func} might get the
|
|
|
1251 arguments @samp{2, 3}, or it might get @samp{3, 2}, or even @samp{2, 2}.
|
|
|
1252
|
|
|
1253 @item
|
|
|
1254 Making certain warnings into errors by default.
|
|
|
1255
|
|
|
1256 Some ISO C testsuites report failure when the compiler does not produce
|
|
|
1257 an error message for a certain program.
|
|
|
1258
|
|
|
1259 @opindex pedantic-errors
|
|
|
1260 ISO C requires a ``diagnostic'' message for certain kinds of invalid
|
|
|
1261 programs, but a warning is defined by GCC to count as a diagnostic. If
|
|
|
1262 GCC produces a warning but not an error, that is correct ISO C support.
|
|
|
1263 If testsuites call this ``failure'', they should be run with the GCC
|
|
|
1264 option @option{-pedantic-errors}, which will turn these warnings into
|
|
|
1265 errors.
|
|
|
1266
|
|
|
1267 @end itemize
|
|
|
1268
|
|
|
1269 @node Warnings and Errors
|
|
|
1270 @section Warning Messages and Error Messages
|
|
|
1271
|
|
|
1272 @cindex error messages
|
|
|
1273 @cindex warnings vs errors
|
|
|
1274 @cindex messages, warning and error
|
|
|
1275 The GNU compiler can produce two kinds of diagnostics: errors and
|
|
|
1276 warnings. Each kind has a different purpose:
|
|
|
1277
|
|
|
1278 @itemize @w{}
|
|
|
1279 @item
|
|
|
1280 @dfn{Errors} report problems that make it impossible to compile your
|
|
|
1281 program. GCC reports errors with the source file name and line
|
|
|
1282 number where the problem is apparent.
|
|
|
1283
|
|
|
1284 @item
|
|
|
1285 @dfn{Warnings} report other unusual conditions in your code that
|
|
|
1286 @emph{may} indicate a problem, although compilation can (and does)
|
|
|
1287 proceed. Warning messages also report the source file name and line
|
|
|
1288 number, but include the text @samp{warning:} to distinguish them
|
|
|
1289 from error messages.
|
|
|
1290 @end itemize
|
|
|
1291
|
|
|
1292 Warnings may indicate danger points where you should check to make sure
|
|
|
1293 that your program really does what you intend; or the use of obsolete
|
|
|
1294 features; or the use of nonstandard features of GNU C or C++. Many
|
|
|
1295 warnings are issued only if you ask for them, with one of the @option{-W}
|
|
|
1296 options (for instance, @option{-Wall} requests a variety of useful
|
|
|
1297 warnings).
|
|
|
1298
|
|
|
1299 @opindex pedantic
|
|
|
1300 @opindex pedantic-errors
|
|
|
1301 GCC always tries to compile your program if possible; it never
|
|
|
1302 gratuitously rejects a program whose meaning is clear merely because
|
|
|
1303 (for instance) it fails to conform to a standard. In some cases,
|
|
|
1304 however, the C and C++ standards specify that certain extensions are
|
|
|
1305 forbidden, and a diagnostic @emph{must} be issued by a conforming
|
|
|
1306 compiler. The @option{-pedantic} option tells GCC to issue warnings in
|
|
|
1307 such cases; @option{-pedantic-errors} says to make them errors instead.
|
|
|
1308 This does not mean that @emph{all} non-ISO constructs get warnings
|
|
|
1309 or errors.
|
|
|
1310
|
|
|
1311 @xref{Warning Options,,Options to Request or Suppress Warnings}, for
|
|
|
1312 more detail on these and related command-line options.
|
