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