![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to gcc.info-4 CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [GCC 1.x] / gcc|
Return to gcc.info-4 CVS log | Up to [GCC 1.x] / gcc |
1.1.1.7 ! root 1: This is Info file gcc.info, produced by Makeinfo-1.47 from the input 1.1 root 2: file gcc.texinfo. 3: 1.1.1.6 root 4: This file documents the use and the internals of the GNU compiler. 1.1 root 5: 1.1.1.6 root 6: Copyright (C) 1988, 1989, 1990 Free Software Foundation, Inc. 1.1 root 7: 1.1.1.7 ! root 8: Permission is granted to make and distribute verbatim copies of this ! 9: manual provided the copyright notice and this permission notice are ! 10: preserved on all copies. 1.1 root 11: 1.1.1.6 root 12: Permission is granted to copy and distribute modified versions of 1.1 root 13: this manual under the conditions for verbatim copying, provided also 1.1.1.4 root 14: that the sections entitled "GNU General Public License" and "Protect 15: Your Freedom--Fight `Look And Feel'" are included exactly as in the 16: original, and provided that the entire resulting derived work is 17: distributed under the terms of a permission notice identical to this 18: one. 1.1 root 19: 1.1.1.6 root 20: Permission is granted to copy and distribute translations of this 1.1 root 21: manual into another language, under the above conditions for modified 1.1.1.4 root 22: versions, except that the sections entitled "GNU General Public 23: License" and "Protect Your Freedom--Fight `Look And Feel'" and this 1.1.1.7 ! root 24: permission notice may be included in translations approved by the Free ! 25: Software Foundation instead of in the original English. ! 26: ! 27: ! 28: File: gcc.info, Node: Statement Exprs, Next: Naming Types, Prev: Extensions, Up: Extensions ! 29: ! 30: Statements and Declarations inside of Expressions ! 31: ================================================= ! 32: ! 33: A compound statement in parentheses may appear inside an expression ! 34: in GNU C. This allows you to declare variables within an expression. ! 35: For example: ! 36: ! 37: ({ int y = foo (); int z; ! 38: if (y > 0) z = y; ! 39: else z = - y; ! 40: z; }) ! 41: ! 42: is a valid (though slightly more complex than necessary) expression for ! 43: the absolute value of `foo ()'. ! 44: ! 45: This feature is especially useful in making macro definitions "safe" ! 46: (so that they evaluate each operand exactly once). For example, the ! 47: "maximum" function is commonly defined as a macro in standard C as ! 48: follows: ! 49: ! 50: #define max(a,b) ((a) > (b) ? (a) : (b)) ! 51: ! 52: But this definition computes either A or B twice, with bad results if ! 53: the operand has side effects. In GNU C, if you know the type of the ! 54: operands (here let's assume `int'), you can define the macro safely as ! 55: follows: ! 56: ! 57: #define maxint(a,b) \ ! 58: ({int _a = (a), _b = (b); _a > _b ? _a : _b; }) ! 59: ! 60: Embedded statements are not allowed in constant expressions, such as ! 61: the value of an enumeration constant, the width of a bit field, or the ! 62: initial value of a static variable. ! 63: ! 64: If you don't know the type of the operand, you can still do this, ! 65: but you must use `typeof' (*note Typeof::.) or type naming (*note ! 66: Naming Types::.). 1.1.1.4 root 67: 1.1.1.6 root 68: 69: File: gcc.info, Node: Naming Types, Next: Typeof, Prev: Statement Exprs, Up: Extensions 70: 71: Naming an Expression's Type 72: =========================== 73: 74: You can give a name to the type of an expression using a `typedef' 1.1.1.7 ! root 75: declaration with an initializer. Here is how to define NAME as a type ! 76: name for the type of EXP: 1.1.1.6 root 77: 78: typedef NAME = EXP; 79: 1.1.1.7 ! root 80: This is useful in conjunction with the statements-within-expressions ! 81: feature. Here is how the two together can be used to define a safe ! 82: "maximum" macro that operates on any arithmetic type: 1.1.1.6 root 83: 84: #define max(a,b) \ 85: ({typedef _ta = (a), _tb = (b); \ 86: _ta _a = (a); _tb _b = (b); \ 87: _a > _b ? _a : _b; }) 88: 1.1.1.7 ! root 89: The reason for using names that start with underscores for the local ! 90: variables is to avoid conflicts with variable names that occur within ! 91: the expressions that are substituted for `a' and `b'. Eventually we ! 92: hope to design a new form of declaration syntax that allows you to ! 93: declare variables whose scopes start only after their initializers; ! 94: this will be a more reliable way to prevent such conflicts. 1.1.1.6 root 95: 96: 97: File: gcc.info, Node: Typeof, Next: Lvalues, Prev: Naming Types, Up: Extensions 98: 99: Referring to a Type with `typeof' 100: ================================= 101: 102: Another way to refer to the type of an expression is with `typeof'. 103: The syntax of using of this keyword looks like `sizeof', but the 104: construct acts semantically like a type name defined with `typedef'. 105: 106: There are two ways of writing the argument to `typeof': with an 107: expression or with a type. Here is an example with an expression: 108: 109: typeof (x[0](1)) 110: 111: This assumes that `x' is an array of functions; the type described is 112: that of the values of the functions. 113: 114: Here is an example with a typename as the argument: 115: 116: typeof (int *) 117: 118: Here the type described is that of pointers to `int'. 119: 120: If you are writing a header file that must work when included in 1.1.1.7 ! root 121: ANSI C programs, write `__typeof__' instead of `typeof'. *Note 1.1.1.6 root 122: Alternate Keywords::. 123: 124: A `typeof'-construct can be used anywhere a typedef name could be 125: used. For example, you can use it in a declaration, in a cast, or 126: inside of `sizeof' or `typeof'. 127: 128: * This declares `y' with the type of what `x' points to. 129: 130: typeof (*x) y; 131: 132: * This declares `y' as an array of such values. 133: 134: typeof (*x) y[4]; 135: 136: * This declares `y' as an array of pointers to characters: 137: 138: typeof (typeof (char *)[4]) y; 139: 140: It is equivalent to the following traditional C declaration: 141: 142: char *y[4]; 143: 144: To see the meaning of the declaration using `typeof', and why it 1.1.1.7 ! root 145: might be a useful way to write, let's rewrite it with these macros: 1.1.1.6 root 146: 147: #define pointer(T) typeof(T *) 148: #define array(T, N) typeof(T [N]) 149: 150: Now the declaration can be rewritten this way: 151: 152: array (pointer (char), 4) y; 153: 154: Thus, `array (pointer (char), 4)' is the type of arrays of 4 155: pointers to `char'. 156: 157: 158: File: gcc.info, Node: Lvalues, Next: Conditionals, Prev: Typeof, Up: Extensions 159: 160: Generalized Lvalues 161: =================== 162: 1.1.1.7 ! root 163: Compound expressions, conditional expressions and casts are allowed ! 164: as lvalues provided their operands are lvalues. This means that you ! 165: can take their addresses or store values into them. ! 166: ! 167: For example, a compound expression can be assigned, provided the last ! 168: expression in the sequence is an lvalue. These two expressions are ! 169: equivalent: 1.1.1.6 root 170: 171: (a, b) += 5 172: a, (b += 5) 173: 174: Similarly, the address of the compound expression can be taken. 175: These two expressions are equivalent: 176: 177: &(a, b) 178: a, &b 179: 180: A conditional expression is a valid lvalue if its type is not void 181: and the true and false branches are both valid lvalues. For example, 182: these two expressions are equivalent: 183: 184: (a ? b : c) = 5 185: (a ? b = 5 : (c = 5)) 186: 1.1.1.7 ! root 187: A cast is a valid lvalue if its operand is an lvalue. A simple ! 188: assignment whose left-hand side is a cast works by converting the ! 189: right-hand side first to the specified type, then to the type of the ! 190: inner left-hand side expression. After this is stored, the value is ! 191: converted back to the specified type to become the value of the ! 192: assignment. Thus, if `a' has type `char *', the following two ! 193: expressions are equivalent: 1.1.1.6 root 194: 195: (int)a = 5 1.1.1.7 ! root 196: (int)(a = (char *)(int)5) 1.1.1.6 root 197: 198: An assignment-with-arithmetic operation such as `+=' applied to a 199: cast performs the arithmetic using the type resulting from the cast, 200: and then continues as in the previous case. Therefore, these two 201: expressions are equivalent: 202: 203: (int)a += 5 1.1.1.7 ! root 204: (int)(a = (char *)(int) ((int)a + 5)) ! 205: ! 206: You cannot take the address of an lvalue cast, because the use of its ! 207: address would not work out coherently. Suppose that `&(int)f' were ! 208: permitted, where `f' has type `float'. Then the following statement ! 209: would try to store an integer bit-pattern where a floating point number ! 210: belongs: ! 211: ! 212: *&(int)f = 1; ! 213: ! 214: This is quite different from what `(int)f = 1' would do--that would ! 215: convert 1 to floating point and store it. Rather than cause this ! 216: inconsistancy, we think it is better to prohibit use of `&' on a cast. ! 217: ! 218: If you really do want an `int *' pointer with the address of `f', ! 219: you can simply write `(int *)&f'. 1.1.1.6 root 220: 221: 222: File: gcc.info, Node: Conditionals, Next: Zero-Length, Prev: Lvalues, Up: Extensions 223: 224: Conditional Expressions with Omitted Middle-Operands 225: ==================================================== 226: 1.1.1.7 ! root 227: The middle operand in a conditional expression may be omitted. Then ! 228: if the first operand is nonzero, its value is the value of the 1.1.1.6 root 229: conditional expression. 230: 231: Therefore, the expression 232: 233: x ? : y 234: 235: has the value of `x' if that is nonzero; otherwise, the value of `y'. 236: 237: This example is perfectly equivalent to 238: 239: x ? x : y 240: 241: In this simple case, the ability to omit the middle operand is not 242: especially useful. When it becomes useful is when the first operand 1.1.1.7 ! root 243: does, or may (if it is a macro argument), contain a side effect. Then ! 244: repeating the operand in the middle would perform the side effect ! 245: twice. Omitting the middle operand uses the value already computed ! 246: without the undesirable effects of recomputing it. 1.1.1.4 root 247: 248: 1.1.1.5 root 249: File: gcc.info, Node: Zero-Length, Next: Variable-Length, Prev: Conditionals, Up: Extensions 250: 251: Arrays of Length Zero 252: ===================== 253: 1.1.1.6 root 254: Zero-length arrays are allowed in GNU C. They are very useful as 255: the last element of a structure which is really a header for a 1.1.1.5 root 256: variable-length object: 257: 258: struct line { 259: int length; 260: char contents[0]; 261: }; 262: 263: { 1.1.1.7 ! root 264: struct line *thisline 1.1.1.5 root 265: = (struct line *) malloc (sizeof (struct line) + this_length); 266: thisline->length = this_length; 267: } 268: 1.1.1.7 ! root 269: In standard C, you would have to give `contents' a length of 1, which ! 270: means either you waste space or complicate the argument to `malloc'. 1.1.1.5 root 271: 272: 1.1.1.4 root 273: File: gcc.info, Node: Variable-Length, Next: Subscripting, Prev: Zero-Length, Up: Extensions 274: 275: Arrays of Variable Length 276: ========================= 277: 1.1.1.7 ! root 278: Variable-length automatic arrays are allowed in GNU C. These arrays ! 279: are declared like any other automatic arrays, but with a length that is ! 280: not a constant expression. The storage is allocated at that time and ! 281: deallocated when the brace-level is exited. For example: 1.1.1.4 root 282: 283: FILE *concat_fopen (char *s1, char *s2, char *mode) 284: { 285: char str[strlen (s1) + strlen (s2) + 1]; 286: strcpy (str, s1); 287: strcat (str, s2); 288: return fopen (str, mode); 289: } 290: 1.1.1.6 root 291: You can also use variable-length arrays as arguments to functions: 1.1.1.4 root 292: 293: struct entry 294: tester (int len, char data[len]) 295: { 296: ... 297: } 298: 1.1.1.7 ! root 299: The length of an array is computed on entry to the brace-level where ! 300: the array is declared and is remembered for the scope of the array in ! 301: case you access it with `sizeof'. 1.1.1.4 root 302: 1.1.1.6 root 303: Jumping or breaking out of the scope of the array name will also 1.1.1.4 root 304: deallocate the storage. Jumping into the scope is not allowed; you 305: will get an error message for it. 306: 1.1.1.6 root 307: You can use the function `alloca' to get an effect much like 1.1.1.4 root 308: variable-length arrays. The function `alloca' is available in many 309: other C implementations (but not in all). On the other hand, 310: variable-length arrays are more elegant. 311: 1.1.1.6 root 312: There are other differences between these two methods. Space 1.1.1.4 root 313: allocated with `alloca' exists until the containing *function* returns. 314: The space for a variable-length array is deallocated as soon as the 315: array name's scope ends. (If you use both variable-length arrays and 1.1.1.7 ! root 316: `alloca' in the same function, deallocation of a variable-length array ! 317: will also deallocate anything more recently allocated with `alloca'.) 1.1.1.4 root 318: 319: 320: File: gcc.info, Node: Subscripting, Next: Pointer Arith, Prev: Variable-Length, Up: Extensions 321: 322: Non-Lvalue Arrays May Have Subscripts 323: ===================================== 324: 1.1.1.7 ! root 325: Subscripting is allowed on arrays that are not lvalues, even though ! 326: the unary `&' operator is not. For example, this is valid in GNU C ! 327: though not valid in other C dialects: 1.1.1.4 root 328: 329: struct foo {int a[4];}; 330: 331: struct foo f(); 332: 333: bar (int index) 334: { 335: return f().a[index]; 336: } 337: 338: 339: File: gcc.info, Node: Pointer Arith, Next: Initializers, Prev: Subscripting, Up: Extensions 340: 341: Arithmetic on `void'-Pointers and Function Pointers 342: =================================================== 343: 1.1.1.6 root 344: In GNU C, addition and subtraction operations are supported on 1.1.1.4 root 345: pointers to `void' and on pointers to functions. This is done by 346: treating the size of a `void' or of a function as 1. 347: 1.1.1.7 ! root 348: A consequence of this is that `sizeof' is also allowed on `void' and ! 349: on function types, and returns 1. 1.1.1.4 root 350: 1.1.1.7 ! root 351: The option `-Wpointer-arith' requests a warning if these extensions ! 352: are used. 1.1.1.4 root 353: 354: 355: File: gcc.info, Node: Initializers, Next: Constructors, Prev: Pointer Arith, Up: Extensions 356: 357: Non-Constant Initializers 358: ========================= 359: 1.1.1.6 root 360: The elements of an aggregate initializer for an automatic variable 1.1.1.4 root 361: are not required to be constant expressions in GNU C. Here is an 362: example of an initializer with run-time varying elements: 363: 364: foo (float f, float g) 365: { 366: float beat_freqs[2] = { f-g, f+g }; 367: ... 368: } 369: 370: 371: File: gcc.info, Node: Constructors, Next: Function Attributes, Prev: Initializers, Up: Extensions 372: 373: Constructor Expressions 374: ======================= 375: 1.1.1.7 ! root 376: GNU C supports constructor expressions. A constructor looks like a ! 377: cast containing an initializer. Its value is an object of the type 1.1.1.4 root 378: specified in the cast, containing the elements specified in the 379: initializer. The type must be a structure, union or array type. 380: 1.1.1.6 root 381: Assume that `struct foo' and `structure' are declared as shown: 1.1.1.4 root 382: 383: struct foo {int a; char b[2];} structure; 384: 385: Here is an example of constructing a `struct foo' with a constructor: 386: 387: structure = ((struct foo) {x + y, 'a', 0}); 388: 389: This is equivalent to writing the following: 390: 391: { 392: struct foo temp = {x + y, 'a', 0}; 393: structure = temp; 394: } 395: 1.1.1.6 root 396: You can also construct an array. If all the elements of the 1.1.1.7 ! root 397: constructor are (made up of) simple constant expressions, suitable for ! 398: use in initializers, then the constructor is an lvalue and can be 1.1.1.4 root 399: coerced to a pointer to its first element, as shown here: 400: 401: char **foo = (char *[]) { "x", "y", "z" }; 402: 1.1.1.6 root 403: Array constructors whose elements are not simple constants are not 1.1.1.7 ! root 404: very useful, because the constructor is not an lvalue. There are only ! 405: two valid ways to use it: to subscript it, or initialize an array ! 406: variable with it. The former is probably slower than a `switch' ! 407: statement, while the latter does the same thing an ordinary C ! 408: initializer would do. 1.1.1.4 root 409: 410: output = ((int[]) { 2, x, 28 }) [input]; 1.1.1.3 root 411: 1.1.1.2 root 412: 1.1.1.3 root 413: File: gcc.info, Node: Function Attributes, Next: Dollar Signs, Prev: Constructors, Up: Extensions 414: 415: Declaring Attributes of Functions 416: ================================= 417: 1.1.1.7 ! root 418: In GNU C, you declare certain things about functions called in your ! 419: program which help the compiler optimize function calls. 1.1.1.3 root 420: 1.1.1.7 ! root 421: A few functions, such as `abort' and `exit', cannot return. These 1.1.1.3 root 422: functions should be declared `volatile'. For example, 423: 424: extern volatile void abort (); 425: 1.1.1.7 ! root 426: tells the compiler that it can assume that `abort' will not return. 1.1.1.3 root 427: This makes slightly better code, but more importantly it helps avoid 428: spurious warnings of uninitialized variables. 1.1.1.2 root 429: 1.1.1.7 ! root 430: Many functions do not examine any values except their arguments, and ! 431: have no effects except the return value. Such a function can be subject ! 432: to common subexpression elimination and loop optimization just as an ! 433: arithmetic operator would be. These functions should be declared ! 434: `const'. For example, 1.1.1.2 root 435: 1.1.1.7 ! root 436: extern const int square (); 1.1.1.2 root 437: 1.1.1.3 root 438: says that the hypothetical function `square' is safe to call fewer 439: times than the program says. 440: 1.1.1.7 ! root 441: Note that a function that has pointer arguments and examines the data ! 442: pointed to must *not* be declared `const'. Likewise, a function that ! 443: calls a non-`const' function usually must not be `const'. ! 444: ! 445: Some people object to this feature, claiming that ANSI C's `#pragma' ! 446: should be used instead. There are two reasons I did not do this. 1.1.1.3 root 447: 448: 1. It is impossible to generate `#pragma' commands from a macro. 449: 1.1.1.7 ! root 450: 2. The `#pragma' command is just as likely as these keywords to mean ! 451: something else in another compiler. 1.1.1.3 root 452: 1.1.1.6 root 453: These two reasons apply to *any* application whatever: as far as I 1.1.1.3 root 454: can see, `#pragma' is never useful. 1.1.1.2 root 455: 456: 1.1.1.3 root 457: File: gcc.info, Node: Dollar Signs, Next: Alignment, Prev: Function Attributes, Up: Extensions 1.1.1.2 root 458: 1.1.1.3 root 459: Dollar Signs in Identifier Names 460: ================================ 461: 1.1.1.6 root 462: In GNU C, you may use dollar signs in identifier names. This is 1.1.1.3 root 463: because many traditional C implementations allow such identifiers. 1.1.1.2 root 464: 1.1.1.7 ! root 465: Dollar signs are allowed if you specify `-traditional'; they are not ! 466: allowed if you specify `-ansi'. Whether they are allowed by default ! 467: depends on the target machine; usually, they are not. 1.1.1.2 root 468: 469: 1.1.1.3 root 470: File: gcc.info, Node: Alignment, Next: Inline, Prev: Dollar Signs, Up: Extensions 1.1.1.2 root 471: 1.1.1.3 root 472: Inquiring about the Alignment of a Type or Variable 473: =================================================== 1.1.1.2 root 474: 1.1.1.7 ! root 475: The keyword `__alignof__' allows you to inquire about how an object ! 476: is aligned, or the minimum alignment usually required by a type. Its ! 477: syntax is just like `sizeof'. 1.1.1.3 root 478: 1.1.1.6 root 479: For example, if the target machine requires a `double' value to be 1.1.1.7 ! root 480: aligned on an 8-byte boundary, then `__alignof__ (double)' is 8. This ! 481: is true on many RISC machines. On more traditional machine designs, ! 482: `__alignof__ (double)' is 4 or even 2. ! 483: ! 484: Some machines never actually require alignment; they allow reference ! 485: to any data type even at an odd addresses. For these machines, ! 486: `__alignof__' reports the *recommended* alignment of a type. 1.1.1.3 root 487: 1.1.1.6 root 488: When the operand of `__alignof__' is an lvalue rather than a type, 1.1.1.3 root 489: the value is the largest alignment that the lvalue is known to have. 1.1.1.7 ! root 490: It may have this alignment as a result of its data type, or because it ! 491: is part of a structure and inherits alignment from that structure. For ! 492: example, after this declaration: 1.1.1.3 root 493: 494: struct foo { int x; char y; } foo1; 495: 496: the value of `__alignof__ (foo1.y)' is probably 2 or 4, the same as 497: `__alignof__ (int)', even though the data type of `foo1.y' does not 498: itself demand any alignment. 1.1.1.2 root 499: 500: 1.1.1.3 root 501: File: gcc.info, Node: Inline, Next: Extended Asm, Prev: Alignment, Up: Extensions 502: 503: An Inline Function is As Fast As a Macro 504: ======================================== 505: 1.1.1.7 ! root 506: By declaring a function `inline', you can direct GNU CC to integrate ! 507: that function's code into the code for its callers. This makes ! 508: execution faster by eliminating the function-call overhead; in 1.1.1.3 root 509: addition, if any of the actual argument values are constant, their 1.1.1.7 ! root 510: known values may permit simplifications at compile time so that not all ! 511: of the inline function's code needs to be included. 1.1.1.2 root 512: 1.1.1.6 root 513: To declare a function inline, use the `inline' keyword in its 1.1.1.3 root 514: declaration, like this: 1.1.1.2 root 515: 1.1.1.3 root 516: inline int 517: inc (int *a) 518: { 519: (*a)++; 520: } 521: 1.1.1.7 ! root 522: (If you are writing a header file to be included in ANSI C programs, ! 523: write `__inline__' instead of `inline'. *Note Alternate Keywords::.) 1.1.1.3 root 524: 1.1.1.6 root 525: You can also make all "simple enough" functions inline with the 1.1.1.3 root 526: option `-finline-functions'. Note that certain usages in a function 527: definition can make it unsuitable for inline substitution. 528: 1.1.1.6 root 529: When a function is both inline and `static', if all calls to the 1.1.1.7 ! root 530: function are integrated into the caller, and the function's address is ! 531: never used, then the function's own assembler code is never referenced. ! 532: In this case, GNU CC does not actually output assembler code for the ! 533: function, unless you specify the option `-fkeep-inline-functions'. Some ! 534: calls cannot be integrated for various reasons (in particular, calls ! 535: that precede the function's definition cannot be integrated, and ! 536: neither can recursive calls within the definition). If there is a ! 537: nonintegrated call, then the function is compiled to assembler code as ! 538: usual. The function must also be compiled as usual if the program ! 539: refers to its address, because that can't be inlined. 1.1.1.3 root 540: 1.1.1.6 root 541: When an inline function is not `static', then the compiler must 1.1.1.7 ! root 542: assume that there may be calls from other source files; since a global ! 543: symbol can be defined only once in any program, the function must not ! 544: be defined in the other source files, so the calls therein cannot be ! 545: integrated. Therefore, a non-`static' inline function is always ! 546: compiled on its own in the usual fashion. 1.1.1.3 root 547: 1.1.1.6 root 548: If you specify both `inline' and `extern' in the function 1.1.1.7 ! root 549: definition, then the definition is used only for inlining. In no case ! 550: is the function compiled on its own, not even if you refer to its ! 551: address explicitly. Such an address becomes an external reference, as ! 552: if you had only declared the function, and had not defined it. ! 553: ! 554: This combination of `inline' and `extern' has almost the effect of a ! 555: macro. The way to use it is to put a function definition in a header ! 556: file with these keywords, and put another copy of the definition ! 557: (lacking `inline' and `extern') in a library file. The definition in ! 558: the header file will cause most calls to the function to be inlined. ! 559: If any uses of the function remain, they will refer to the single copy ! 560: in the library. 1.1.1.2 root 561: 562: 1.1.1.3 root 563: File: gcc.info, Node: Extended Asm, Next: Asm Labels, Prev: Inline, Up: Extensions 564: 565: Assembler Instructions with C Expression Operands 566: ================================================= 567: 1.1.1.6 root 568: In an assembler instruction using `asm', you can now specify the 1.1.1.3 root 569: operands of the instruction using C expressions. This means no more 1.1.1.7 ! root 570: guessing which registers or memory locations will contain the data you ! 571: want to use. 1.1.1.3 root 572: 1.1.1.6 root 573: You must specify an assembler instruction template much like what 1.1.1.7 ! root 574: appears in a machine description, plus an operand constraint string for ! 575: each operand. 1.1.1.3 root 576: 1.1.1.6 root 577: For example, here is how to use the 68881's `fsinx' instruction: 1.1.1.3 root 578: 579: asm ("fsinx %1,%0" : "=f" (result) : "f" (angle)); 580: 581: Here `angle' is the C expression for the input operand while `result' 582: is that of the output operand. Each has `"f"' as its operand 1.1.1.7 ! root 583: constraint, saying that a floating-point register is required. The `=' ! 584: in `=f' indicates that the operand is an output; all output operands' ! 585: constraints must use `='. The constraints use the same language used ! 586: in the machine description (*note Constraints::.). 1.1.1.3 root 587: 1.1.1.6 root 588: Each operand is described by an operand-constraint string followed 589: by the C expression in parentheses. A colon separates the assembler 1.1.1.7 ! root 590: template from the first output operand, and another separates the last ! 591: output operand from the first input, if any. Commas separate output ! 592: operands and separate inputs. The total number of operands is limited ! 593: to the maximum number of operands in any instruction pattern in the ! 594: machine description. ! 595: ! 596: If there are no output operands, and there are input operands, then ! 597: there must be two consecutive colons surrounding the place where the ! 598: output operands would go. 1.1.1.3 root 599: 1.1.1.6 root 600: Output operand expressions must be lvalues; the compiler can check 1.1.1.7 ! root 601: this. The input operands need not be lvalues. The compiler cannot ! 602: check whether the operands have data types that are reasonable for the ! 603: instruction being executed. It does not parse the assembler ! 604: instruction template and does not know what it means, or whether it is ! 605: valid assembler input. The extended `asm' feature is most often used ! 606: for machine instructions that the compiler itself does not know exist. ! 607: ! 608: The output operands must be write-only; GNU CC will assume that the ! 609: values in these operands before the instruction are dead and need not be ! 610: generated. Extended asm does not support input-output or read-write ! 611: operands. For this reason, the constraint character `+', which ! 612: indicates such an operand, may not be used. 1.1.1.3 root 613: 1.1.1.6 root 614: When the assembler instruction has a read-write operand, or an 1.1.1.3 root 615: operand in which only some of the bits are to be changed, you must 616: logically split its function into two separate operands, one input 1.1.1.7 ! root 617: operand and one write-only output operand. The connection between them ! 618: is expressed by constraints which say they need to be in the same ! 619: location when the instruction executes. You can use the same C 1.1.1.3 root 620: expression for both operands, or different expressions. For example, 1.1.1.7 ! root 621: here we write the (fictitious) `combine' instruction with `bar' as its ! 622: read-only source operand and `foo' as its read-write destination: 1.1.1.3 root 623: 624: asm ("combine %2,%0" : "=r" (foo) : "0" (foo), "g" (bar)); 625: 626: The constraint `"0"' for operand 1 says that it must occupy the same 627: location as operand 0. A digit in constraint is allowed only in an 628: input operand, and it must refer to an output operand. 629: 1.1.1.6 root 630: Only a digit in the constraint can guarantee that one operand will 1.1.1.7 ! root 631: be in the same place as another. The mere fact that `foo' is the value ! 632: of both operands is not enough to guarantee that they will be in the ! 633: same place in the generated assembler code. The following would not ! 634: work: 1.1.1.3 root 635: 636: asm ("combine %2,%0" : "=r" (foo) : "r" (foo), "g" (bar)); 637: 1.1.1.6 root 638: Various optimizations or reloading could cause operands 0 and 1 to 639: be in different registers; GNU CC knows no reason not to do so. For 1.1.1.3 root 640: example, the compiler might find a copy of the value of `foo' in one 1.1.1.7 ! root 641: register and use it for operand 1, but generate the output operand 0 in ! 642: a different register (copying it afterward to `foo''s own address). Of ! 643: course, since the register for operand 1 is not even mentioned in the ! 644: assembler code, the result will not work, but GNU CC can't tell that. ! 645: ! 646: Unless an output operand has the `&' constraint modifier, GNU CC may ! 647: allocate it in the same register as an unrelated input operand, on the ! 648: assumption that the inputs are consumed before the outputs are produced. ! 649: This assumption may be false if the assembler code actually consists of ! 650: more than one instruction. In such a case, use `&' for each output ! 651: operand that may not overlap an input. *Note Modifiers::. 1.1.1.3 root 652: 1.1.1.6 root 653: Some instructions clobber specific hard registers. To describe 654: this, write a third colon after the input operands, followed by the 655: names of the clobbered hard registers (given as strings). Here is a 1.1.1.3 root 656: realistic example for the vax: 657: 658: asm volatile ("movc3 %0,%1,%2" 659: : /* no outputs */ 660: : "g" (from), "g" (to), "g" (count) 661: : "r0", "r1", "r2", "r3", "r4", "r5"); 662: 1.1.1.6 root 663: You can put multiple assembler instructions together in a single 1.1.1.7 ! root 664: `asm' template, separated either with newlines (written as `\n') or with ! 665: semicolons if the assembler allows such semicolons. The GNU assembler ! 666: allows semicolons and all Unix assemblers seem to do so. The input ! 667: operands are guaranteed not to use any of the clobbered registers, and ! 668: neither will the output operands' addresses, so you can read and write ! 669: the clobbered registers as many times as you like. Here is an example ! 670: of multiple instructions in a template; it assumes that the subroutine ! 671: `_foo' accepts arguments in registers 9 and 10: 1.1.1.3 root 672: 673: asm ("movl %0,r9;movl %1,r10;call _foo" 674: : /* no outputs */ 675: : "g" (from), "g" (to) 676: : "r9", "r10"); 677: 1.1.1.6 root 678: If you want to test the condition code produced by an assembler 1.1.1.3 root 679: instruction, you must include a branch and a label in the `asm' 680: construct, as follows: 681: 682: asm ("clr %0;frob %1;beq 0f;mov #1,%0;0:" 683: : "g" (result) 684: : "g" (input)); 685: 1.1.1.7 ! root 686: This assumes your assembler supports local labels, as the GNU assembler ! 687: and most Unix assemblers do. 1.1.1.3 root 688: 1.1.1.7 ! root 689: Usually the most convenient way to use these `asm' instructions is to ! 690: encapsulate them in macros that look like functions. For example, 1.1.1.3 root 691: 692: #define sin(x) \ 693: ({ double __value, __arg = (x); \ 694: asm ("fsinx %1,%0": "=f" (__value): "f" (__arg)); \ 695: __value; }) 696: 697: Here the variable `__arg' is used to make sure that the instruction 1.1.1.7 ! root 698: operates on a proper `double' value, and to accept only those arguments ! 699: `x' which can convert automatically to a `double'. 1.1.1.3 root 700: 1.1.1.6 root 701: Another way to make sure the instruction operates on the correct 1.1.1.7 ! root 702: data type is to use a cast in the `asm'. This is different from using a ! 703: variable `__arg' in that it converts more different types. For ! 704: example, if the desired type were `int', casting the argument to `int' ! 705: would accept a pointer with no complaint, while assigning the argument ! 706: to an `int' variable named `__arg' would warn about using a pointer ! 707: unless the caller explicitly casts it. 1.1.1.2 root 708: 1.1.1.6 root 709: If an `asm' has output operands, GNU CC assumes for optimization 1.1.1.7 ! root 710: purposes that the instruction has no side effects except to change the ! 711: output operands. This does not mean that instructions with a side ! 712: effect cannot be used, but you must be careful, because the compiler ! 713: may eliminate them if the output operands aren't used, or move them out ! 714: of loops, or replace two with one if they constitute a common ! 715: subexpression. Also, if your instruction does have a side effect on a ! 716: variable that otherwise appears not to change, the old value of the ! 717: variable may be reused later if it happens to be found in a register. 1.1.1.2 root 718: 1.1.1.6 root 719: You can prevent an `asm' instruction from being deleted, moved or 1.1.1.3 root 720: combined by writing the keyword `volatile' after the `asm'. For 721: example: 1.1.1.2 root 722: 1.1.1.3 root 723: #define set_priority(x) \ 724: asm volatile ("set_priority %0": /* no outputs */ : "g" (x)) 725: 1.1.1.7 ! root 726: (However, an instruction without output operands will not be deleted or ! 727: moved, regardless, unless it is unreachable.) 1.1.1.3 root 728: 1.1.1.6 root 729: It is a natural idea to look for a way to give access to the 1.1.1.3 root 730: condition code left by the assembler instruction. However, when we 1.1.1.7 ! root 731: attempted to implement this, we found no way to make it work reliably. ! 732: The problem is that output operands might need reloading, which would ! 733: result in additional following "store" instructions. On most machines, ! 734: these instructions would alter the condition code before there was time ! 735: to test it. This problem doesn't arise for ordinary "test" and ! 736: "compare" instructions because they don't have any output operands. ! 737: ! 738: If you are writing a header file that should be includable in ANSI C ! 739: programs, write `__asm__' instead of `asm'. *Note Alternate Keywords::. 1.1.1.2 root 740: 741: 1.1.1.3 root 742: File: gcc.info, Node: Asm Labels, Next: Explicit Reg Vars, Prev: Extended Asm, Up: Extensions 743: 744: Controlling Names Used in Assembler Code 745: ======================================== 746: 1.1.1.6 root 747: You can specify the name to be used in the assembler code for a C 1.1.1.7 ! root 748: function or variable by writing the `asm' (or `__asm__') keyword after ! 749: the declarator as follows: 1.1.1.3 root 750: 751: int foo asm ("myfoo") = 2; 752: 753: This specifies that the name to be used for the variable `foo' in the 754: assembler code should be `myfoo' rather than the usual `_foo'. 1.1.1.2 root 755: 1.1.1.7 ! root 756: On systems where an underscore is normally prepended to the name of ! 757: a C function or variable, this feature allows you to define names for ! 758: the linker that do not start with an underscore. 1.1.1.2 root 759: 1.1.1.7 ! root 760: You cannot use `asm' in this way in a function *definition*; but you ! 761: can get the same effect by writing a declaration for the function 1.1.1.3 root 762: before its definition and putting `asm' there, like this: 1.1.1.2 root 763: 1.1.1.3 root 764: extern func () asm ("FUNC"); 765: 766: func (x, y) 767: int x, y; 768: ... 769: 1.1.1.7 ! root 770: It is up to you to make sure that the assembler names you choose do ! 771: not conflict with any other assembler symbols. Also, you must not use a ! 772: register name; that would produce completely invalid assembler code. ! 773: GNU CC does not as yet have the ability to store static variables in ! 774: registers. Perhaps that will be added. 1.1.1.2 root 775: 776: 1.1.1.3 root 777: File: gcc.info, Node: Explicit Reg Vars, Next: Alternate Keywords, Prev: Asm Labels, Up: Extensions 778: 779: Variables in Specified Registers 780: ================================ 781: 1.1.1.6 root 782: GNU C allows you to put a few global variables into specified 1.1.1.3 root 783: hardware registers. You can also specify the register in which an 784: ordinary register variable should be allocated. 785: 1.1.1.7 ! root 786: * Global register variables reserve registers throughout the program. ! 787: This may be useful in programs such as programming language ! 788: interpreters which have a couple of global variables that are ! 789: accessed very often. ! 790: ! 791: * Local register variables in specific registers do not reserve the ! 792: registers. The compiler's data flow analysis is capable of ! 793: determining where the specified registers contain live values, and ! 794: where they are available for other uses. These local variables are ! 795: sometimes convenient for use with the extended `asm' feature ! 796: (*note Extended Asm::.). 1.1.1.2 root 797: 1.1.1.3 root 798: * Menu: 799: 800: * Global Reg Vars:: 801: * Local Reg Vars:: 1.1.1.2 root 802: 1.1 root 803: 1.1.1.3 root 804: File: gcc.info, Node: Global Reg Vars, Next: Local Reg Vars, Prev: Explicit Reg Vars, Up: Explicit Reg Vars 1.1 root 805: 1.1.1.3 root 806: Defining Global Register Variables 807: ---------------------------------- 808: 1.1.1.6 root 809: You can define a global register variable in GNU C like this: 1.1 root 810: 1.1.1.3 root 811: register int *foo asm ("a5"); 1.1 root 812: 1.1.1.3 root 813: Here `a5' is the name of the register which should be used. Choose a 1.1.1.7 ! root 814: register which is normally saved and restored by function calls on your ! 815: machine, so that library routines will not clobber it. 1.1.1.3 root 816: 1.1.1.6 root 817: Naturally the register name is cpu-dependent, so you would need to 1.1.1.3 root 818: conditionalize your program according to cpu type. The register `a5' 819: would be a good choice on a 68000 for a variable of pointer type. On 1.1.1.4 root 820: machines with register windows, be sure to choose a "global" register 821: that is not affected magically by the function call mechanism. 1.1.1.3 root 822: 1.1.1.7 ! root 823: In addition, operating systems on one type of cpu may differ in how ! 824: they name the registers; then you would need additional conditionals. ! 825: For example, some 68000 operating systems call this register `%a5'. 1.1.1.3 root 826: 1.1.1.6 root 827: Eventually there may be a way of asking the compiler to choose a 1.1.1.3 root 828: register automatically, but first we need to figure out how it should 829: choose and how to enable you to guide the choice. No solution is 830: evident. 831: 1.1.1.6 root 832: Defining a global register variable in a certain register reserves 1.1.1.3 root 833: that register entirely for this use, at least within the current 1.1.1.7 ! root 834: compilation. The register will not be allocated for any other purpose ! 835: in the functions in the current compilation. The register will not be ! 836: saved and restored by these functions. Stores into this register are ! 837: never deleted even if they would appear to be dead, but references may ! 838: be deleted or moved or simplified. 1.1.1.3 root 839: 1.1.1.6 root 840: It is not safe to access the global register variables from signal 1.1.1.3 root 841: handlers, or from more than one thread of control, because the system 842: library routines may temporarily use the register for other things 843: (unless you recompile them specially for the task at hand). 844: 1.1.1.7 ! root 845: It is not safe for one function that uses a global register variable ! 846: to call another such function `foo' by way of a third function `lose' ! 847: that was compiled without knowledge of this variable (i.e. in a ! 848: different source file in which the variable wasn't declared). This is ! 849: because `lose' might save the register and put some other value there. ! 850: For example, you can't expect a global register variable to be ! 851: available in the comparison-function that you pass to `qsort', since ! 852: `qsort' might have put something else in that register. (If you are ! 853: prepared to recompile `qsort' with the same global register variable, ! 854: you can solve this problem.) ! 855: ! 856: If you want to recompile `qsort' or other source files which do not ! 857: actually use your global register variable, so that they will not use ! 858: that register for any other purpose, then it suffices to specify the ! 859: compiler option `-ffixed-REG'. You need not actually add a global ! 860: register declaration to their source code. 1.1.1.3 root 861: 1.1.1.6 root 862: A function which can alter the value of a global register variable 1.1.1.7 ! root 863: cannot safely be called from a function compiled without this variable, ! 864: because it could clobber the value the caller expects to find there on ! 865: return. Therefore, the function which is the entry point into the part ! 866: of the program that uses the global register variable must explicitly ! 867: save and restore the value which belongs to its caller. 1.1.1.3 root 868: 1.1.1.6 root 869: On most machines, `longjmp' will restore to each global register 1.1.1.3 root 870: variable the value it had at the time of the `setjmp'. On some 871: machines, however, `longjmp' will not change the value of global 1.1.1.7 ! root 872: register variables. To be portable, the function that called `setjmp' ! 873: should make other arrangements to save the values of the global register ! 874: variables, and to restore them in a `longjmp'. This way, the same ! 875: thing will happen regardless of what `longjmp' does. ! 876: ! 877: All global register variable declarations must precede all function ! 878: definitions. If such a declaration could appear after function ! 879: definitions, the declaration would be too late to prevent the register ! 880: from being used for other purposes in the preceding functions. 1.1.1.3 root 881: 1.1.1.6 root 882: Global register variables may not have initial values, because an 1.1.1.3 root 883: executable file has no means to supply initial contents for a register. 1.1 root 884: 885: 1.1.1.3 root 886: File: gcc.info, Node: Local Reg Vars, Prev: Global Reg Vars, Up: Explicit Reg Vars 887: 888: Specifying Registers for Local Variables 889: ---------------------------------------- 890: 1.1.1.6 root 891: You can define a local register variable with a specified register 1.1.1.3 root 892: like this: 893: 894: register int *foo asm ("a5"); 1.1 root 895: 1.1.1.7 ! root 896: Here `a5' is the name of the register which should be used. Note that ! 897: this is the same syntax used for defining global register variables, ! 898: but for a local variable it would appear within a function. 1.1 root 899: 1.1.1.6 root 900: Naturally the register name is cpu-dependent, but this is not a 1.1.1.3 root 901: problem, since specific registers are most often useful with explicit 902: assembler instructions (*note Extended Asm::.). Both of these things 1.1.1.7 ! root 903: generally require that you conditionalize your program according to cpu ! 904: type. 1.1.1.3 root 905: 1.1.1.7 ! root 906: In addition, operating systems on one type of cpu may differ in how ! 907: they name the registers; then you would need additional conditionals. ! 908: For example, some 68000 operating systems call this register `%a5'. 1.1.1.3 root 909: 1.1.1.6 root 910: Eventually there may be a way of asking the compiler to choose a 1.1.1.3 root 911: register automatically, but first we need to figure out how it should 912: choose and how to enable you to guide the choice. No solution is 913: evident. 914: 1.1.1.7 ! root 915: Defining such a register variable does not reserve the register; it ! 916: remains available for other uses in places where flow control determines ! 917: the variable's value is not live. However, these registers are made ! 918: unavailable for use in the reload pass. I would not be surprised if ! 919: excessive use of this feature leaves the compiler too few available ! 920: registers to compile certain functions. 1.1 root 921: 922: 1.1.1.3 root 923: File: gcc.info, Node: Alternate Keywords, Prev: Explicit Reg Vars, Up: Extensions 924: 925: Alternate Keywords 926: ================== 927: 1.1.1.6 root 928: The option `-traditional' disables certain keywords; `-ansi' 1.1.1.7 ! root 929: disables certain others. This causes trouble when you want to use GNU C ! 930: extensions, or ANSI C features, in a general-purpose header file that ! 931: should be usable by all programs, including ANSI C programs and ! 932: traditional ones. The keywords `asm', `typeof' and `inline' cannot be ! 933: used since they won't work in a program compiled with `-ansi', while ! 934: the keywords `const', `volatile', `signed', `typeof' and `inline' won't ! 935: work in a program compiled with `-traditional'. ! 936: ! 937: The way to solve these problems is to put `__' at the beginning and ! 938: end of each problematical keyword. For example, use `__asm__' instead ! 939: of `asm', `__const__' instead of `const', and `__inline__' instead of ! 940: `inline'. 1.1 root 941: 1.1.1.6 root 942: Other C compilers won't accept these alternative keywords; if you 1.1.1.3 root 943: want to compile with another compiler, you can define the alternate 944: keywords as macros to replace them with the customary keywords. It 945: looks like this: 1.1 root 946: 1.1.1.3 root 947: #ifndef __GNUC__ 948: #define __asm__ asm 949: #endif 1.1 root 950: 951: 1.1.1.3 root 952: File: gcc.info, Node: Bugs, Next: Portability, Prev: Extensions, Up: Top 1.1 root 953: 1.1.1.3 root 954: Reporting Bugs 955: ************** 1.1 root 956: 1.1.1.6 root 957: Your bug reports play an essential role in making GNU CC reliable. 1.1 root 958: 1.1.1.7 ! root 959: When you encounter a problem, the first thing to do is to see if it ! 960: is already known. *Note Trouble::. Also look in *Note ! 961: Incompatibilities::. If it isn't known, then you should report the 1.1.1.5 root 962: problem. 963: 1.1.1.7 ! root 964: Reporting a bug may help you by bringing a solution to your problem, ! 965: or it may not. (If it does not, look in the service directory; see ! 966: *Note Service::.) In any case, the principal function of a bug report ! 967: is to help the entire community by making the next version of GNU CC ! 968: work better. Bug reports are your contribution to the maintenance of ! 969: GNU CC. 1.1 root 970: 1.1.1.7 ! root 971: In order for a bug report to serve its purpose, you must include the ! 972: information that makes for fixing the bug. 1.1 root 973: 1.1.1.3 root 974: * Menu: 975: 976: * Criteria: Bug Criteria. Have you really found a bug? 977: * Reporting: Bug Reporting. How to report a bug effectively. 978: 1.1 root 979: 1.1.1.3 root 980: File: gcc.info, Node: Bug Criteria, Next: Bug Reporting, Prev: Bugs, Up: Bugs 981: 982: Have You Found a Bug? 983: ===================== 984: 1.1.1.6 root 985: If you are not sure whether you have found a bug, here are some 1.1.1.3 root 986: guidelines: 987: 1.1.1.7 ! root 988: * If the compiler gets a fatal signal, for any input whatever, that ! 989: is a compiler bug. Reliable compilers never crash. 1.1 root 990: 1.1.1.3 root 991: * If the compiler produces invalid assembly code, for any input 992: whatever (except an `asm' statement), that is a compiler bug, 1.1.1.7 ! root 993: unless the compiler reports errors (not just warnings) which would ! 994: ordinarily prevent the assembler from being run. 1.1 root 995: 1.1.1.3 root 996: * If the compiler produces valid assembly code that does not 997: correctly execute the input source code, that is a compiler bug. 998: 1.1.1.7 ! root 999: However, you must double-check to make sure, because you may have ! 1000: run into an incompatibility between GNU C and traditional C (*note ! 1001: Incompatibilities::.). These incompatibilities might be considered ! 1002: bugs, but they are inescapable consequences of valuable features. 1.1.1.3 root 1003: 1004: Or you may have a program whose behavior is undefined, which 1005: happened by chance to give the desired results with another C 1006: compiler. 1007: 1008: For example, in many nonoptimizing compilers, you can write `x;' 1009: at the end of a function instead of `return x;', with the same 1010: results. But the value of the function is undefined if `return' 1.1.1.7 ! root 1011: is omitted; it is not a bug when GNU CC produces different results. 1.1.1.3 root 1012: 1013: Problems often result from expressions with two increment 1014: operators, as in `f (*p++, *p++)'. Your previous compiler might 1.1.1.7 ! root 1015: have interpreted that expression the way you intended; GNU CC might ! 1016: interpret it another way. Neither compiler is wrong. The bug is ! 1017: in your code. 1.1.1.3 root 1018: 1019: After you have localized the error to a single source line, it 1020: should be easy to check for these things. If your program is 1021: correct and well defined, you have found a compiler bug. 1022: 1.1.1.7 ! root 1023: * If the compiler produces an error message for valid input, that is ! 1024: a compiler bug. 1.1.1.3 root 1025: 1.1.1.7 ! root 1026: Note that the following is not valid input, and the error message ! 1027: for it is not a bug: 1.1.1.3 root 1028: 1029: int foo (char); 1030: 1031: int 1032: foo (x) 1033: char x; 1034: { ... } 1035: 1.1.1.7 ! root 1036: The prototype says to pass a `char', while the definition says to ! 1037: pass an `int' and treat the value as a `char'. This is what the ! 1038: ANSI standard says, and it makes sense. 1.1.1.3 root 1039: 1040: * If the compiler does not produce an error message for invalid 1.1.1.7 ! root 1041: input, that is a compiler bug. However, you should note that your ! 1042: idea of "invalid input" might be my idea of "an extension" or ! 1043: "support for traditional practice". 1.1.1.3 root 1044: 1045: * If you are an experienced user of C compilers, your suggestions 1046: for improvement of GNU CC are welcome in any case. 1.1 root 1047: 1.1.1.6 root 1048:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.