]>
Commit | Line | Data |
---|---|---|
99dee823 | 1 | @c Copyright (C) 1988-2021 Free Software Foundation, Inc. |
b64a6a11 JM |
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 | |
6ccde948 | 20 | * Actual Bugs:: Bugs we will fix later. |
b64a6a11 | 21 | * Interoperation:: Problems using GCC with other compilers, |
6ccde948 | 22 | and with certain linkers, assemblers and debuggers. |
b64a6a11 JM |
23 | * Incompatibilities:: GCC is incompatible with traditional C. |
24 | * Fixed Headers:: GCC uses corrected versions of system header files. | |
6ccde948 | 25 | This is necessary, but doesn't always work smoothly. |
b64a6a11 | 26 | * Standard Libraries:: GCC uses the system C library, which might not be |
6ccde948 | 27 | compliant with the ISO C standard. |
fd250f0d | 28 | * Disappointments:: Regrettable things we cannot change, but not quite bugs. |
6ccde948 | 29 | * C++ Misunderstandings:: Common misunderstandings with GNU C++. |
6ccde948 | 30 | * Non-bugs:: Things we think are right, but some others disagree. |
b64a6a11 | 31 | * Warnings and Errors:: Which problems in your code get warnings, |
6ccde948 | 32 | and which get errors. |
b64a6a11 JM |
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. | |
b64a6a11 JM |
44 | @end itemize |
45 | ||
b64a6a11 JM |
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 | |
b64a6a11 | 54 | @item |
0484cb35 JJ |
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. | |
b64a6a11 | 58 | |
0484cb35 JJ |
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. | |
b64a6a11 JM |
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 | ||
b64a6a11 JM |
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 | ||
b64a6a11 | 75 | @item |
981f6289 | 76 | On a SPARC, GCC aligns all values of type @code{double} on an 8-byte |
b64a6a11 JM |
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 | |
981f6289 | 115 | SPARC assumes that doubles are 8 byte aligned, this may result in a |
b64a6a11 JM |
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 | ||
b64a6a11 JM |
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 | |
598f4c4c | 132 | the preliminary GNU tools. |
b64a6a11 JM |
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 | ||
2705baf5 DE |
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 | |
8a36672b | 179 | application. Applications are not required to use the |
2705baf5 DE |
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 | ||
08882783 DE |
184 | @item |
185 | An application can interpose its own definition of functions for | |
186 | functions invoked by @file{libstdc++.a} with ``runtime-linking'' | |
8a36672b | 187 | enabled on AIX@. To accomplish this the application must be linked |
08882783 DE |
188 | with ``runtime-linking'' option and the functions explicitly must be |
189 | exported by the application (@option{-Wl,-brtl,-bE:exportfile}). | |
190 | ||
b64a6a11 JM |
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 | |
2705baf5 | 195 | floating-point numbers (@samp{.} vs @samp{,} for separating decimal |
8a36672b | 196 | fractions). There have been problems reported where the library linked |
2705baf5 | 197 | with GCC does not produce the same floating-point formats that the |
8a36672b | 198 | assembler accepts. If you have this problem, set the @env{LANG} |
2705baf5 | 199 | environment variable to @samp{C} or @samp{En_US}. |
b64a6a11 JM |
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 | ||
b64a6a11 JM |
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 | |
f458d1d5 | 216 | (non-ISO) versions of C@. |
b64a6a11 JM |
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 | |
3521b33c ZW |
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}. | |
b64a6a11 | 239 | |
3521b33c | 240 | The solution to these problems is to change the program to use |
b64a6a11 | 241 | @code{char}-array variables with initialization strings for these |
3521b33c | 242 | purposes instead of string constants. |
b64a6a11 JM |
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 | ||
3ab51846 | 255 | @smallexample |
b64a6a11 | 256 | #define foo(a) "a" |
3ab51846 | 257 | @end smallexample |
b64a6a11 JM |
258 | |
259 | @noindent | |
260 | will produce output @code{"a"} regardless of what the argument @var{a} is. | |
261 | ||
b64a6a11 JM |
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 | ||
3ab51846 | 270 | @smallexample |
b64a6a11 JM |
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 | @} | |
3ab51846 | 285 | @end smallexample |
b64a6a11 JM |
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 | ||
b64a6a11 JM |
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 | ||
3ab51846 | 301 | @smallexample |
b64a6a11 JM |
302 | @group |
303 | foobar ( | |
304 | #define luser | |
305 | hack) | |
306 | @end group | |
3ab51846 | 307 | @end smallexample |
b64a6a11 | 308 | |
f458d1d5 | 309 | ISO C does not permit such a construct. |
b64a6a11 JM |
310 | |
311 | @item | |
312 | K&R compilers allow comments to cross over an inclusion boundary | |
962e6e00 | 313 | (i.e.@: started in an include file and ended in the including file). |
b64a6a11 JM |
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 | ||
e4ae5e77 | 323 | In some other C compilers, an @code{extern} declaration affects all the |
b64a6a11 JM |
324 | rest of the file even if it happens within a block. |
325 | ||
b64a6a11 JM |
326 | @item |
327 | In traditional C, you can combine @code{long}, etc., with a typedef name, | |
328 | as shown here: | |
329 | ||
3ab51846 | 330 | @smallexample |
b64a6a11 JM |
331 | typedef int foo; |
332 | typedef long foo bar; | |
3ab51846 | 333 | @end smallexample |
b64a6a11 JM |
334 | |
335 | In ISO C, this is not allowed: @code{long} and other type modifiers | |
f458d1d5 | 336 | require an explicit @code{int}. |
b64a6a11 JM |
337 | |
338 | @cindex typedef names as function parameters | |
339 | @item | |
f458d1d5 | 340 | PCC allows typedef names to be used as function parameters. |
b64a6a11 JM |
341 | |
342 | @item | |
f458d1d5 ZW |
343 | Traditional C allows the following erroneous pair of declarations to |
344 | appear together in a given scope: | |
b64a6a11 | 345 | |
3ab51846 | 346 | @smallexample |
b64a6a11 JM |
347 | typedef int foo; |
348 | typedef foo foo; | |
3ab51846 | 349 | @end smallexample |
b64a6a11 JM |
350 | |
351 | @item | |
f458d1d5 ZW |
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. | |
b64a6a11 JM |
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 | |
f458d1d5 | 363 | allow this. |
b64a6a11 JM |
364 | |
365 | @cindex apostrophes | |
ab940b73 | 366 | @cindex @code{'} |
b64a6a11 JM |
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 | ||
3ab51846 | 374 | @smallexample |
b64a6a11 JM |
375 | #if 0 |
376 | You can't expect this to work. | |
377 | #endif | |
3ab51846 | 378 | @end smallexample |
b64a6a11 JM |
379 | |
380 | The best solution to such a problem is to put the text into an actual | |
f458d1d5 | 381 | C comment delimited by @samp{/*@dots{}*/}. |
b64a6a11 JM |
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 | |
cea28603 KH |
415 | on the stack). The target hook @code{TARGET_STRUCT_VALUE_RTX} |
416 | tells GCC where to pass this address. | |
b64a6a11 JM |
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+}, | |
7e1542b9 | 448 | @samp{p-}, @samp{P+}, or @samp{P-} character sequences. (In strict C90 |
b64a6a11 JM |
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 | |
60ae6360 | 466 | files, by running a program called @code{fixincludes}. Normally, you |
b64a6a11 JM |
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 | |
60ae6360 JM |
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/}. | |
b64a6a11 JM |
477 | |
478 | @item | |
60ae6360 | 479 | On some systems, header file directories contain |
b64a6a11 JM |
480 | machine-specific symbolic links in certain places. This makes it |
481 | possible to share most of the header files among hosts running the | |
60ae6360 | 482 | same version of the system on different machine models. |
b64a6a11 JM |
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 | ||
b64a6a11 JM |
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. | |
b64a6a11 JM |
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 | ||
3ab51846 | 545 | @smallexample |
b64a6a11 JM |
546 | int foo (struct mumble *); |
547 | ||
548 | struct mumble @{ @dots{} @}; | |
549 | ||
550 | int foo (struct mumble *x) | |
551 | @{ @dots{} @} | |
3ab51846 | 552 | @end smallexample |
b64a6a11 JM |
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 | |
60ae6360 JM |
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/}. | |
b64a6a11 JM |
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 | ||
2705baf5 DE |
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. | |
032613df DE |
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. | |
48c1db3d DE |
618 | This may lead to both increased executable size and unexpected symbol |
619 | references. | |
b64a6a11 JM |
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 | |
83205b9b | 636 | * Name lookup:: Name lookup, templates, and accessing members of base classes |
b64a6a11 JM |
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 | ||
3ab51846 | 651 | @smallexample |
b64a6a11 JM |
652 | class Foo |
653 | @{ | |
654 | @dots{} | |
655 | void method(); | |
656 | static int bar; | |
657 | @}; | |
3ab51846 | 658 | @end smallexample |
b64a6a11 JM |
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 | ||
3ab51846 | 667 | @smallexample |
b64a6a11 | 668 | int Foo::bar = 0; |
3ab51846 | 669 | @end smallexample |
b64a6a11 JM |
670 | |
671 | Other C++ compilers may not correctly implement the standard behavior. | |
05739753 | 672 | As a result, when you switch to @command{g++} from one of these compilers, |
b64a6a11 | 673 | you may discover that a program that appeared to work correctly in fact |
05739753 | 674 | does not conform to the standard: @command{g++} reports as undefined |
b64a6a11 JM |
675 | symbols any static data members that lack definitions. |
676 | ||
83205b9b WB |
677 | |
678 | @node Name lookup | |
e6f3f526 | 679 | @subsection Name Lookup, Templates, and Accessing Members of Base Classes |
83205b9b WB |
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 | ||
3ab51846 | 693 | @smallexample |
83205b9b WB |
694 | void foo(double); |
695 | ||
696 | struct A @{ | |
697 | template <typename T> | |
698 | void f () @{ | |
cd1a8088 JM |
699 | foo (1); // @r{1} |
700 | int i = N; // @r{2} | |
83205b9b | 701 | T t; |
cd1a8088 JM |
702 | t.bar(); // @r{3} |
703 | foo (t); // @r{4} | |
83205b9b WB |
704 | @} |
705 | ||
706 | static const int N; | |
707 | @}; | |
3ab51846 | 708 | @end smallexample |
83205b9b WB |
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 | |
5cf0212f WB |
726 | called two-stage (or dependent) name lookup. G++ implements it |
727 | since version 3.4. | |
83205b9b WB |
728 | |
729 | Two-stage name lookup sometimes leads to situations with behavior | |
8a36672b | 730 | different from non-template codes. The most common is probably this: |
83205b9b | 731 | |
3ab51846 | 732 | @smallexample |
83205b9b WB |
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 | @}; | |
3ab51846 | 740 | @end smallexample |
83205b9b WB |
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 | |
fd250f0d | 746 | @code{Base} even after declaring @code{Derived}, so the compiler cannot |
83205b9b WB |
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 | |
8a36672b | 755 | @code{Base<T>::i}. Alternatively, @code{Base<T>::i} might be brought |
83205b9b WB |
756 | into scope by a @code{using}-declaration. |
757 | ||
5cf0212f | 758 | Another, similar example involves calling member functions of a base |
daf2f129 | 759 | class: |
5cf0212f | 760 | |
3ab51846 | 761 | @smallexample |
5cf0212f WB |
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 | @}; | |
3ab51846 | 769 | @end smallexample |
5cf0212f WB |
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 | ||
3ab51846 | 778 | @smallexample |
5cf0212f WB |
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) | |
3ab51846 | 784 | @end smallexample |
5cf0212f WB |
785 | |
786 | To make the code valid either use @code{this->f()}, or | |
4ec7afd7 | 787 | @code{Base<T>::f()}. Using the @option{-fpermissive} flag will also let |
5cf0212f WB |
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. | |
4ec7afd7 | 791 | We do not recommend using @option{-fpermissive} to work around invalid |
5cf0212f WB |
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. | |
83205b9b WB |
799 | |
800 | ||
b64a6a11 JM |
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 | ||
3ab51846 | 820 | @smallexample |
b64a6a11 JM |
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 | @} | |
3ab51846 | 833 | @end smallexample |
b64a6a11 JM |
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 | ||
3ab51846 | 852 | @smallexample |
748fa294 | 853 | const string& tmp = strfunc (); |
b64a6a11 | 854 | charfunc (tmp.c_str ()); |
3ab51846 | 855 | @end smallexample |
b64a6a11 JM |
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 | ||
3ab51846 | 865 | @smallexample |
b64a6a11 JM |
866 | struct Base@{ |
867 | char *name; | |
3c645823 | 868 | Base(const char *n) : name(strdup(n))@{@} |
b64a6a11 JM |
869 | Base& operator= (const Base& other)@{ |
870 | free (name); | |
871 | name = strdup (other.name); | |
3c645823 | 872 | return *this; |
b64a6a11 JM |
873 | @} |
874 | @}; | |
875 | ||
876 | struct A:virtual Base@{ | |
877 | int val; | |
878 | A():Base("A")@{@} | |
879 | @}; | |
880 | ||
881 | struct B:virtual Base@{ | |
882 | int bval; | |
883 | B():Base("B")@{@} | |
884 | @}; | |
885 | ||
886 | struct Derived:public A, public B@{ | |
887 | Derived():Base("Derived")@{@} | |
888 | @}; | |
889 | ||
890 | void func(Derived &d1, Derived &d2) | |
891 | @{ | |
892 | d1 = d2; | |
893 | @} | |
3ab51846 | 894 | @end smallexample |
b64a6a11 JM |
895 | |
896 | The C++ standard specifies that @samp{Base::Base} is only called once | |
897 | when constructing or copy-constructing a Derived object. It is | |
898 | unspecified whether @samp{Base::operator=} is called more than once when | |
899 | the implicit copy-assignment for Derived objects is invoked (as it is | |
900 | inside @samp{func} in the example). | |
901 | ||
2dd76960 | 902 | G++ implements the ``intuitive'' algorithm for copy-assignment: assign all |
b64a6a11 | 903 | direct bases, then assign all members. In that algorithm, the virtual |
83205b9b | 904 | base subobject can be encountered more than once. In the example, copying |
3c645823 JW |
905 | proceeds in the following order: @samp{name} (via @code{strdup}), |
906 | @samp{val}, @samp{name} again, and @samp{bval}. | |
b64a6a11 JM |
907 | |
908 | If application code relies on copy-assignment, a user-defined | |
909 | copy-assignment operator removes any uncertainties. With such an | |
910 | operator, the application can define whether and how the virtual base | |
911 | subobject is assigned. | |
912 | ||
b64a6a11 JM |
913 | @node Non-bugs |
914 | @section Certain Changes We Don't Want to Make | |
915 | ||
916 | This section lists changes that people frequently request, but which | |
917 | we do not make because we think GCC is better without them. | |
918 | ||
919 | @itemize @bullet | |
920 | @item | |
921 | Checking the number and type of arguments to a function which has an | |
922 | old-fashioned definition and no prototype. | |
923 | ||
924 | Such a feature would work only occasionally---only for calls that appear | |
925 | in the same file as the called function, following the definition. The | |
926 | only way to check all calls reliably is to add a prototype for the | |
927 | function. But adding a prototype eliminates the motivation for this | |
928 | feature. So the feature is not worthwhile. | |
929 | ||
930 | @item | |
931 | Warning about using an expression whose type is signed as a shift count. | |
932 | ||
933 | Shift count operands are probably signed more often than unsigned. | |
934 | Warning about this would cause far more annoyance than good. | |
935 | ||
936 | @item | |
937 | Warning about assigning a signed value to an unsigned variable. | |
938 | ||
939 | Such assignments must be very common; warning about them would cause | |
940 | more annoyance than good. | |
941 | ||
942 | @item | |
943 | Warning when a non-void function value is ignored. | |
944 | ||
962e6e00 JM |
945 | C contains many standard functions that return a value that most |
946 | programs choose to ignore. One obvious example is @code{printf}. | |
947 | Warning about this practice only leads the defensive programmer to | |
948 | clutter programs with dozens of casts to @code{void}. Such casts are | |
949 | required so frequently that they become visual noise. Writing those | |
950 | casts becomes so automatic that they no longer convey useful | |
951 | information about the intentions of the programmer. For functions | |
952 | where the return value should never be ignored, use the | |
953 | @code{warn_unused_result} function attribute (@pxref{Function | |
954 | Attributes}). | |
b64a6a11 JM |
955 | |
956 | @item | |
957 | @opindex fshort-enums | |
958 | Making @option{-fshort-enums} the default. | |
959 | ||
960 | This would cause storage layout to be incompatible with most other C | |
961 | compilers. And it doesn't seem very important, given that you can get | |
962 | the same result in other ways. The case where it matters most is when | |
963 | the enumeration-valued object is inside a structure, and in that case | |
964 | you can specify a field width explicitly. | |
965 | ||
966 | @item | |
967 | Making bit-fields unsigned by default on particular machines where ``the | |
968 | ABI standard'' says to do so. | |
969 | ||
970 | The ISO C standard leaves it up to the implementation whether a bit-field | |
971 | declared plain @code{int} is signed or not. This in effect creates two | |
972 | alternative dialects of C@. | |
973 | ||
974 | @opindex fsigned-bitfields | |
975 | @opindex funsigned-bitfields | |
976 | The GNU C compiler supports both dialects; you can specify the signed | |
977 | dialect with @option{-fsigned-bitfields} and the unsigned dialect with | |
978 | @option{-funsigned-bitfields}. However, this leaves open the question of | |
979 | which dialect to use by default. | |
980 | ||
981 | Currently, the preferred dialect makes plain bit-fields signed, because | |
982 | this is simplest. Since @code{int} is the same as @code{signed int} in | |
983 | every other context, it is cleanest for them to be the same in bit-fields | |
984 | as well. | |
985 | ||
986 | Some computer manufacturers have published Application Binary Interface | |
987 | standards which specify that plain bit-fields should be unsigned. It is | |
988 | a mistake, however, to say anything about this issue in an ABI@. This is | |
989 | because the handling of plain bit-fields distinguishes two dialects of C@. | |
990 | Both dialects are meaningful on every type of machine. Whether a | |
991 | particular object file was compiled using signed bit-fields or unsigned | |
992 | is of no concern to other object files, even if they access the same | |
993 | bit-fields in the same data structures. | |
994 | ||
995 | A given program is written in one or the other of these two dialects. | |
996 | The program stands a chance to work on most any machine if it is | |
997 | compiled with the proper dialect. It is unlikely to work at all if | |
998 | compiled with the wrong dialect. | |
999 | ||
1000 | Many users appreciate the GNU C compiler because it provides an | |
1001 | environment that is uniform across machines. These users would be | |
1002 | inconvenienced if the compiler treated plain bit-fields differently on | |
1003 | certain machines. | |
1004 | ||
1005 | Occasionally users write programs intended only for a particular machine | |
1006 | type. On these occasions, the users would benefit if the GNU C compiler | |
1007 | were to support by default the same dialect as the other compilers on | |
1008 | that machine. But such applications are rare. And users writing a | |
1009 | program to run on more than one type of machine cannot possibly benefit | |
1010 | from this kind of compatibility. | |
1011 | ||
1012 | This is why GCC does and will treat plain bit-fields in the same | |
1013 | fashion on all types of machines (by default). | |
1014 | ||
1015 | There are some arguments for making bit-fields unsigned by default on all | |
1016 | machines. If, for example, this becomes a universal de facto standard, | |
1017 | it would make sense for GCC to go along with it. This is something | |
1018 | to be considered in the future. | |
1019 | ||
1020 | (Of course, users strongly concerned about portability should indicate | |
1021 | explicitly in each bit-field whether it is signed or not. In this way, | |
1022 | they write programs which have the same meaning in both C dialects.) | |
1023 | ||
1024 | @item | |
1025 | @opindex ansi | |
b64a6a11 JM |
1026 | @opindex std |
1027 | Undefining @code{__STDC__} when @option{-ansi} is not used. | |
1028 | ||
f458d1d5 ZW |
1029 | Currently, GCC defines @code{__STDC__} unconditionally. This provides |
1030 | good results in practice. | |
b64a6a11 JM |
1031 | |
1032 | Programmers normally use conditionals on @code{__STDC__} to ask whether | |
1033 | it is safe to use certain features of ISO C, such as function | |
1034 | prototypes or ISO token concatenation. Since plain @command{gcc} supports | |
1035 | all the features of ISO C, the correct answer to these questions is | |
1036 | ``yes''. | |
1037 | ||
1038 | Some users try to use @code{__STDC__} to check for the availability of | |
1039 | certain library facilities. This is actually incorrect usage in an ISO | |
1040 | C program, because the ISO C standard says that a conforming | |
1041 | freestanding implementation should define @code{__STDC__} even though it | |
1042 | does not have the library facilities. @samp{gcc -ansi -pedantic} is a | |
1043 | conforming freestanding implementation, and it is therefore required to | |
1044 | define @code{__STDC__}, even though it does not come with an ISO C | |
1045 | library. | |
1046 | ||
1047 | Sometimes people say that defining @code{__STDC__} in a compiler that | |
1048 | does not completely conform to the ISO C standard somehow violates the | |
1049 | standard. This is illogical. The standard is a standard for compilers | |
1050 | that claim to support ISO C, such as @samp{gcc -ansi}---not for other | |
1051 | compilers such as plain @command{gcc}. Whatever the ISO C standard says | |
1052 | is relevant to the design of plain @command{gcc} without @option{-ansi} only | |
1053 | for pragmatic reasons, not as a requirement. | |
1054 | ||
1055 | GCC normally defines @code{__STDC__} to be 1, and in addition | |
1056 | defines @code{__STRICT_ANSI__} if you specify the @option{-ansi} option, | |
1057 | or a @option{-std} option for strict conformance to some version of ISO C@. | |
1058 | On some hosts, system include files use a different convention, where | |
1059 | @code{__STDC__} is normally 0, but is 1 if the user specifies strict | |
1060 | conformance to the C Standard. GCC follows the host convention when | |
1061 | processing system include files, but when processing user files it follows | |
1062 | the usual GNU C convention. | |
1063 | ||
1064 | @item | |
1065 | Undefining @code{__STDC__} in C++. | |
1066 | ||
1067 | Programs written to compile with C++-to-C translators get the | |
1068 | value of @code{__STDC__} that goes with the C compiler that is | |
1069 | subsequently used. These programs must test @code{__STDC__} | |
1070 | to determine what kind of C preprocessor that compiler uses: | |
1071 | whether they should concatenate tokens in the ISO C fashion | |
1072 | or in the traditional fashion. | |
1073 | ||
1074 | These programs work properly with GNU C++ if @code{__STDC__} is defined. | |
1075 | They would not work otherwise. | |
1076 | ||
1077 | In addition, many header files are written to provide prototypes in ISO | |
1078 | C but not in traditional C@. Many of these header files can work without | |
1079 | change in C++ provided @code{__STDC__} is defined. If @code{__STDC__} | |
1080 | is not defined, they will all fail, and will all need to be changed to | |
1081 | test explicitly for C++ as well. | |
1082 | ||
1083 | @item | |
1084 | Deleting ``empty'' loops. | |
1085 | ||
1086 | Historically, GCC has not deleted ``empty'' loops under the | |
1087 | assumption that the most likely reason you would put one in a program is | |
1088 | to have a delay, so deleting them will not make real programs run any | |
1089 | faster. | |
1090 | ||
1091 | However, the rationale here is that optimization of a nonempty loop | |
e6aef969 NS |
1092 | cannot produce an empty one. This held for carefully written C compiled |
1093 | with less powerful optimizers but is not always the case for carefully | |
1094 | written C++ or with more powerful optimizers. | |
e6aef969 NS |
1095 | Thus GCC will remove operations from loops whenever it can determine |
1096 | those operations are not externally visible (apart from the time taken | |
67135ef4 ZD |
1097 | to execute them, of course). In case the loop can be proved to be finite, |
1098 | GCC will also remove the loop itself. | |
e6aef969 NS |
1099 | |
1100 | Be aware of this when performing timing tests, for instance the | |
1101 | following loop can be completely removed, provided | |
1102 | @code{some_expression} can provably not change any global state. | |
1103 | ||
1104 | @smallexample | |
1105 | @{ | |
1106 | int sum = 0; | |
1107 | int ix; | |
1108 | ||
1109 | for (ix = 0; ix != 10000; ix++) | |
1110 | sum += some_expression; | |
1111 | @} | |
1112 | @end smallexample | |
1113 | ||
1114 | Even though @code{sum} is accumulated in the loop, no use is made of | |
1115 | that summation, so the accumulation can be removed. | |
b64a6a11 JM |
1116 | |
1117 | @item | |
1118 | Making side effects happen in the same order as in some other compiler. | |
1119 | ||
1120 | @cindex side effects, order of evaluation | |
1121 | @cindex order of evaluation, side effects | |
1122 | It is never safe to depend on the order of evaluation of side effects. | |
1123 | For example, a function call like this may very well behave differently | |
1124 | from one compiler to another: | |
1125 | ||
3ab51846 | 1126 | @smallexample |
b64a6a11 JM |
1127 | void func (int, int); |
1128 | ||
1129 | int i = 2; | |
1130 | func (i++, i++); | |
3ab51846 | 1131 | @end smallexample |
b64a6a11 JM |
1132 | |
1133 | There is no guarantee (in either the C or the C++ standard language | |
1134 | definitions) that the increments will be evaluated in any particular | |
1135 | order. Either increment might happen first. @code{func} might get the | |
1136 | arguments @samp{2, 3}, or it might get @samp{3, 2}, or even @samp{2, 2}. | |
1137 | ||
b64a6a11 JM |
1138 | @item |
1139 | Making certain warnings into errors by default. | |
1140 | ||
1141 | Some ISO C testsuites report failure when the compiler does not produce | |
1142 | an error message for a certain program. | |
1143 | ||
1144 | @opindex pedantic-errors | |
1145 | ISO C requires a ``diagnostic'' message for certain kinds of invalid | |
1146 | programs, but a warning is defined by GCC to count as a diagnostic. If | |
1147 | GCC produces a warning but not an error, that is correct ISO C support. | |
2eac577f | 1148 | If testsuites call this ``failure'', they should be run with the GCC |
b64a6a11 JM |
1149 | option @option{-pedantic-errors}, which will turn these warnings into |
1150 | errors. | |
1151 | ||
1152 | @end itemize | |
1153 | ||
1154 | @node Warnings and Errors | |
1155 | @section Warning Messages and Error Messages | |
1156 | ||
1157 | @cindex error messages | |
1158 | @cindex warnings vs errors | |
1159 | @cindex messages, warning and error | |
1160 | The GNU compiler can produce two kinds of diagnostics: errors and | |
1161 | warnings. Each kind has a different purpose: | |
1162 | ||
1163 | @itemize @w{} | |
1164 | @item | |
1165 | @dfn{Errors} report problems that make it impossible to compile your | |
1166 | program. GCC reports errors with the source file name and line | |
1167 | number where the problem is apparent. | |
1168 | ||
1169 | @item | |
1170 | @dfn{Warnings} report other unusual conditions in your code that | |
1171 | @emph{may} indicate a problem, although compilation can (and does) | |
1172 | proceed. Warning messages also report the source file name and line | |
1173 | number, but include the text @samp{warning:} to distinguish them | |
1174 | from error messages. | |
1175 | @end itemize | |
1176 | ||
1177 | Warnings may indicate danger points where you should check to make sure | |
1178 | that your program really does what you intend; or the use of obsolete | |
1179 | features; or the use of nonstandard features of GNU C or C++. Many | |
1180 | warnings are issued only if you ask for them, with one of the @option{-W} | |
1181 | options (for instance, @option{-Wall} requests a variety of useful | |
1182 | warnings). | |
1183 | ||
1184 | @opindex pedantic | |
1185 | @opindex pedantic-errors | |
1186 | GCC always tries to compile your program if possible; it never | |
1187 | gratuitously rejects a program whose meaning is clear merely because | |
1188 | (for instance) it fails to conform to a standard. In some cases, | |
1189 | however, the C and C++ standards specify that certain extensions are | |
1190 | forbidden, and a diagnostic @emph{must} be issued by a conforming | |
1191 | compiler. The @option{-pedantic} option tells GCC to issue warnings in | |
1192 | such cases; @option{-pedantic-errors} says to make them errors instead. | |
1193 | This does not mean that @emph{all} non-ISO constructs get warnings | |
1194 | or errors. | |
1195 | ||
1196 | @xref{Warning Options,,Options to Request or Suppress Warnings}, for | |
1197 | more detail on these and related command-line options. |