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