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